BSC R12 DT Impact

Ericssonwide Internal REPORT Prepared (also subject responsible if other)

1 (125)

No.

esteeds Approved

Checked

ETE/O/LB [Marie Sollén]

ETE/O/LB-04:000013 Uen Date

Rev

2010-12-22

Pa1

Reference

R12 Impact on Data Transcript Abstract This document describes the impact R12 has on the Data Transcript activity, the feature are listed per shipment. The structure for each feature are a short description, AXE Parameters, Exchang properties, Command, STS and HW. Below are the input documents stated: BSS R12 Integration Plan BSC R12 Integration Plan (tube) BSC R12 Feature Information BSC R12 BSS R12

Contents 1 Shipment 1..................................................................................................3 1.1 369, R12 Impact on Data Transcript.................................................3 1.2 STS delivery 1..................................................................................8 1.3 409, BTS O&M Improvements..........................................................9 2 Shipment 2................................................................................................16 2.1 81, HCS Enhancements.................................................................16 2.2 466, R12 Impact on Data Transcript...............................................19 2.3 467, System Improvements for BSC..............................................22 2.4 368, R12 Impact on Data Transcript...............................................23 3 Shipment 3................................................................................................25 3.1 390.1, R12 Impact on Data Transcript............................................25 3.2 390.2, Increased PCU capacity - Traffic Capacity..........................26 3.3 40, GPRS/EGPRS Performance Booster.......................................28 3.4 368, R12 Impact on Data Transcript...............................................31 3.5 467, System Improvements for BSC..............................................31 3.6 25, GPRS/EGPRS Load Optimization............................................32 3.7 STS delivery 2................................................................................35 3.8 413, Mega BSC – Support for 1024 cells.......................................35 4 Shipment 4................................................................................................36 4.1 104, Tandem Free Operation.........................................................36


esteeds Approved


2 (125)

No.

Checked


Rev

2010-12-22

Pa1

Reference

4.2 191, Handover with Usage of Service Indicator..............................51 4.3 194, Load Sharing Between UMTS AND GSM...............................52 4.4 409, BTS O&M Improvements........................................................56 5 Shipment 5................................................................................................56 5.1 367, RNO Enhancements R12.......................................................56 5.2 397.1, Channel Allocation Enhancements R12..............................62 5.3 397.2, Channel Allocation Enhancements R12..............................64 5.4 441, DTM Improvements................................................................73 5.5 94, Enhanced Measurement Reporting (EMR)...............................76 5.6 432, R12 Impact on Data Transcript...............................................88 6 Shipment 6................................................................................................93 6.1 239.1, R12 Impact on Data Transcript............................................93 6.2 239.2, R12 Impact on Data Transcript............................................98 6.3 238, Statistics Enhancements R12...............................................108 6.4 43, R12 Impact on Data Transcript...............................................111 6.5 390, R12 Impact on Data Transcript.............................................113 6.6 368, R12 Impact on Data Transcript.............................................113 6.7 STS delivery 3..............................................................................113 6.8 40, GPRS/EGPRS Performance Booster.....................................114 6.9 438, Adaptive AMR Thresholds....................................................114 7 Shipment 7..............................................................................................118 7.1 239, R12 Impact on Data Transcript.............................................118 7.2 396, R12 Impact on Data Transcript.............................................118 7.3 238, Statistics Enhancements R12...............................................123 7.4 432, R12 Impact on Data Transcript.............................................125 7.5 Feature name...............................................................................125


3 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

1

Shipment 1

1.1

369, R12 Impact on Data Transcript

Reference

Package: MBCE_1, MBCE_2 1.1.1

Description Link to IP IP Multi Band Cell Enhancements is a feature with different multi band cell improvements. It is divided into five different ambition levels that are independent of each other with the exception that in ambition level 4 STS counters are added for the functionality described in ambition level 2.

1.1.2

The first ambition level makes it possible to use own-BCCH signal strength for CS calls served by non-BCCH frequency band group through the locating process to allow more accurate locating.

1.1.2.1

AXE parameter No impact.

1.1.2.2

Exchange Property No impact.

1.1.2.3

Command No impact.

1.1.2.4

STS No impact.

1.1.3

The second ambition level makes it possible to separately applying pathloss and DTCB criteria to the BCCH channel group where the BCCH resides.

1.1.3.1


1.1.3.2



No.

esteeds Approved

Checked


1.1.3.3

4 (125)


Rev

2010-12-22

Pa1

Reference

Command Doc. No: 2/190 82-CNT 240 1489 Title: RLLOC Change: Amb lev: 2: The new parameters BCCHREUSE, BCCHLOSS and BCCHDTCB should be added. In block RQLOA command description RLLOC and printout description CELL LOCATING DATA should be updated with parameters BCCHREUSE, BCCHLOSS, BCCHDTCBN and BCCHDTCBP.

Param BCCHREUSE

Description Tight BCCH reuse switch

BCCHLOSS

Pathloss threshold for BCCH channel group Negative distance to cell border for BCCH channel group Positive distance to cell border for BCCH channel group

BCCHDTCBN

BCCHDTCBP

Value range TIGHT, NORMAL [0..200] dB [1..63] −dB

Default NORMAL 200 dB −63 dB

[0..63] dB

Table: Description and value range of the tight BCCH parameters It should not be possible to give BCCHDTCBN and BCCHDTCBP at the same time. Parameters are only valid for internal cells. The value TIGHT of the BCCHREUSE parameter should be represented internally by 1 (one), and NORMAL by 0 (zero). Command syntax: / /sctype\\ RLLOC:CELL=cell|,SCTYPE=+ +| \ \ALL // / +[,BSPWR=bspwr][, BSTXPWR=bstxpwr] \


5 (125)

No.

esteeds Approved

ETE/O/LB-04:000013 Uen

Checked


Date

Rev

2010-12-22

Pa1

Reference

[,BSRXMIN=bsrxmin][,BSRXSUFF=bsrxsuff] [,MSRXMIN=msrxmin][,MSRXSUFF=msrxsuff] [,SCHO=scho][,MISSNM=missnm][,AW=aw] [,EXTPEN=extpen][, HYSTSEP=hystsep] [,ISHOLEV=isholev][,BCCHREUSE=bcchreuse] [,BCCHLOSS=bcchloss] \ +; / //,[,FBOFFSP=fboffsp]\\ |+ +|; \\,[,FBOFFSN=fboffsn]// //,[,BCCHDTCBP=bcchdtcbp]\\ |+ +|; \\,[,BCCHDTCBN=bcchdtcbn]//

The parameters in table 1 should be stored in block RQCD by RQLOA. RQLOA should also fetch the parameters when printout is requested using command RLLOP. 1.1.4

The third ambition level makes it possible to do subcell load distribution from OL to UL subcell based on the amount of traffic in OL subcell

1.1.4.1


1.1.4.2


1.1.4.3

Command Doc. No: 2/190 82-CNT 240 1293 Title: RLLLC Change: Amb lev: 3: A new parameter SCLDSC

The existing command RLLLC is used to change subcell load distribution parameters in a cell. A new optional parameter shall be added to RLLLC. The new parameter SCLDSC will be used to set if the traffic load in underlaid subcell or if the traffic load in overlaid subcell shall be used at subcell load distribution. The value of SCLDSC shall be UL if the traffic load in underlaid subcell shall be used and it shall be OL if the traffic load in overlaid subcell shall be used at subcell load distribution. The default value shall be UL. / RLLLC:CELL=cell+[,SCLD=scld][,SCLDLL=scldll][,SCLDUL=scldul] \ \ [,SCLDSC=scldsc]+; /


No.

esteeds Approved

Checked


1.1.4.4

6 (125)


Rev

2010-12-22

Pa1

Reference

STS Two new STS counters shall be implemented in the existing Object Type CELEVENTSCCNT. The new STS counter OLSCLDCOM shall describe the number of subcell change attempts to overlaid subcell due to subcell load distribution. The new STS counter OLSCLDSUC shall describe the number of successful subcell change to overlaid subcell due to subcell load distribution.

1.1.5

The fourth ambition level improves the operability of multi band cells by adding STS counters for the number of channel group changes due to pathloss and DTCB criteria from BCCH channel group.

1.1.5.1


1.1.5.2


1.1.5.3

Command No impact.

1.1.5.4

STS STS counters shall be added for the functionality Tight BCCH frequency reuse.


7 (125)

No.

esteeds Approved

Checked


Counter BCDTCBCOM BCLOSSCOM BCDTCBSUC BCLOSSSUC


Rev

2010-12-22

Pa1

Reference

Reason for stepping Intra-cell handover attempt out of BCCH channel group, BCCHDTCB criteria Intra-cell handover attempt out of BCCH channel group, BCCHLOSS critera Successful intra-cell handover out of BCCH channel group, BCCHDTCB criteria Successful intra-cell handover out of BCCH channel group, BCCHLOSS criteria

Table 3: STS counters for Intra-cell handover out of BCCH channel group

1.1.6

The fifth ambition level introduces three new CHAPs. This will for example make it possible to have Immediate Assignment on TCH in a multi band cell.

1.1.6.1


1.1.6.2


1.1.6.3

Command Doc. No: 1/190 82-CNT 240 1499 Title: RLHPC Change: Amb lev: 5: Three new CHAPs shall be introduced in order to allow Immediate Assignment on TCH in overlaid subcell Doc. No: 2/190 82-CNT 240 1499 Title: RLHPP Change: Amb lev: 5: Three new CHAPs shall be introduced in order to allow Immediate Assignment on TCH in overlaid subcell For the commands RLHPC and RLHPP, block RCCHPA must be updated to allow the new value range of parameter CHAP. It shall now be extended to 013. This also affects the command descriptions. Three new CHAPs shall be introduced in order to allow Immediate Assignment on TCH in overlaid subcell.


8 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

CHAP 11: OL subcell (only), SDCCH (as first choice), and then TCH. This CHAP will be based on CHAP 8. It also provides a channel allocation strategy at Immediate Assignment on TCH. It will only attempt to allocate a TCH at Immediate Assignment when there are no idle SDCCHs (as it is in CHAP 1). CHAP 12: OL subcell (only), TCH (as first choice), and then SDCCH. This CHAP will be based on CHAP 8. It also provides a channel allocation strategy at Immediate Assignment on TCH. It will only attempt to allocate a SDCCH at Immediate Assignment when there are no idle TCHs (as it is in CHAP 2). CHAP 13: UL subcell (as first choice), then OL subcell, TCH (as first choice), and then SDCCH. This CHAP will be based on CHAP 6. At Immediate Assignment on TCH, TCH allocation will be first choice, as it is in CHAP 2 (only attempt to allocate a SDCCH at Immediate Assignment when there are no idle TCHs). OL subcell can be used as a last resort. 1.1.6.4

STS No impact.

1.2

STS delivery 1 Package: plan

1.2.1

Description Link to IP 1/15941-484/FCP1034829 The total scope of new and changed object types in R12 is split in three STS releases. This IP contains the new and changed object types included in release 1, according to STS delivery plan for BSC R12, 1/100 53-484/FCP 103 4829. The new and changed object types included in Release 2 and 3 will be included in BSS R12, BSC Impacts on STS, Release 2 (2/159 41-484/FCP 103 4829 Uen) and BSS R12, BSC Impacts on STS, Release 3 (3/159 41484/FCP 103 4829 Uen).

1.2.2


1.2.3


1.2.4

Command No impact.


No.

esteeds Approved

Checked


1.2.5

9 (125)


Rev

2010-12-22

Pa1

Reference

STS The object types that will be included in Release 1 are: BSCGPRS CELEVENTI CELEVENTSC CELLGPRS CELLHCS TRAFGPRS2 TRALOST

1.3

409, BTS O&M Improvements Package: RBSFAULTF_1

1.3.1

Description Link to IP 1/159 41-422/FCP 103 4829 The ‘BTS O&M Improvements’ feature will provide the following functionality in the BSC: •

Part 1 – TG Synchronization Improvements

Introduction of TG Cluster instance and improved synchronization of TG’s, which belong to the TG Cluster achieved with automatic calculation and configuration of synchronization parameters and automatic Master TG reselection when synchronization with actual Master fails. •

Part 2 – Improved Fault Filtering

Improved filtering of ‘Remote Transcoder Lost’ fault reports giving more efficient usage of RXELP log area and statistic data collection related to TS Mode when fault occurs. 1.3.2

Part 1 – TG Synchronization Improvements, Ambition Level 1

1.3.2.1

AXE parameter Existing optional feature ‘RBS 2000 Synchronization’ should be active. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=12EXPNDWITHG12, VALUE=1;

1.3.2.2



10 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

1.3.2.3

Command

1.3.2.4

TG Synchronization Improvements

Reference

Doc. No: 2/190 82-CNT 241 1389 Rev: H1 Title: RXMOI Change: Add new parameter CLUSTERID and faultcodes Doc. No: 3/190 82-CNT 241 1389 Rev: H Title: RXMOC Change: Add new parameter CLUSTERID and faultcodes Doc. No: 13/190 82-CNT 241 1389 Title: RXMSC Change: Add new faultcodes

Rev: B

Doc. No: 35/190 82-CNT 241 1111 Rev: B Title: RXMOP Change: Add new parameter CLUSTERID and faultcodes Doc. No: 40/190 82-CNT 241 1111 Title: RXCDP Change: Change function description

Rev: B

RXMOI (existing command) Radio X-ceiver Administration, Managed Object, Initiate Syntax: Managed Object TG In BTS Logical Model G01 RXMOI:MO=mo...,COMB=comb,RSITE=rsite,SWVER=swver [,TRACO=traco]; In BTS Logical Model G12 RXMOI:MO=mo...,COMB=comb,RSITE=rsite,SWVER=swver [,TRACO=traco][,SIGDEL=sigdel][,CLUSTERID=clusterid];

Procedure Printouts: FAULTCODE XX MASTER ALREADY DEFINED IN TG CLUSTER CLUSTERID=clusterid Attempt to define more that one Master TG in the TG Cluster.


11 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

FAULTCODE YY ILLEGAL TF MODE IN TG CLUSTER Attempt to define a TF with Stand-Alone mode in a TG Cluster. FAULTCODE ZZ MAXIMUM NUMBER OF TG IN CLUSTER EXCEEDED CLUSTERID=clusterid Attempt to define more than allowed number of TGs in a TG Cluster. FAULTCODE DD ILLEGAL TF COMPENSATION IN TG CLUSTER Attempt to define external TF compensation in a TG Cluster. Parameters: CLUSTERID=clusterid TG Cluster Identity This parameter represents a TG Cluster Identity. Numeral 0 – 255, UNDEF Default value = UNDEF (undefined)

RXMOC (existing command) Radio X-ceiver Administration, Managed Object, Change Syntax: Managed Object TG In BTS Logical Model G01 / RXMOC:MO=mo...+[,FHOP=fhop][,SWVER=swver][,COMB=comb] \ [,RSITE=rsite][,TRACO=traco][,CONFACT=confact] \ [,CONFMD=confmd][,EMG=emg]+; / In BTS Logical Model G12 / RXMOC:MO=mo...+[,FHOP=fhop][,SWVER=swver][,COMB=comb] \ [,RSITE=rsite][,TRACO=traco][,CONFACT=confact] [,CONFMD=confmd][,SIGDEL=sigdel][,AHOP=ahop] \ [,ABISALLOC=abisalloc][,CLUSTERID=clusterid]+; /

Procedure Printouts:


12 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

FAULTCODE XX MASTER ALREADY DEFINED IN TG CLUSTER CLUSTERID=clusterid Attempt to define more that one Master TG in the TG Cluster. FAULTCODE AA ILLEGAL TF MODE TRANSITION IN TG CLUSTER Attempt to change a TF Mode to Stand-Alone in a TG Cluster. FAULTCODE DD ILLEGAL TF COMPENSATION IN TG CLUSTER Attempt to change TF compensation to value illegal in a TG Cluster. FAULTCODE ZZ MAXIMUM NUMBER OF TG IN CLUSTER EXCEEDED CLUSTERID=clusterid Attempt to define more than allowed number of TGs in a TG Cluster. FAULTCODE CC ILLEGAL CLUSTERID FOR STANDALONE TG Attempt to change CLUSTERID to defined value for Stand-Alone TG. Parameters: CLUSTERID=clusterid TG Cluster Identity This parameter represents a TG Cluster Identity. Numeral 0 – 255, UNDEF

RXMSC (existing command) Radio X-ceiver Administration, Managed Object in Service Data, Change Procedure Printouts: FAULTCODE XX MASTER ALREADY DEFINED IN TG CLUSTER CLUSTERID=clusterid Attempt to define more that one Master TG in the TG Cluster. FAULTCODE AA ILLEGAL TF MODE TRANSITION IN TG CLUSTER


13 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

Attempt to change a TF Mode to Stand-Alone in a TG Cluster. FAULTCODE DD ILLEGAL TF COMPENSATION IN TG CLUSTER Attempt to change TF compensation to value illegal in a TG Cluster. RXMOP (existing command) Radio X-ceiver Administration, Managed Object Data, Print Syntax: In BTS Logical Model G01 / \ |MO=mo... | RXMOP:+ +; |MOTY=moty | \ / In BTS Logical Model G12 / \ |MO=mo... | | | RXMOP:+MO=mo[,CLUSTER] +; | /clusterid\ | |MOTY=moty[,CLUSTERID=| |]| | \ALL / | \ /

Procedure Printouts: FAULTCODE BB CLUSTERID IS NOT DEFINED Attempt to print data for undefined TG Cluster Identity.

Parameters: CLUSTERID=clusterid TG Cluster Identity This parameter represents a TG Cluster Identity. Numeral 0 – 255, Only MOs belonging to a specific TG Cluster will be printed. ALL – MOs belonging to all TG Clusters will be printed. CLUSTER

If parameter is specified and specified MO belongs to a TG Cluster then data for all MOs belonging to the TG Cluster with the same MOTY will be printed. Otherwise only specified MO data will be printed.


14 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT DATA (existing printout) RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT DATA /

\

:::

|/ ||MO ||motg-G12 || || || || || || || || || ||. ||. ||.

RSITE rsite

AHOP COMB [ahop] comb

SWVERREPL [swverrepl] CONFMD confmd TGFID tgfid

SWVERDLD [swverdld]

CONFACT confact

FHOP fhop

MODEL model

SWVERACT [swveract]

TRACO ABISALLOC CLUSTERID traco [abisalloc] [clustered]

SIGDEL sigdel

BSSWANTED [bsswanted]

:::

\| || || || || || || || || || || || || || ||

|\

/|

::: \

/

Parameters: clusterid

The TG Cluster Identity This is an identity of the TG Cluster.

1.3.3

Part 1 – TG Synchronization Improvements, Ambition Level 2

1.3.3.1

AXE parameter Existing optional feature ‘RBS 2000 Synchronization’ should be active. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=12EXPNDWITHG12, VALUE=1; The new optional feature ‘Automatic Master Reselection’ shall be available base upon commercial agreement. The new AXE parameter MASTERRES (Automatic Master Reselection) shall be added within the existing set CME20BSCF, which will be used to enable/disable the feature. Value 1 will be used to enable the feature, value 0 will be used to disable the feature. The possibility to enable this feature will depend on if existing optional feature ‘RBS 2000 Synchronization’ is enabled (AXE parameter 12EXPNDWITHG12 set to 1). DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME= MASTERRES, VALUE=1;


No.

esteeds Approved


Checked


1.3.3.2

15 (125)

Date

Rev

2010-12-22

Pa1

Reference

Exchange Property New Exchange Property EXMASTERRES shall be introduced to allow the operator to activate/deactivate the Automatic Master Reselection functionality. Value 1 will be used to activate the functionality, value 0 will be used to deactivate the functionality. RAEPC:PROP=EXMASTERRES-1;

1.3.3.3

Command This feature also improves the ISP of cells in TG clusters by introducing automatic master reselection. This means that a new master is selected automatically if the former master is unable to provide timing information to the slaves in the TG cluster. No intervention from the operator is needed any more. This also reduces the operation and maintenance cost for the operator. This is part of the new optional feature ‘Automatic Master Reselection’ introduced by Ambition Level 2 as an extension to Ambition Level 1. In the existing printout ‘RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT DATA’ parameter TFAUTO (TFMODE Automatic) for MO-TF shall be added. When Automatic AXE parameter MASTERRES is set to 1 and the Exchange Property EXMASTERRES is set to 1 then for TF belonging to a TG Cluster parameter TFAUTO shall be printed with value YES. Otherwise value NO shall be printed.

RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT DATA /

:::

| |/ ||MO ||motf-G12 || . || . || . ||motf-G12 |\

TFMODE tfmode . . . tfmode

\

| \| SYNCSRC TFCOMPNEG TFCOMPPOS FSOFFSET TFAUTO || syncsrc [tfcompneg][tfcomppos][fsoffset][tfauto]|| . . . . . || . . . . . || . . . . . || syncsrc [tfcompneg][tfcomppos][fsoffset][tfauto]|| /|

::: \

/

Note: Two spaces between 1st and 2nd column needs to be removed in the printout. Parameters: tfauto

Parameter specifies if automatic TFMODE configuration is used. YES

TFMODE set automatically, printed value of TFMODE and current value of TFMODE may differ. Use RXCDP to get current value of TFMODE.

NO

TFMODE set according to printed value.


No.

esteeds Approved

Checked


1.3.3.4

16 (125)


Rev

2010-12-22

Pa1

Reference

STS No impact.

1.3.4

Part 2 – Improved Fault Filtering

1.3.4.1

Description This feature introduces improved 'Remote Transcoder Lost' fault handling in the BSS. This reduces the risk of overwriting the RXELP log in the BSC and decreases the signaling load on the A-bis transmission link. It is achieved by moving the fault reporting from TS to TRXC level and by filtering fault reports during OML failure (the second action is performed in the BTS only). This feature also introduces the statistical counters related to TS Mode, for which the 'Remote Transcoder Lost' fault occurs and is reported. Introduction of this feature reduces also a risk to get into congestion on A-bis interface due to too many Fault Report messages.

1.3.4.2


1.3.4.3

Exchange Property’ No impact.

1.3.4.4

Command No impact.

1.3.4.5

STS New DID and new counters introduces the statistical counters related to TS Mode.

2

Shipment 2

2.1

81, HCS Enhancements Package: HCSE_1

2.1.1

Description Link to IP 1/159 41-402/FCP 103 4829


17 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Today there is traffic imbalance between layers in HCS: cells in higher prioritized layers may become congested, while cells in lower prioritized layers have free capacity. There are unwanted handovers to cells in lower prioritised layer when the handover to the (only one) higher prioritized target cell failed due to that it was congested. This IP describes how the HCS algorithm is modified to prioritize more than one cell in the same layer in the candidate list. This proposal includes also new HCS traffic distribution functionality in Locating. It shall be possible to set thresholds for a cell, so that the possibility to do HCS handover in and HCS handover out from a cell shall depend on the current traffic load in the cell. At low traffic load in a cell, HCS handover out cannot be done, and at high load in a cell, it cannot be possible to do HCS handover into this cell. 2.1.2

AXE parameter All new functionality, will be part of the existing optional feature “Multi Layer Hierarchical Cell Structures” (HCSBAND), set with “HCS with 8 layers and 8 HCS bands”. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=HCSBAND, VALUE=1;

2.1.3

Exchange Property RAEPC:PROP= MAXCELLSINLAYERRAEPC:PROP= MAXDBDEVINLAYERRAEPC:PROP= HCSTRAFDISSTATERAEPC:PROP= HCSCHAVAILTIMER-

•

MAXCELLSINLAYER defines the number of cells that can be prioritized by HCS in the same layer.

•

MAXDBDEVINLAYER defines the maximum value in dB that a cell in a layer can deviate from the strongest cell in the same layer and still be prioritized by HCS.

•

HCSTRAFDISSTATE is used to enable/disable the HCS Traffic Distribution State for all the cells in a BSC, and thus it will start/stop the monitoring of the channel availability for the active cells.

•

HCSCHAVAILTIMER defines the load evaluation time for HCS.


18 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Exchange property

Value range

Default value

Owned by

MAXCELLSINLAYER

1 - 31

1

RQUPD

MAXDBDEVINLAYER

0 - 63 dB

3 dB

RQUPD

HCSTRAFDISSTATE

0 (OFF) 1 (ON)

0 (OFF)

RQUPD

HCSCHAVAILTIMER

200 – 5000 ms

500 ms

RQRCQS

HCSCHAVAILTIMER shall always be a multiple of 100ms. It shall be possible to modify the values of the new Exchange Properties ONLY when there is support for the optional feature ”Multilayer Hierarchical Cell Structure” set with 8 layers and 8 bands. This means that the blocks that own these Exchange Properties shall make this check. 2.1.4

Command The existing command RLLHC shall change the values of the new HCS traffic distribution parameters HCSOUT and HCSIN on a cell basis. •

HCSOUT: HCS traffic distribution level threshold to allow HCS handover out from a cell. Value range is 0 – 100% and default value shall be 100%. It shall be possible to allow HCS handover out from the serving cell when the channel availability of the serving cell is below or equal its HCSOUT threshold. The default value for HCSOUT implies that it shall always be possible to allow HCS handover out from the serving cell. This parameter is only valid for serving cells.

•

HCSIN: HCS traffic distribution level threshold to allow HCS handover into a cell. Value range is 0 – 100% and default value shall be 0%. It shall be possible to allow HCS handover into an internal neighbour cell when the channel availability of the neighbour cell is above or equal its HCSIN threshold. The default value for HCSIN implies that it shall always be possible to allow HCS handover in to the internal neighbour cell. This parameter is only valid for internal neighbour cells.


No.

esteeds Approved

Checked


2.1.5

19 (125)


Rev

2010-12-22

Pa1

Reference

STS Two new STS counters per cell are added. TIMEHCSOUT accumulates time in seconds when the serving cell’s channel availability is below or equal to HCSOUT. TOTTIMEHCSACTIVE measures the total time in seconds that the HCS traffic distribution has been activated in the cell (during the STS measurement period). These counters shall be included in the object type CELLHCS.

2.2

466, R12 Impact on Data Transcript Package: BTSIMPR_1, BTSIMPR_2

2.2.1

Description Link to IP 1/159 41-432/FCP 103 4829 The implementation of RBS System Improvements R12 is divided into six ambition levels referred to as sub-features: 1. Faster Internal Function Change 2. Faster External Function Change 3. Improved File Relation Request 4. BTS Automatic Restart After Very Long Link-break 5. LAPD Multiplexing Queuing Alarm 6. Improved LED Handling During Function Change This IP covers only ambition level 5 – LAPD Multiplexing Queuing Alarm. This sub-feature is valid only for the BTS logical model G12. The rest of ambition levels concern the BTS node and will be implemented there. The purpose of developing such feature is that the operator does not get any information from the system that an overload situation on the multiplexed LAPD communication link exists. No indication leads to the state that the operator might not take necessary measures in time to correct the overload situation and congestion may decrease the efficiency of the Abis link. To avoid such situation a new fault condition for the overload LAPD multiplexing is introduced. The operator will receive alarm that the network generates more uplink signalling traffic than planned. Thus the network operator is informed that the network is not properly dimensioned and can act to correct the situation.


No.

esteeds Approved

Checked


2.2.2

20 (125)


Rev

2010-12-22

Pa1

Reference


2.2.3


2.2.4

Command New value for existing parameters ALMASK and ALSIT in command RXALC shall be added. This value will indicate a new alarm situation – congestion on LAPD multiplexing queue. Thus the operator will have the opportunity to mask such alarm situation and to coordinate this type of alarm on managed objects level. New alarm situation will be visible on printouts received by commands for printing alarm coordination data (RXALP) or printing alarm situations (RXASP). Handling of printing data should be handled as in design base. RXALC (existing command): Radio X-ceiver Administration Alarm Coordination Data, Change Parameters: ALMASK=almask

Alarm Situation Mask Indication of the type of Alarm Situation to be masked. MPLXQ

ALSIT=alsit

MPLEX QUEUE CONGESTION

Alarm Situation Indication of the type of Alarm Situation for which Alarm Class is to be set. MPLXQ


Table 2: New ALMASK and ALSIT parameters value in command RXALC.


21 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

RADIO X-CEIVER ADMINISTRATION ALARM COORDINATION DATA (existing printout) Parameters: ALMASK=almask

Alarm Situation Mask Indication of the type of Alarm Situation for which masking is set. MPLXQ

ALSIT=alsit


Alarm Situation Indication of the type of Alarm Situation for which Alarm Class is set. MPLXQ


Table 3: New ALMASK and ALSIT parameters value.

RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT ALARM SITUATIONS (existing printout) Parameters: alarm situation The alarm situation provides the type of fault in the indicated managed object. The following alarm situations are possible (listed In the alphabetical order): MPLEX QUEUE CONGESTION An overload situation on the LAPD Multiplexing queue exists. Table 4: New alarm situation.

BTS Alarm Print To indicate LAPD multiplexing congestion situation, raised alarm for CF managed object or for TG (depending on coordination level set) will show a new alarm slogan about multiplexing queue congestion.


22 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT FAULT (existing printout) Parameters: alarm slogan The alarm situation provides the type of fault in the indicated managed object. The following alarm situations are possible (listed in the alphabetical order): MPLEX QUEUE CONGESTION An overload situation on the LAPD Multiplexing queue exists. Table 5: New alarm slogan.

RADIO X-CEIVER ADMINISTRATION TRANSCEIVER GROUP FAULT (existing printout) Parameters: alarm slogan The alarm situation provides the type of fault in the indicated managed object. The following alarm situations are possible (listed in the alphabetical order): MPLEX QUEUE CONGESTION An overload situation on the LAPD Multiplexing queue exists. Table 6: New alarm slogan.

2.2.5

STS No impact.

2.3

467, System Improvements for BSC Package: DECRGRC_1


No.

esteeds Approved

Checked


2.3.1

23 (125)


Rev

2010-12-22

Pa1

Reference

Description Link to IP 1/159 41-427/FCP 103 4829 The whole architecture in BG-GRC must admit continuing development and maintenance of GPRS functionality. The blocks in BG-GRC are required to be reconstructed in order to reduce the block size and complexity. This will reduce the product size and facilitate new GPRS features to be implemented.

2.3.2


2.3.3


2.3.4

Command

2.3.5

STS Object Type CELLGPRS CELLMOVED The counter shall be moved from RGRLCU to RGCNTU.

2.3.6

HW No impact.

2.4

368, R12 Impact on Data Transcript Package: RPMO_5

2.4.1

Description Link to IP 1/159 41-430/FCP 103 4829 The enhancements described by this IP cover seven different areas: •

Scalable solution

•

Load regulation

•

Event Handling Framework Improvements

•

New event notifications

•

R-PMO Improvements


24 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

•

GMLOG Improvements

•

Open Event Notification Interface

Reference

The main purpose with event handling in R12 is to improve the event handling due to growing quantities of event data. The purpose for the R-PMO application is to work as a complement to STS as well as continue to be a trouble shooting tool and optimization tool. The Event Handling Framework (EHF) is a framework that provides an efficient way to pass event data from the CP, TRH and from individual GPH RP units to any event consumer 2.4.2

AXE parameter Open Event Notification Interface. RGSERVU shall be owner of the new optional feature parameter for this application. Proposed parameter name is OPENEVENTIF. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=OPENEVENTIF, VALUE=1;

2.4.3


2.4.4

Command Interface to IP Connectivity. The Master Event Server, MES shall if available use an RPP installed in a slot with 100Mbps capability. To support this, a new parameter must be added to the RRIPI command that states preferred capabilities for RP (100 Mbps slot). RTIP can retrieve the information via BIOS but preferably it shall be done via RPEXL (APZ CXA). RGSERVCU shall handle the new AID for RAPMI/E/P commands.

2.4.5

STS No impact.

2.4.6

HW Dedicate RPP for MES In R11 an RPP may be dedicated to event traffic using commands. In R12 redundancy shall be combined with dedication of RPP to event traffic. When the MES is moved to a new RPP the new RPP handles cells, if the RPP shall be dedicated to event traffic those cells needs to be moved to another RPP. But, there is no way to guarantee that there is another RPP that can take over those cells. Therefore automatic dedication is not feasible.


25 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The proposal is to appoint two RPPs to event handling. The recommendation is to block all devices and only use one RPP as master and the other as hot stand-by. In the case the operator doesn’t want do dedicate two RPPs to event traffic only, devices can be deblocked and the RPPs can execute both event traffic and GPRS traffic. The drawback is that the event traffic is executed on background priority and when ordinary traffic handling executing on higher priority level increases (when deblocking devices) the event handling can start load regulate, i.e. discard event notifications. The proposal is to solve redundancy using a standby-RPP and fail over will be between those two dedicated RPPs (RPPs placed in 100Mbps position in two different racks). When dedicating an RPP for event traffic only the BLODI and NTCOE commands shall be used. This solution requires no software implementation only changes to the OPI “BSC, Dedicated RP Resource for Event Handling, Change”. Dedication of RPP for event traffic only shall be done in the same way as in R11.

3

Shipment 3

3.1

390.1, R12 Impact on Data Transcript Package: PCUCAP_1, PCUCAP_2

3.1.1

Description Link to IP 1/159 41-411/FCP 103 4829 The BSC shall have the capacity to set up 8192 simultaneous GPRS/EGPRS physical channels towards the base stations in order to provide 50% GPRS utilization even for a 2048 TRX BSCs. To accomplish this, the maximum numbers of PCU RPPs to be supported by a BSC shall be increased from 64 to 128. The upgrade to 128 RPPs is only valid for HWM501 cabinets.

3.1.2


3.1.3


3.1.4

Command Doc. No: 1/190 82-CNT 242 1221 Uen Rev:A Title: RRIPI - Radio Transmission, IP Parameters, Initiate


26 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Change: Increase maximum allowed IP addresses from 256 to 512. GPRS, IP Connectivity Handling Maximum number of IP addresses per PCU shall be increased from 256 to 512. The number of maximum IP addresses per IP Device remains the same as in the designbase (32). 3.1.5

STS

3.1.5.1

New or Modified Counters -

3.1.5.2

Affected Counters The number of STS counters kept by CM file will increase from 64 to 128. This indirectly impacts following STS counters in the GPH. -

No of On Demand 16 kbps per RP

-

No of On Demand 64 kbps per RP

-

RPPLOAD

The counter values or meaning is not changed. 3.1.6

HW The upgrade to 128 RPPs is only valid for HWM501 cabinets. No verification of 128 RPPs is to be made using BYB202.

3.2

390.2, Increased PCU capacity - Traffic Capacity Package: PCUCAP_1, PCUCAP_2

3.2.1

Description Link to IP 2/159 41-411/FCP 103 4829 The total capacity of the BSC to handle throughput of GPRS/EGPRS traffic in R12 shall be doubled compared to BSC R10. To accomplish this, the maximum number of PCU RPPs to be supported by the BSC is to be increased from 64 to 128. To fully accomplish this, the capacity of an RPP in the PCU shall not be decreased compared to R10, even though the number of features that are handled in the RPP will be increased in R11 and R12. The improvements, in order to decrease the load on the RPPs, are divided into two parts.


27 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The first part is to improve the code running on the RPP. A list of possible improvements has been prototyped and tested. Those that significantly reduce the CPU load and the memory usage in the PCU are to be implemented. If possible, the change shall be implemented as a design rule. The second way to reduce the CPU load is to decrease the number of PDCHs that do not carry any traffic. Most of the proposed changes do affect all blocks in the PCU but since RGMACR and RGRLCPR are the major consumer of execution time, improvements in these units will be the most effective to add improvements to. 3.2.2


3.2.3

Exchange Property The format of the TBFLIMIT parameters is to be changed. The parameters shall be possible to be set on decimal level, limited to one decimal. •

TBFULLIMIT

Temporary Block Flow Uplink Limit Value range: 1.0 – 6.0 (10-60), default value: 2.0 (20) Coded as follow: 10 = 1.0 11 = 1.1 . . 60 = 6.0

•

TBFDLLIMIT

Temporary Block Flow Downlink Limit Value range: 1.0 – 8.0 (10-80), default value: 2.0 (20) Coded as follow: 10 = 1.0 11 = 1.1 . . 80 = 8.0

It is suggested that the value in the command is given in the same format as the parameters are coded (10-60/80) in. RAEPC:PROP=TBFDLLIMIT-20; RAEPC:PROP=TBFULLIMIT-20;


28 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The default value of parameter PILT (PIL Timer) is to be changed from 20 to 10 seconds. The recommended value was changed to 10 seconds already in R11. RAEPC:PROP=PILTIMER-10; 3.2.4

Command No impact.

3.2.5

STS No impact.

3.2.6

HW No impact.

3.3

40, GPRS/EGPRS Performance Booster Package: MSCLASS_ULDL_1

3.3.1

Description Link to IP 1/159 41-408/FCP 103 4829 GPRS/EGPRS Performance Booster consists of two parts: •

Support for new MS multislot classes

•

Dynamic UL/DL Handling improvements

The new multislot classes will make it possible to use up to 5 timeslots downlink, and the improved dynamic UL/DL handling introduces a neutral uplink/downlink reservation, which improves performance for applications where there are streams of uplink data and downlink data in parallel. 3.3.1.1

Support for New MS Multislot Classes MS multislot classes 1 to 45 are supported already in the design base, where MS multislot class 30 to 45 are mapped to MS multislot class 8, 10, 11 or 12. The support for new MS multislot classes feature introduces a full support for MS multislot class 30 to 33, and a changed mapping for multislot class 34 to 45. The feature shall be an optional feature and shall be possible to turn on and off per BSC. If the feature is turned off, the MS multislot classes shall be handled as in the design base.


esteeds Approved

No.

Checked


3.3.1.2

29 (125)


Rev

2010-12-22

Pa1

Reference

Dynamic UL/DL Handling Improvements Dynamic UL/DL Handling is an optional feature already existing in the design base. The feature shall be improved by the following changes: 1. Introduce new TBF data buffer level definitions 2. Introduce a neutral UL/DL state (close to equal number of TS in UL and DL) 3. Introduce a new algorithm for when to switch between UL/DL states and a new way to do it. The neutral state (for other QoS classes than EIT Streaming) and changes to and from the neutral state shall be a new optional feature. The dynamic UL/DL handling improvements affects the Candidate List interface and a rework of the interface shall be done to simplify the Candidate List handling.

3.3.2

AXE parameter A new BSC wide optional feature, Support for new MS multislot classes, (GPRS5TSDL) shall be introduced to switch on support for the MS multislot classes 30 to 33. The proposal for the optional feature is: The GPRS5TSDL shall have the following possible values: 0 = FEATURE UNAVAILABLE 1 = FEATURE AVAILABLE The default value shall be 0. The CLASS of the parameter shall be ‘FEATURE’ and the distribution shall be ‘IMMEDIATE’. The parameter shall be implemented in RGRLCU. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=GPRS5TSDL, VALUE=1; A new BSC wide optional feature, Dynamic UL/DL Handling improvements, (GPRSNEUTRAL) shall be introduced to switch on support for the neutral state for dynamic UL/DL handling. The proposal for the optional feature is: The GPRSNEUTRAL shall have the following possible values: 0 = FEATURE UNAVAILABLE 1 = FEATURE AVAILABLE The default value shall be 0. The CLASS of the parameter shall be ‘FEATURE’ and the distribution shall be ‘IMMEDIATE’. The parameter shall be implemented in RGRLCU.


30 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=GPRSNEUTRAL, VALUE=1; 3.3.3

Exchange Property New BSC Exchange Properties shall be implemented for the new optional features, to be set by operator command (RAEPC). The exchange properties shall be owned by RGRLCU. Note that there is a relation to the feature “Required Decrease of Block Sizes within BG-GR” for property handling. •

GPRS5TSDLACT – Support for MS multislot classes 30 to 33 0 = FEATURE OFF 1 = FEATURE ON The default value shall be 0 and it shall only be possible to change the value to 1 if the global parameter GPRS5TSDL indicates that the feature is available. The default value of GPRS5TSDLACT is 0 (feature off).

•

GPRSNEUTRALACT – Neutral state for dynamic UL/DL handling 0 = FEATURE OFF 1 = FEATURE ON The default value shall be 0 and it shall only be possible to change the value to 1 if the global parameter GPRSNEUTRAL indicates that the feature is available. The default value of GPRSNEUTRALACT is 0 (feature off).

RAEPC:PROP=GPRS5TSDLACT-1; RAEPC:PROP=GPRSNEUTRALACT-1;

3.3.4

Command No impact.

3.3.5

STS New statistics counters to be introduced in RGRLCR (r_chhcell) are further described Support for New MS Multislot Classes


31 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The feature introduces 5 new statistics counters per cell: • • • • •

MUTIL15 MUTIL25 MUTIL35 MUTIL45 MUTIL55

MUTILXY describe the number of used timeslots, X, in relation to the maximum number of timeslots that can be used, Y. The counters shall be handled in the same manner as the related utilization counters in the design base. The counters shall be reported from RGRLCR (r_chhcell) to RGCNTR (f_cperfdata) in the existing signal RGGETUSEDPDCHSR. The counters shall be transferred from RGCNTR (f_cperfdata) to RGCNTU for storage to be accessed by STS. The new counters shall be placed in a new DID, called TRAFGPRS2CNT2. This is needed because the existing DID TRAFGPRS2CNT contains 23 counters and a DID cannot contain more than 25 counters. The counters from both TRAFGPRS2CNT and TRAFGPRS2CNT2 fit into the object type TRAFGPRS2, since an object type can contain up to 30 counters. 3.3.6

HW No impact.

3.4

368, R12 Impact on Data Transcript Package: RPMO_1 See description in Shipment 2.

3.5

467, System Improvements for BSC Package: SUP_1

3.5.1

Description No IP available.


32 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

3.5.2

AXE parameter

3.5.3

Exchange Property

3.5.4

Command

3.5.5

STS

3.5.6

HW

3.6

25, GPRS/EGPRS Load Optimization

Reference

Package: LOADOPT_1 3.6.1

Description Link to IP 1/159 41-417/FCP 103 4829 In cases where two or more TBFs share the same radio resources and there is a TBF with low throughput due to bad radio conditions, that TBF shall be scheduled more seldom. In that way the TBFs with better radio conditions, and thus better throughput, will be scheduled more often. This leads to that the users with good throughput in the system can increase their throughput at high load situations. This might in turn lead to that those users utilize the GPRS/EGPRS services more, which would increase the revenues of the operator. It shall also be possible for the operator to prioritize between GPRS and EGPRS users. To determine if a TBF should be put in low scheduling, the radio conditions shall be evaluated against the radio link bitrate of the TBF. For a downlink TBF the radio link bitrate depends on the coding scheme it is using and the ratio of retransmissions it has. For an uplink TBF the radio link bitrate depends on the combination of coding scheme and ratio of failed USF schedules. In order to put a TBF in low scheduling mode, the TBF shall fulfill the following conditions: •

Quality of Service (QoS) classes Interactive and/or Background

•

The data volume level for the TBF is Medium or Large

•

MAC mode is Dynamic Allocation (uplink)

The priorities between the different QoS classes shall not be affected. GPRS Load Optimization shall however function even if the QoS feature is not activated.


No.

esteeds Approved

Checked


3.6.2

33 (125)


Rev

2010-12-22

Pa1

Reference

AXE parameter A new BSC wide optional feature shall be introduced to switch on support for GPRS Load Optimization. The proposal for the optional feature is: •

Global Parameter: GPRSLOADOPT

GPRSLOADOPT shall be a Commercial Market Parameter and shall have the following possible values: 0 = FEATURE UNAVAILABLE 1 = FEATURE AVAILABLE The default value shall be 0. The CLASS of the parameter shall be ‘FEATURE’ and the distribution shall be ‘IMMEDIATE’. The value shall be given on a commercial agreement basis only. The parameter shall be implemented in RGRLCU. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=GPRSLOADOPT, VALUE=1;


No.

esteeds Approved

Checked


3.6.3

34 (125)


Rev

2010-12-22

Pa1

Reference

Exchange Property New BSC Exchange Properties shall be implemented for the new optional feature. The exchange properties shall be owned by RGRLCU and shall be checked and set by the function block ROEPC (subsystem ROS). •

LOADOPT – Support for GPRS Load Optimization 0 = FEATURE OFF 1 = FEATURE ON FOR BACKGROUND 2 = FEATURE ON FOR BACKGROUND AND INTERACTIVE The default value shall be 0 and it shall only be possible to change the value if the global parameter GPRSLOADOPT indicates that the feature is available.

•

LOPTGTHR – Radio link bitrate threshold for GPRS TBFs The threshold defines when a GPRS TBF is considered to be in a bad radio environment. The radio link bitrate is measured per PDCH. Valid for both downlink and uplink. Value range: 0 – 20 kbps The default value shall be 3 kbps and it shall only be possible to change the value if the global parameter GPRSLOADOPT indicates that the feature is available.

•

LOPTETHR – Radio link bitrate threshold for EGPRS TBFs The threshold defines when an EGPRS TBF is considered to be in a bad radio environment. The radio link bitrate is measured per PDCH. Valid for both downlink and uplink. Value range: 0 – 60 kbps The default value shall be 10 kbps and it shall only be possible to change the value if the global parameter GPRSLOADOPT indicates that the feature is available.

The setting of parameters LOPTGTHR and LOPTETHR can be used to differentiate GPRS users from EGPRS users. RAEPC:PROP=LOADOPT-1; RAEPC:PROP=LOPTGTHR-3; RAEPC:PROP=LOPTETHR-10;


No.

esteeds Approved

Checked


3.6.4

35 (125)


Rev

2010-12-22

Pa1

Reference

Command No impact.

3.6.5

STS No impact.

3.6.6

HW No impact.

3.7


3.7.1

Description No IP.

3.7.2

AXE parameter

3.7.3

Exchange Property

3.7.4

Command

3.7.5

STS

3.8

413, Mega BSC – Support for 1024 cells Package: MEGA_1

3.8.1

Description Link to IP 1/159 41-425/FCP 103 4829 The number of 512 internal cells is not enough to give enough flexibility for the average operators in their cell planning. BSC nodes that can handle more cells have definite benefits in situations where the number of TRXs grows above 1020. With this feature 1024 internal cells, 2048 external cells and 32768 neighbouring cell relations shall be supported. The system limits for external UTRAN cells and UTRAN cell relations were already increased in BSS R11 and therefore not impacted. The new increased system limits which this feature introduces are only applicable for APZ 212 30, APZ 212 33 and APZ 212 33C. If IOG20 is used a very limited number of statistical counters will be supported.


No.

esteeds Approved

Checked


3.8.1.1

36 (125)


Rev

2010-12-22

Pa1

Reference

Affected SAE’s A new local SAE is introduced for the neighbouring cell relation file in block RQCD. The maximum file size for the internal cell file (SAE298) shall be increased from 512 to 1024 and for the external cell file (SAE299) from 512 to 2048. The maximum file size for both the internal handover counter file (SAE522) and the external handover counter file (SAE523) shall be increased from 8192 to 32768. The maximum file size for the message page file (SAE997) shall be increased from 8192 to 16384. The maximum file size for the LCH file (SAE1153) shall be increased from 73216 to 73728.

3.8.2


3.8.3


3.8.4

Command No impact.

3.8.5

STS The total number of counters will increase due to the increased number of cells and cell relations. No new counters will be introduced with this feature. The maximum number of STS counters will increase with about 836.000, due to the increased number of cells and cell relations. If the new total number of STS counters exceeds the limitations in APG40 is not known at this stage but is currently under investigation.

3.8.6

HW No impact.

4

Shipment 4

4.1

104, Tandem Free Operation Package: TFO_1, TFO_9, TFO_2 (TFO_6&7), TFO_3 (TFO_6&7&8), TFO_4 (TFO_6&7&8)


No.

esteeds Approved

Checked


4.1.1

37 (125)


Rev

2010-12-22

Pa1

Reference

Description Link to IP 1/159 41-410/FCP 103 4829 Tandem Free Operation (TFO), as specified by 3GPP, is intended to avoid the traditional double speech encoding/decoding in MS to MS call configurations in GSM (or MS to UE for GSM/3G or UE to UE for 3G networks). In a normal MS to MS call configuration the speech signal is first encoded in the originating MS, sent over the air interface, coded into G.711 PCM format, carried over the fixed network, transcoded again in the distant transcoder, sent over the distant air interface and finally decoded in the terminating MS. In this configuration, the two speech codec are in “Tandem Operation”. The major drawback of a tandem configuration is the speech quality degradation introduced by the double transcoding. Both encoding functions can be bypassed if the originating and terminating connections are using the same speech codec. Then it is possible to transmit transparently the speech frames received from the originating MS to the terminating MS without activating the transcoding functions in the originating and terminating networks. In this configuration, “Tandem Free Operation” is on going. The impacts of the introduction of TFO can be split in two main areas:

•

All is needed to manage and administrate the TFO feature

•

All is needed to purely handle the TFO protocol frames The impacts due to TFO protocol handling affect BG-TRA RPI and DSP software. For these impacts refer to [IP2] and [IP3]. The first bullet refers to impacts needed on RTS and RCS CP software. 4.1.1.1

TFO support on TRA R6 CSPB 1.0 and R6 CSPB 1.1 The report [QSR-1] states that the TFO ESW requires a supplementary data memory that forces to reduce the number of channels that a TRA R6 Cicero (CSPB 1.0), configured with AMR-FR or AMR-HR codec, can handle. In a board CSPB 1.0 there are 8 ASIC Cicero. No channel reduction applies for a Capella in a CSPB 1.1. Furthermore, some checks have been shown that the same memory constraint applies for EFR codec too so the same channel reduction shall be applied also for that codec. In particular with a CSPB 1.0 the present 24 channels per Cicero will decrease to become 16 (meaning that each PAM/DSP can handle 2 channels instead of 3: 1/3 are lost), so a board cannot handle 192 channels any more. Figure summarizes what happens when TFO is activated.


esteeds Approved

38 (125)

No.

Checked


CICERO configured with FR or HR codec

CICERO configured with EFR, AFR or AHR codec


Rev

2010-12-22

Pa1

Reference

24 ch

CAPELLA configured with FR or HR codec

24 ch

16 ch

CAPELLA configured with EFR, AFR or AHR codec

24 ch

CSPB 1.0

CSPB 1.1 TFO ACTIVATED FigureTFO ACTIVATED

At the moment the different characteristics between the two boards are not handled at all by the applications due to required backward compatibility but with the introduction of TFO the two boards can not be considered equivalent any more, unless to continue to accept a reduced use of the CSPB 1.1 as it was CSPB 1.0. The different channel combination to be handled for the two HW platforms implies to introduce a mechanism to distinguish the two HW boards in the CP SW. See chapter Command 4.1.2

AXE parameter Optional feature handling shall be implemented with a new AXE feature parameter (TFO is the proposed name) in CME20BSCF parameter set. Block RMHBI (in RCS subsystem) shall be TFO feature owner. The default value shall be ‘OFF’. The Ordering Information at BSC level shall be updated to include that new parameter. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=TFO, VALUE=1;


esteeds Approved

39 (125)

No.

Checked



Rev

2010-12-22

Pa1

Reference

4.1.3

Exchange Property

4.1.3.1

A new BSC exchange property (TFOSTATUS is the proposed name) belonging to TFO feature shall be introduced to activate TFO support in a BSC for EFR, AMR-FR and AMR-HR codec types on transcoder based on R6 HW platform. Blocks RMHBI and RMHTR (in RCS subsystem) shall be defined as owners of TFOSTATUS exchange property. The default value shall be ‘OFF’. RAEPC:PROP=TFOSTATUS- ;

4.1.3.2

µ -Law PCM Encoding Type. In order for a TFO connection to be established, e2e transparency between the two transcoder devices must be maintained. This means that any IPE must be removed or must be made compliant with the TFO protocol. To obtain this e2e transparency, at least into transcoders, it is necessary to move the µ -Law coding from the ET on the A-interface to the TRA in Ericsson BSS for TFO calls requiring µ -Law coding (i.e. where ANSI 24 channels transmission is used). As TFO shall be released only for EFR, AMR-FR and AMR-HR codec types, only these codec types working on TRA R6-family devices shall be able of coding and decoding PCM traffic according to both ALaw and µ -Law principles. A new BSC exchange property (PCMLAW is the proposed name) shall be introduced to set PCM law type on A-interface. Block RTACC (in BG-TRANSMDEV) shall be defined as owner of PCMLAW exchange property. The default value shall be ‘A-Law’. All transcoders devices shall be considered within BSC R12 product able to use A-law by default; the TRA R6-family devices that are TFO capable shall be also able to change the current PCM law (from/to µ -law) in a dynamic way during call setup. RAEPC:PROP=PCMLAW- ;

4.1.3.3

The TFO feature deployment on TRA R6 application (CSPB 1.0 based) implies a channel reduction from 24 to 16 channels for each ASIC supporting TFO (i.e. configured with EFR, AMR-FR or AMR-HR codec type), so in order to configure these boards to support TFO it is needed to EM block and EM deblock all related SNT individuals, as described by the operational instruction included below. It is proposed to introduce a new BSC exchange property (TFOCONFIGTRA is the proposed name) aiming to trigger that blocking/deblocking for the R6 boards. Block RTTGS (in BG-TRA) shall be defined as owner of TFOCONFIGTRA exchange property.


40 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The default value shall be ‘OFF’. All TRA R6 boards can be configured to support TFO by giving command RAEPC: RAEPC:PROP=TFOCONFIGTRA-1; 4.1.4

Command

4.1.4.1

The current TRA R6 Device Owner (block RTTGD), SNT Owner (block RTTGS) and RPI (block RTTGSR) shall be updated to implement that mechanism and to handle in the proper way the different channel capacity of the two boards when TFO is activated. The proposal is to introduce a new SNT variant value to connect/distinguish a new installed R6 board CSPB 1.1. In that case the SNT connection command for a new CSPB 1.1 shall be: NTCOI:SNT=RTTGS-n,SNTP=sntp,MODE=256,SNTV=2; (for CSPB 1.1) while for a CSPB 1.0 shall remain as it is now: NTCOI:SNT=RTTGS-n,SNTP=sntp,MODE=256,SNTV=1; (for CSPB 1.0) The printout related to command NTCOP shall report the SNT variant for an SNT by giving the evidence to the operator about the different HW type.

4.1.4.2

By summarizing 2 concepts can be identified: -

TFO activation, belonging to the intention of the customer to start using TFO. This set acts on BSC.

-

TFO configuration, belonging to the capabilities of TRC to support TFO, regardless the time the customer wants to begin to use them.

In this way, the TRC looks like a platform that offers its capabilities as services to BSC, regardless their actual use asked by BSC according to its own settings. 4.1.4.3

TFO activation/deactivation procedure

[BG-CPR] An operational instruction at BSC level shall contain the handling of TFO AXE feature parameter (TFO) and BSC exchange property (TFOSTATUS). It shall include a reference to the operational instruction at BG-TRA level, including the handling of TFOCONFIGTRA exchange property. See below. 4.1.4.4 [BG-TRA], [OSS]

TFO configuration procedure


esteeds Approved

41 (125)

No.

Checked



Rev

2010-12-22

Pa1

Reference

The complete operational instructions related to the handling of TFOCONFIGTRA BSC exchange property is reported below. The TFO configuration procedure in a TRA R6 board shall introduce a traffic disturbance that can be approached by operator in two different ways. The first one can be named ‘soft and slow’ and it implies to block and deblock each installed TRA R6 board one at time by having that the TFO deployment shall take a long time but with a very limited traffic disturbance; the second one can be named ‘strong and quick’ and it implies to block and deblock all installed TRA R6 boards at the same time by having that the TFO deployment shall take a short time but with a high traffic disturbance possibly not acceptable. Of course the best approach does not exist in absolute sense; it shall depend on BSC real configuration. The operational instructions listed below, to be included in a new OPI document, are aiming to deploy TFO by following the ‘soft and slow’ way. 1. Start TFO configuration. All TRA R6 boards can be configured to support TFO by giving command RAEPC: RAEPC:PROP=TFOCONFIGTRA-1; [RAEPC:PROP=TFOCONFIGTRA-0;] After command execution, the BSC exchange property owner block (RTTGS) shall just register the new value in a common variable. For all TRA R6 boards the TFO activation status shall be forwarded after a manual EM blocking/deblocking of each board as described in the rest of this procedure. All TRA R6B boards shall be always TFO capable. 2. Print device handling FR, EFR, AMR-FR and AMR-HR. The command RRTCP shall be given: RRTCP:DEV=ALL; RADIO TRANSMISSION TRANSCODER CONFIGURATION DATA DEV SNT CHRATE SPV

/ |dev&&-dev | . | . | . |dev&&-dev \

snt . . . snt

chrate . . . chrate

\ spv| . | . | . | spv| /


42 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

The related printout shall give information on which codec type each ASIC Cicero (group of 32 devices) is configured with (each row contains information for one ASIC). The SNT individuals (like RTTGS-y) to be considered in this OPI are that ones handling at least one ASIC configured with EFR, AMR-FR or AMR-HR codec type (Speech Version= 2 or 3). The parameter SPV in the printout shall be used to recognize all those SNT. 3. Check SNT variant. Only SNT individuals handling a CSPB 1.0 board should be considered, so the command NTCOP shall be given to obtain information about SNT variant. NTCOP:SNT=RTTGS-y ; SWITCHING NETWORK TERMINAL CONNECTION DATA / |SNT | |snt | | | | \

SNTV

SNTP

DIP

DEV

sntv

[sntp]

[dip]

[dev . . . [dev

\ | | devp] | . | . | . | devp] | / DEVP

If parameter SNTV is equal to 1 then all related RTTGD devices must be blocked. 4. Are there any installed TRA R6 boards? If no SNT individual handling a TRA R6 board (SNTV=1) is received from printout in step 3 then OPI is over, otherwise continue. 5. Deactivate SCTRAP feature / Idle Level Supervision. Feature SCTRAP and Idle Level Supervision are two mutually exclusive functionality, so only one of them can be active at same time into BSC. The command RRPSE / RRISE should be given in order to stop SCTRAP feature / Idle Level Supervision handling. That’s needed to avoid any interference with that functionality heavily tied to idle level monitoring. 6. Manually block TRA devices in one board? If the TRA R6 SNT individual RTTGS-y handles at least one ASIC configured in EFR, AMR-FR or AMR-HR mode (see printout step 2), then command RRTBI shall be given with parameter FORCE to manually block all 256 TRA RTTGD devices. The command shall be given 8 times one for each ASIC (group of 32 devices): RRTBI:DEV=RTTGD-n&&-m,FORCE; (n=y*256, m=n+31)


43 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

The parameter FORCE may cause dropped calls so it is suggested to start the procedure during maintenance window in the night. Note that even if step 8 states to block the RPI, the manual block of all devices is anyhow needed in order to keep safe the blocking state of those devices becoming unused/used after TFO activation/deactivation. 7. Print RP administration data. The command RADRP can be given to obtain the RP number related to SNT RTTGS-y handling the TRA RTTGD devices already blocked: RADRP:DEV=RTTGD-n; (n=y*256) DEVICE RP/EM DATA IN BSC DEV

dev

.

RP

EMG

[rp] [emg]

.

.

EM / \ |em| |. | |. | |. | |em| \ / .

ADMSTATE [h1][h2][h3][h4][h5][h6] cs [cs][cs][cs][cs][cs]

.

.

.

.

.

.

8. Manual block the RPI. The command BLRPI can be given to manual block the RPI related to SNT RTTGS-y: BLRPI:RP=rp; 9. Manually deblock the RPI. The command BLRPE shall be given to manually deblock the RPI related to SNT RTTGS-y: BLRPE:RP=rp; If TFOCONFIGTRA is turned on, the RPI deblocking shall trigger forwarding of TFO configuration bit to RPI and DSP SW with the existing signal interface CONFIGTRARPI. From now on the TRA R6 board represented by SNT individual RTTGS-y shall be able to handle TFO and all ASIC configured with EFR, AMR-FR and AMR-HR codec types shall handle 16 channels instead of 24.


44 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

If TFOCONFIGTRA is turned off, the RPI deblocking shall trigger forwarding of TFO configuration bit to RPI and DSP SW with the existing signal interface CONFIGTRARPI. From now on the TRA R6 board represented by SNT individual RTTGS-y shall not be able to handle TFO any more and all ASIC configured with EFR, AMR-FR and AMR-HR codec types shall be able to handle again 24 channels. During a manual reconfiguration ordered by command RRTCC the same signal CONFIGTRARPI is used towards RPI so if a Cicero ASIC reconfiguration is ordered from FR to EFR, for example, the status of exchange property TFOCONFIGTRA shall be sent all the same and that ASIC shall accordingly handle 16 or 24 channels. 10. Manually deblock TRA devices. The command RRTBE shall be given to manually deblock all TRA RTTGD devices handled by SNT RTTGS-y; the command shall be given 8 times one for each ASIC (group of 32 devices): RRTBE:DEV=RTTGD-n&&-m; (n=y*256, m=n+31) RADIO TRANSMISSION MANUAL DEBLOCKING OF TRANSCODER DEVICES RESULT DEV RTTGD-n

IDEV

RESULT EXECUTED

RTTGD-n+1 RTTGD-n+2 RTTGD-n+3 RTTGD-n+4 RTTGD-n+5

. .

. .

RTTGD-n+20 RTTGD-n+21 RTTGD-n+22

. .

. .

RTTGD-30 RTTGD-31

. .

. .

EXECUTED

UNUSED DEVICE UNUSED DEVICE UNUSED DEVICE

UNUSED DEVICE UNUSED DEVICE

END

After completing step 10 the TFO shall be working or not working on board CSPB 1.0 RTTGS-y. 11. Are there any recording reference attached to the new unused DEMUX devices? By using the result printout given by command RRTBE received in step 10 it is possible to check if a recording reference is attached to some unused devices. The command RRTRP should be given to print all attached recording references: RRTRP:RREF=ALL;


45 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

RADIO TRANSMISSION TRANSCODER TEST CALL DETAILS RREF rref . . rref

DEV dev . . dev

TRASTATUS trastatus . . trastatus

If a recording reference is attached to an unused DEMUX device then it should be removed via the command RRTRE (the OPI ‘Radio Transmission Transcoder Device Test Call, End’ shall be linked): RRTRE:RREF=rref; 12. Are there more SNT to be considered? If there are other TRA R6 SNT individuals where TFO should be configured, the steps from 6 to 11 shall be repeated by using the information received in the printout of steps 2 and 3. 13. Activate SCTRAP feature / Idle Level Supervision. The command RRPSI / RRISI should be given in order to activate again SCTRAP feature / Idle Level Supervision handling. 4.1.5

TFO Configuration and PCM Law Status Printing

[BG-TRA] The TFO configuration status and the current PCM law setting are two specific information that can be different for each device. In order to allow the operator their complete visibility for whatever transcoder device it is proposed to add them into Format 2 of the following existing result printout: RADIO TRANSMISSION TRANSCODER POOL DETAILS The new proposed format 2 is shown below in bold underlined font: RADIO TRANSMISSION TRANSCODER POOL DETAILS / | | | |/ || || |+ || ||

TRAPOOL

CHRATE

SPV

RNOTRA

POOLACT

POOLIDLE

trapool

chrate

spv

rnotra

poolact

poolidle

SUBPOOL

SUBACT

SUBIDLE

subpool . . . subpool

subact . . . subact

subidle . . . subidle

POOLTRAF \ pooltraf | | SUBTRAF | \| subtraf || . || . +| . || subtraf ||


46 (125)

No.

esteeds Approved

Checked

ETE/O/LB [Marie Sollén] || NONE |\ | | DEV |// |||dev ||| . ||| . ||| . |||dev ||\ || |+ || ||/ |||DEV |||dev ||| . ||| . ||| . |||dev ||\ || NONE \\


Rev

2010-12-22

Pa1

Reference

SUBPOOL [TFOCAPAB

PCMLAW]

subpool [tfocapab

pcmlaw] . . . [pcmlaw]

SUBPOOL subpool

PCMLAW] pcmlaw] . . . [pcmlaw]

. . . [TFOCAPAB [tfocapab

|| /| | | \\ | || | || | || | || | || | /| | | | + | | | \| | || | || | || | || | || | || | /| | | | / /

Parameters: Parameter

Description

Type

Comment

Tfocapab

TFO capability

String

Possible values are SUPPORTED or NOT SUPPORTED

pcmlaw

PCM law used

String

Possible values are A-LAW or U-LAW

Parameter ‘tfocapab’ shall be set to ‘SUPPORTED’ for all R6B devices and for all R6 devices TFO capable, it shall be set to ‘NOT SUPPORTED’ in all other cases. Parameter ‘pcmlaw’ shall be set depending on current status held in block RTTGS. The related command RRTPP shall be updated as well as in the following (changes are in bold font): / |ALL

\ |/

/

\\


47 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

RRTPP:TRAPOOL=+ +|,PRINTDEV|,DETAIL |trapool...|\ \ \ /

||; //

Parameters: Parameter

Description

DETAIL

Print details

Type

Comment Specifies that the TFO capability and the PCM law usage for devices belonging to the transcoder pools are printed.

So the new command format shall allow specifying the parameter DETAIL only together parameter PRINTDEV. 4.1.6

Pool Administration

[BG-TRA] A transcoder pool can be populated by using the command RRTPC: RRTPC:TRAPOOL=trapool,RNOTRA=rnotra[,FORCE]; It allows specifying in parameter RNOTRA the number of transcoder resources to be added in the pool specified in parameter TRAPOOL. In order to allow traffic resource seizure prioritization, a new sub-pool structure is proposed below (in bold the changes):

Codec type

Capability

Subpool index

HW Boards

EFR speech, FR data, MCC, TFO, A/u-law

3

R6B, R6

EFR speech, FR data, MCC, A/u-law

2

R6

EFR speech, FR data, MCC, A-law

1

R5A, R5B

EFR speech, FR data, MCC, A-law

0

R4

AFR speech, FR data, MCC, TFO, A/u-law

2

R6B, R6

EFR

AMR-FR


48 (125)

No.

esteeds Approved

Checked


AMR-HR


Rev

2010-12-22

Pa1

Reference

AFR speech, FR data, MCC, A/u-law

1

R6

AFR speech, FR data, MCC, A-law

0

R5B

AHR speech, HR data, MCC, TFO, A/u-law

2

R6B, R6

AHR speech, HR data, MCC, A/u-law

1

R6

AHR speech, HR data, MCC, A-law

0

R5B

The change means to insert, for all three pools TFO adapted, all TRA R6 and R6B resources able to support TFO in a new sub-pool and to insert all TRA R6 resources not TFO capable in another sub-pool. These two new sub-pools shall contain all TRA resources where it shall be possible to set the PCM law in a dynamic way. That pool structure shall apply at the first system restart after product functional change from BSC R11 to BSC R12. To aim that signals RTTRASEIZER and RTSEIZETOPOOLR shall be updated by adding the following extra data: 1. TFO capability (0=not supported, 1=supported) This new data shall be sent from TRA device owner (block RTTGD) towards RTTPH function block; block RTPDI shall just forward.

4.1.7

STS

4.1.8

Influence on STS Four new STS counters shall be added (see chapter Error: Reference source not found) in the existing TRAPEVENT Object Type; those counters shall belong to DID TRAPEVENTCNT as in the following shown (in bold the changes): DID-name: TRAPEVENTCNT DID-number: 450 Function: Transcoder resource registrations per pool. Application: Block RTTPH DID item position 1

Contents Global transcoder pool pointer (TPPTR)


49 (125)

No.

esteeds Approved

Checked


2 3 4 5 6 7 8 9 10 11 12 13


Rev

2010-12-22

Pa1

Reference

Number of accumulations (TPACC) Active Transcoder Resources (TPACTTR) Available Transcoder Resources (TPAVTR) Idle Transcoder Resources (TPIDLTR) Transcoder Resource Allocation (TPALLOC) Attempts Transcoder Resource Congestion (TPCONG) Transcoder Resource Congestion (TPCTIME) Time V.110 Synchronization Failure (TPSYNCF) for pooled transcoder devices Number of TFO establishment attempts (TPTFOESTATT) Number of successful TFO establishment (TPTFOEST) Number of TFO re-establishment attempts (TPTFORESTATT) Number of successful TFO re-establishment (TPTFOREST)

Description: The counters are defined per transcoder pool. DID item positions 1 - 13 are stored in the transcoder pool file in block RTTPH. DID item position 1 is a pointer, the pointer value can be translated to a transcoder pool name in the transcoder pool translation table (TPTRANTAB). The number of records in the file is 32. No size alteration. The size of the variables. DID item positions: 1 - 13 = R declared.

The four new counters shall be added per each transcoder pool so the total number of new counters for a BSC/TRC shall depend on the number of defined pools; the following table applies: New counters per pool Total Number of Counters for a BSC/TRC

4 4*p

(*) where p is the number of pools per BSC/TRC

4.1.8.1

New or Modified Counters The existing Object Type TRAPEVENT (Transcoder Resource Registrations per Transcoder Pool) shall be modified by adding four new counters as described in previous chapter (in bold the changes):


50 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Object Type: TRAPEVENT Transcoder resource statistics per transcoder pool. The object type exists only in TRC or BSC/TRC. This object type is used to give the operator the possibility to obtain statistics about the transcoder resources in the transcoder pools in the system. Type

Counter name

Description

ID

ID1

Global transcoder pool pointer

PC

TPACC

Number of accumulations

PC

TPACTTR

Active Transcoder Resources

PC

TPAVTR

Available Transcoder Resources

PC

TPIDLTR

Idle Transcoder Resources

PC

TPALLOC

Transcoder Resource Allocation Attempts

PC

TPCONG

Transcoder Resource Congestion

PC

TPCTIME

Transcoder Resource Congestion Time

PC

TPSYNCF

V.110 Synchronization Failure for pooled transcoder devices (supported only for TRA R4 and R5)

PC

TPTFOESTATT

Number of TFO establishment attempts

PC

TPTFOEST

Number of successful TFO establishment

PC

TPTFORESTATT

Number of TFO re-establishment attempts

PC

TPTFOREST

Number of successful TFO re-establishment

The current CP block RTTPH shall be still the counters owning block. No existing counters shall be modified.


No.

esteeds Approved


Checked


4.1.9

51 (125)

Date

Rev

2010-12-22

Pa1

Reference

HW From product handling point of view ‘TRA R6’ shall be used to indicate a CSPB 1.0 board while ‘TRA R6B’ shall be used to indicate a CSPB 1.1 board. ‘TRA R6-family devices’ will be used in this document to indicate both types of TRA devices.

4.2

191, Handover with Usage of Service Indicator Package: SBHO_1

4.2.1

Description Link to IP 1/159 41-414/FCP 103 4829 This is a proposal for how to implement service based handovers. This IP shows how to handle new 48.008 Service Handover IE and its influence on handover. Depending on the value handover will be performed to GSM or UMTS.

4.2.2

AXE parameter New Optional feature parameter: •

SBHO values: 0 UNAVAILABLE 1 AVAILABLE default value:

0

owner:

RMHAIDL

DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=SBHO, VALUE=1; 4.2.3

Exchange Property New BSC Exchange Property: •

SBHOACTIVE values: 0 OFF 1 ON default value:

0

owner:

RMHAIDL


52 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

RAEPC:PROP=SBHOACTIVE-1; 4.2.4

Command No impact.

4.2.5

STS

4.2.5.1

Influence on STS

Counters per BSC

0

Counters per Cell

0

Counters per UTRAN Cell Relations

1

Total Number of Counters for a BSC/TRC

4.2.5.2

New or Modified Counters

HOATTSHOULDUTRAN Number of handover attempts to a neighbouring UTRAN FDD cell due to the Service Handover value is ‘should’. The counter is incremented when the BSC sends a INTER SYSTEM TO UTRAN HANDOVER COMMAND message to the MS.

4.2.6

HW No impact.

4.3

194, Load Sharing Between UMTS AND GSM Package: ISHO_1

4.3.1

Description Link to IP 1/159 41-413/FCP 103 4829 This IP describes implementation of requirements for load sharing between a BSS R12 system (based on 3GPP release 6) and Ericsson’s UTRAN P3 system (based on 3GPP release 4) and UTRAN P4 system (based on 3GPP release 6).


53 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The main feature Inter System Handover Improvements is divided into two ambition levels in BSC. The Ambition level 1 covers following functionalities: load sharing between UMTS and GSM, urgency handover to UTRAN cell, support for real-time monitors for handovers due to load. The load sharing functionality will be added as optional feature with the name: Load sharing between UMTS and GSM and it will be controlled by AXE parameter ISHOLSH and exchange property COEXUMTSLSH. This function gives possibility to regulate the load in a GSM cell by controlling number of handovers of speech connections between both systems. The urgency handover is second functionality implemented in Ambition level 1. It can be triggered when there is a quality- or timing advance problem in the serving GSM cell regardless of the load in the GSM cell (improvement of the existing feature “GSM-UMTS Cell Reselection and Handover”). Real - time monitors shall give information about the load contribution from multi-RAT mobiles and the number of handovers due to load. The Ambition level 2 makes possible to run real-time monitors for handovers to UTRAN cell with information about the average values of UMTS cells quality (improvement of the existing feature “GSM-UMTS Cell Reselection and Handover”).

4.3.2

AXE parameter Ambition Level 1 “Load sharing between GSM and UMTS” is optional feature and it will be controlled by AXE parameter. The proposal for the optional feature is: •

Global Parameter ISHOLSH

The ISHOLSH shall be a Commercial Market Parameter and shall have the following possible values: 0=FEATURE UNAVAILABLE 1=FEATURE AVAILABLE The default values shall be 0. The CLASS of the parameter shall be FEATURE and the distribution shall be IMMEDIATE. The value shall be given on commercial agreement basis only. The parameter shall be added in owner block RMHOEB. The RQLOA should be the user of the AXE parameter. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=ISHOLSH, VALUE=1;


No.

esteeds Approved


Checked


4.3.3

54 (125)

Date

Rev

2010-12-22

Pa1

Reference

Exchange Property It shall be possible to activate/deactivate the functionality using the new exchange property COEXUMTSLSH in command RAEPC. It shall be possible to set property to “ON” (1) and “OFF” (0) and OFF will be default. The AI2 for ROEPC shall be updated with the new exchange property. RMHOEB, RQUCD and RQRCQS will be defined as parameter owner for the new exchange property. RAEPC:PROP=COEXUMTSLSH-1;

4.3.4

Command In the function Administration of Locating Data the new parameter MAXISHO should be added to the existing command RLLOC. Radio Control Cell, Locating Data, Change (RLLOC) Syntax: / / \\ | |sctype|| RLLOC:CELL=cell|,SCTYPE=+ +| | |ALL || \ \ // / | +[,BSPWR=bspwr][,BSTXPWR=bstxpwr] | \ [,BSRXMIN=bsrxmin][,BSRXSUFF=bsrxsuff] [,MSRXMIN=msrxmin][,MSRXSUFF=msrxsuff] [,SCHO=scho][,MISSNM=missnm][,AW=aw] [,EXTPEN=extpen][,HYSTSEP=hystsep] \ | [,ISHOLEV=isholev] [,MAXISHO=maxisho]+; | / // \\ ||,[,FBOFFSP=fboffsp]|| |+ +|; ||,[,FBOFFSN=fboffsn]||

\\

//

Parameters: MAXISHO=maxisho Maximum number of inter system handovers This parameter defines maximum number of outgoing inter system handovers per second from specified cell Numeral 1 – 100.


55 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Table: New parameter MAXISHO in command RLLOC. The new parameter should be stored in block RQUCD by RQLOA. When the feature is available the RQLOA should fetch this parameter when printout is requested using command RLLOP. When the feature is not available and the MAXISHO parameter is given the existing FC should be presented: “Parameter not supported by this exchange”. Default values for new parameter MAXISHO = 2, value range for MAXISHO: 1..100 handovers per second. 4.3.5

STS New or Modified Counters

Name of the new counters

Description

URGHOVERUTRAN

Number of handover attempts to the neighbour UTRAN FDD cell in case of urgency conditions

SUCURGHOUTRAN

Number of successful handover attempts to the neighbour UTRAN FDD cell in case of urgency conditions

Two new STS counters per UTRAN relation. These counters shall be included in the existing object type NUCELLREL.

4.3.6

Counters per UTRAN relation

2


16384

HW No impact.


No.

esteeds Approved

Checked


4.4

56 (125)


Rev

2010-12-22

Pa1

Reference

409, BTS O&M Improvements Package: TGSI_1 See description in Shipment 1

5

Shipment 5

5.1

367, RNO Enhancements R12 Package: RNO_1

5.1.1

Description Link to IP 1/159 41-418/FCP 103 4829 The requirement for enhancements in OSS RNO product family for optimisation of GSM-UMTS network coexistence has been specified. Today the operators use OSS RNO tools i.e. FAS/FOX, NCS/NOX, MRR, TET, RNDBI and SYROX for GSM network optimisation. The enhanced NCS i.e. GSM-UMTS NCS, will use UMTS related measurement data in addition to GSM related, as a support for optimising 3G neighbours for 2G cells. This enhanced optimisation will benefit GSM to UMTS handover and handling of neighbouring relations.

5.1.2

AXE parameter This proposal introduces new optional feature GSM-UMTS NCS in BSC. The feature enhances Active BA-List Recording so that it will be possible to define new recording for both GSM and UMTS measurement frequencies. The BARFIL file in BSC that contains output data from Active BA-List Recording and is used as a source data for RNO will be extended with new UMTS related measurements. The GSM-UMTS NCS feature shall be implemented, as an optional feature thus the availability of the feature shall be controlled by an AXE feature parameter. The proposed name of the feature parameter and functional abbreviation of the feature is GUBAR (GSM-UMTS BA-List Recording). The GUBAR feature shall work only if the optional feature GSM-UMTS Cell Reselection and Handover is active however no mutual dependency between features activation shall be implemented. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME= VALUE=1;

,

DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=GUBAR, VALUE=1; 5.1.3



No.

esteeds Approved

Checked


5.1.4

57 (125)


Rev

2010-12-22

Pa1

Reference

Command Doc. No: 3/190 82-CNT 248 1113 Uen Title: RABDC Change: New UMTS related recording parameters.

Rev: C

Doc. No: 4/190 82-CNT 248 1113 Uen Title: RABDE Change: Possibility to delete TUMFIs.

Rev: B

Doc. No: 9/190 82-CNT 248 1057 Uen Title: RABTI Change: Removed parameter IO=io.

Rev: B

Doc. No: 3/190 82-CNT 240 1478 Uen Rev: B1 Title: RLUMC Change: New fault code when BA list recording is in progress. Doc. No: 2/190 82-CNT 240 1479 Uen Rev: B2 Title: RLSUC Change: New fault code when BA list recording is in progress.

Function Active BA-List Recording is changed to introduce new type of recording for both GSM and UMTS measurement frequencies. The following shall be done in the function to accomplish changes:

5.1.4.1

•

Availability of new GUBAR functionality shall be controlled by feature AXE parameter.

•

The RABDC command used for the recording definition shall be extended with new parameters defining UMTS measurements.

•

The RABDE command used for the removal of recording definition shall be extended to allow removal of UMTS test measurement frequencies (TUMFIs).

•

The answer printout ACTIVE BA-LIST RECORDING DEFINITION DATA (command RABDP) shall show extended recording definition.

RABDC (existing command) Radio Control Administration, Active BA-list Recording Definition, Change Syntax of updated command (new parameters are in bold): /


58 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

|// \\ |||,CELL=cell... || RABDC:RID=rid +|+ / \+| |||,CELL=ALL |,CSYSTYPE=csystype||| |\\ \ /// \ / \/ \ |,TMBCCHNO=tmbcchno...||,NCELLTYPE=ncelltype| \ /\ / // \\// \\ ||,RELSSP=relssp||||,RELSS2P=relss2p|| |+ +||+ +| ||,RELSSN=relssn||||,RELSS2N=relss2n|| \\ //\\ // // \\// \\ ||,RELSS3P=relss3p||||,RELSS4P=relss4p|| |+ +||+ +| ||,RELSS3N=relss3n||||,RELSS4N=relss4n|| \\ //\\ // // \\ ||,RELSS5P=relss5p|| |+ +| ||,RELSS5N=relss5n|| \\ // / \/ \/ \ |,ABSS=abss||,NUMFREQ=numfreq||,SEGTIME=segtime| \ /\ /\ / / \/ \/ \ |,TFDDMRR=tfddmrr||,NUMUMFI=numumfi||,ECNOABSS=ecnoabss| \ /\ /\ / \ | / \/ \| |,TUMFI=tumfi...||,NUCELLTYPE=nucelltype|+; \ /\ /| | /

New parameters: Parameter

Description

Type

Default value

TFDDMRR

number of neighbouring UTRAN cells

numeral [1-3] or string [UNUSED]

UNUSED

NUMUMFI

number of

numeral

5

Comment Number of neighbouring UTRAN cells to be reported during one recording period. This parameter temporarily (for the recording time) replaces the FDDMRR defined by command RLSUC. maximum number of TUMFIs that


No.

esteeds Approved


Checked

ETE/O/LB [Marie Sollén] TUMFIs

[1-64]

ECNOABSS

absolute signal quality (EC/N0) threshold

numeral [0-49]

TUMFI

test UTRAN measurement frequency expressed as: mfddarfcnmscrcodediversity

NUCELLTYPE

type of neighbouring UTRAN cell

Date

Rev

2010-12-22

Pa1

combined numeral-numeral-string [0-16383]-[0-511]-[DIV/NODIV]

Reference

are allowed to be added to the 3G BA-list at a time EC/N0 – pilot channel divided by the power density in the band. This quantity specifies the signal quality of the UTRAN neighbouring cell. The numeral value range corresponds to the range: -24 up to 0 in [dB] and is mapped as follows: 0

not applicable

string [DEF/UNDEF/BOTH]

Table : New parameters in RABDC

5.1.4.2

59 (125)

Command RABDE (existing command)

BOTH

numeral 0 1 … 48 49

[dB] < -24 >= -24, but < 23.5 … >= -0.5, but < 0 >= 0

mfddarfcn – Absolute Radio Frequency Channel Number (ARFCN) for the UTRAN cell mscrcode – scrambling code diversity – indicates if diversity is applied for the UTRAN cell type of neighbouring UTRAN cells that information will be recorded for: - DEF - defined neighbour - UNDEF - undefined neighbour - BOTH - DEF + UNDEF


60 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Radio Control Administration, Active BA-list Recording Definition, End Syntax of updated command: (new parameters are in bold) / \ |,CELL=cell... | | / \| |,CELL=ALL |,CSYSTYPE=csystype|| | \ /| | / \ | | |tmbcchno...| | RABDE:RID=rid +,TMBCCHNO= + + +; | |ALL | | | \ / | | / \ | | |tumfi... | | |,TUMFI= + + | | |ALL | | \ \ / /

5.1.4.3

ACTIVE BA-LIST RECORDING DEFINITION DATA (existing printout) Purpose: The printout is obtained as an answer to the command RABDP and contains the recording configuration data specified in the command RABDC. The printout shall be extended with new UMTS related recording parameters i.e. TFDDMRR, ECNOABSS, NUMUMFI, NUCELLTYPE and the list of defined TUMFIs. The structure of printout shall be kept unchanged so that all data are printed per RID. Syntax of updated printout: (new parameters are in bold) ACTIVE BA-LIST RECORDING DEFINITION DATA RID rid

NCELLTYPE ncelltype

NUMFREQ numfreq

SEGTIME segtime

RELSSP RELSSN [relssp] [relssn]

RELSS2P RELSS2N [relss2p] [relss2n]

RELSS3P RELSS3N [relss3p][relss3n]

RELSS4P RELSS4N [relss4p] [relss4n]

RELSS5P RELSS5N [relss5p][relss5n] / | TFDDMRR

ECNOABSS

ABSS abss NUCELLTYPE

\ NUMUMFI |


esteeds Approved


61 (125)

No.

Checked


Rev

2010-12-22

Pa1

|[tfddmrr][ecnoabss][nucelltype][numumfi]| | | \ / TMBCCHNO / \ |tmbcchno . . . tmbcchno | | . . | | . . | + . . + |tmbcchno . . . tmbcchno | | | |NO FREQUENCY CONNECTED TO THIS RID| \ / / |TUMFI | |tumfi . . . tumfi | . . + . . | . . |tumfi . . . tumfi | |NO UMFI CONNECTED TO THIS RID \ CELL / \ |cell . . . cell | | . . | | . . | + . . + |cell . . . cell | | | |NO CELL CONNECTED TO THIS RID| \ /

\ | | | | + | | | | /

Reference


No.

esteeds Approved

Checked


5.1.5

62 (125)


Rev

2010-12-22

Pa1

Reference

STS No impact.

5.1.6

HW No impact.

5.2

397.1, Channel Allocation Enhancements R12 Package: ECHA_1, ECHA_2

5.2.1

Description Link to IP 1/159 41-419/FCP 103 4829 In releases up to R11 there is no procedure to change the TBF mode for an ongoing TBF. Since there are cases where such a change of TBF mode may be beneficial and in some cases even crucial this sub feature is aiming to provide such a procedure. Since there is no support of this in the 3GPP specifications all TBFs connected to the MS in question must be released and set up again using the new TBF mode. When setting up the first TBF again a re-reservation to new TSs may also be done at the same time. For packet data connections only, MSs having a single DL TBF and MSs having both a DL and an UL TBF shall be handled in this sub feature. MSs having a single UL TBF or TBFs belonging to DTM connections will not be handled in this sub feature. There are two ambition levels in this sub feature: 1. Change of TBF mode for QoS traffic class Streaming. 2. Change of TBF mode for QoS traffic classes Interactive and Background. (It is assumed that ambition level 1 is required.) This improvement will be used as a tool in other improvements. Note that this sub feature may remove the necessity to have an EGPRS capable dedicated PDCH in cells in order to use EGPRS mode during the lifetime of a TBF.

5.2.2



63 (125)

No.

esteeds Approved

Checked


5.2.3

Exchange Property

5.2.3.1

Ambition level 1


Rev

2010-12-22

Pa1

Reference

A new BSC exchange parameter shall be introduced according to table Ambition level 1. The generic operator command RAEPC shall be used. RGRLCU shall own the parameter that shall be checked and set by the function block ROEPC in subsystem ROS. BSC exchange parameter: TBFMODEACT = tbfmodeact This property defines if change of TBF mode for QoS traffic class Streaming is activated or not. 0 = OFF Change of TBF mode for QoS traffic class Streaming is not activated. 1 = ON Change of TBF mode for QoS traffic class Streaming is activated. Default value is 0.

Table Ambition level 1 : New BSC exchange parameter TBFMODEACT.

TBFMODEACT = tbfmodeact This property defines if change of TBF mode for QoS Ambition level 2traffic classes Streaming, Interactive and Background is activated or not. The new BSC exchange parameter TBFMODEACT shall be changed 0 = OFF to table Ambition level 2 according Change of TBF mode is not activated for any QoS traffic class. 1 = Streaming Change of TBF mode for QoS traffic class Streaming is activated. 2 = Interactive and Background BSC exchange Change parameter: of TBF mode for QoS traffic classes Interactive and Background is activated. 3 = Streaming, Interactive, and Background Change of TBF mode for QoS traffic classes Streaming, Interactive and Background is activated. Default value is 0.


64 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Table Ambition level 2: Changed BSC exchange parameter TBFMODEACT. 5.2.4

Command No impact.

5.2.5

STS Affected Counters The following counters shall not be incremented for ignored access requests during change of TBF mode:

5.2.6

•

PSCHREQ

•

PREJOTH

HW No impact.

5.3

397.2, Channel Allocation Enhancements R12 Package: ECHA_1, ECHA_2

5.3.1

Description Link to IP 2/159 41-419/FCP 103 4829


65 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Enhancements of Channel Allocation is a feature with different channel allocation improvements. It is divided into four different parts that are independent of each other. The first part, PDCH Pre-emption Improvements, has two ambition levels. In ambition level 1, GPRSPRIO will be a cell parameter instead of a BSC exchange property. This is done in order to interact better with the cell parameter PDCHPREEMPT. In ambition level 2, the number of pre-emptable ODPDCHs shall be sampled during one minute and an average shall be reported. The reported number of pre-emptable ODPCHs will then be used when the number of idle TCHs is calculated if GPRSPRIO indicates that they should be treated as idle TCHs. The second part, Steerable Allocation, the BSC exchange property CHALLOC and the cell parameter PDCHALLOC is replaced with the new cell parameter CSPSALLOC. This will be done since CHALLOC and PDCHALLOC can interfere with each other. A new parameter, CSPSPRIO shall be introduced in order to steer if PSPRIO shall have priority over CSPSALLOC or if the priority shall be the opposite. The third part, Packing Improvements and Optimization of TCH Usage, will introduce a new algorithm for selecting a connection to move at HR packing and at DYMA FR to HR. It will also introduce a new method in order to optimize the TCH usage. This will be done by moving connections in order to free resources for GPRS and DTM in the TCH group. The fourth part, On-demand PDCH Limit, makes it possible to limit the number of ODPDCHs by command. It will be possible to limit the number of ODPDCHs on channel group level. 5.3.2


5.3.3

Exchange Property

5.3.3.1

The first part, PDCH Pre-emption Improvements In ambition level 1, GPRSPRIO will be a cell parameter in command RLCLC instead of a BSC exchange property.

5.3.3.2

The second part, Steerable Allocation The BSC exchange property CHALLOC and the cell parameter PDCHALLOC is replaced with the new cell parameter CSPSALLOC in command RLCLC.

5.3.3.3

The third part, Packing Improvements and Optimization of TCH Usage No impact.


No.

esteeds Approved


Checked


5.3.3.4

66 (125)

Date

Rev

2010-12-22

Pa1

Reference

The fourth part, On-demand PDCH Limit No impact.

5.3.4

Command

5.3.4.1

The first part, PDCH Pre-emption Improvements Administration of Channel Allocation Data Command Handling Two new commands shall be introduced in RCCHPA. These commands shall handle changing and printing of the GPRSPRIO parameter per cell. RLCLC

It shall be possible to change the value of GPRSPRIO for the cell. RCCHPA shall then distribute the parameter value to RCCD in this function.

RLCLP

It shall be possible to print the value of GPRSPRIO for a specific, several cells or for all cells. RCCHPA shall then fetch current parameter values for the requested cells.

RLCLC (new command): Radio Control Cell, Channel Allocation Data, Change Syntax: / RLCLC:CELL=cell |[,CSPSALLOC=cspsalloc] [,CSPSPRIO=cspsprio] \

\ [,GPRSPRIO=gprsprio] |; /

Note: The parameters CSPSALLOC and CSPSPRIO are used in part 2, steerable allocation. Parameters: GPRSPRIO=gprsprio GPRS priority This parameter controls whether ODPDCHs (Amb 1)/Pre-emptable ODPDCHs (Amb 2) will be treated as idle or busy for Dynamic HR allocation and TCH packing functions (i.e. HR packing and DYMA), Cell Load Sharing, Subcell Load Distribution and GSM - UMTS Cell Reselection and Handover. 0 Pre-emptable ODPDCHs will be treated as idle for all the functions


esteeds Approved


67 (125)

No.

Checked


Rev

2010-12-22

Pa1

Reference

1 Pre-emptable ODPDCHs will be treated as busy for the Dynamic HR allocation and TCH packing functions and idle for the following functions: Cell Load Sharing Subcell Load Distribution GSM - UMTS Cell Reselection and Handover 2 Pre-emptable ODPDCHs will be treated as busy for the Cell Load Sharing function and idle for the following functions: Dynamic HR allocation and TCH packing Subcell Load Distribution GSM - UMTS Cell Reselection and Handover 3 Pre-emptable ODPDCHs will be treated as busy for the following functions: Dynamic HR allocation and TCH packing Cell Load Sharing And idle for the following functions: Subcell Load Distribution GSM - UMTS Cell Reselection and Handover 4 Pre-emptable ODPDCHs will be treated as busy for the Subcell Load Distribution function and idle for the following functions: Dynamic HR allocation and TCH packing Cell Load Sharing GSM - UMTS Cell Reselection and Handover

5 Pre-emptable ODPDCHs will be treated as busy for the following functions: Dynamic HR allocation and TCH packing Subcell Load Distribution And idle for the following functions: Cell Load Sharing GSM - UMTS Cell Reselection and Handover

6 Pre-emptable ODPDCHs will be treated as busy for the following functions: Cell Load Sharing Subcell Load Distribution And idle for the following functions: Dynamic HR allocation and TCH packing GSM - UMTS Cell Reselection and Handover

7 Pre-emptable ODPDCHs will be treated as busy for the following functions: Dynamic HR allocation and TCH packing Cell Load Sharing Subcell Load Distribution And idle for the GSM - UMTS Cell Reselection and Handover function. 8 Pre-emptable ODPDCHs will be treated as busy for the GSM - UMTS Cell Reselection and Handover function and idle for the following functions: Dynamic HR allocation and TCH packing Cell Load Sharing Subcell Load Distribution GSM - UMTS Cell Reselection and Handover


68 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

9 Pre-emptable ODPDCHs will be treated as busy for the following functions: Dynamic HR allocation and TCH packing GSM - UMTS Cell Reselection and Handover And idle for the following functions: Cell Load Sharing Subcell Load Distribution 10 Pre-emptable ODPDCHs will be treated as busy for the following functions: Cell Load Sharing GSM - UMTS Cell Reselection and Handover And idle for the following functions: Dynamic HR allocation and TCH packing Subcell Load Distribution

11 Pre-emptable ODPDCHs will be treated as busy for the following functions: Dynamic HR allocation and TCH packing Cell Load Sharing GSM - UMTS Cell Reselection and Handover And idle for the Subcell Load Distribution function.

12 Pre-emptable ODPDCHs will be treated as busy for the following functions: Subcell Load Distribution GSM - UMTS Cell Reselection and Handover And idle for the following functions: Dynamic HR allocation and TCH packing Cell Load Sharing

13 Pre-emptable ODPDCHs will be treated as busy for the following functions: Dynamic HR allocation and TCH packing Subcell Load Distribution GSM - UMTS Cell Reselection and Handover And idle for the Cell Load Sharing function.

14 Pre-emptable ODPDCHs will be treated as busy for the following functions: Cell Load Sharing Subcell Load Distribution GSM - UMTS Cell Reselection and Handover And idle for the Dynamic HR allocation and TCH packing function. 15 Pre-emptable ODPDCHs will be treated as idle for all the functions. Default value: 0

RLCLP (new command): Radio Control Cell, Channel Allocation Data, Print Syntax:


69 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

/ \ |cell …| RLCLP:CELL=+ +; |ALL | \ /

The new printout ‘CELL CHANNEL ALLOCATION DATA’ shall show GPRSPRIO for the cells. 5.3.4.2

The second part, Steerable Allocation This part will combine the parameters PDCHALLOC and CHALLOC into one new parameter, CSPSALLOC. This will be done since PDCHALLOC and CHALLOC can interfere with each other. The parameter PDCHALLOC shall be removed from the command RLGSC and from the printout ‘CELL GENERAL PACKET RADIO SERVICE DATA’. A new cell parameter, CSPSPRIO shall be introduced in order to steer if PSPRIO shall have priority over CSPSALLOC or if the priority shall be the opposite. CSPSPRIO will be used at allocation for singleslot and multislot circuit switched connections. Administration of Channel Allocation Data Command Handling The commands RLCLC and RLCLP shall be used in RCCHPA. These commands shall handle changing and printing of the CSPSALLOC parameter per cell. RLCLC

It shall be possible to change the value of CSPSALLOC for the cell. RCCHPA shall then distribute the parameter value to RCCD in this function.

RLCLP

It shall be possible to print the value of CSPSALLOC for a specific, several cells or for all cells. RCCHPA shall then fetch current parameter values for the requested cells


70 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Parameters: CSPSALLOC=cspsalloc CS and PS allocation preference This parameter determines if nonhopping Traffic Channels (TCHs) on the Broadcast Control Channel (BCCH) frequency should be selected first, last or if there is no preference at CS and PS channel allocation. No selection preference CSNOPRFPSFIRST No selection preference for CS and select TCHs first for PS CSNOPRFPSLAST No selection preference for CS and select TCHs last for PS CSFIRSTPSNOPRF Select TCHs first for CS and no selection preference for PS CSFIRSTPSLAST Select TCHs first for CS and select TCHs last for PS CSLASTPSNOPRF Select TCHs last for CS and no selection preference for PS CSLASTPSFIRST Select TCHs last for CS and select TCHs first for PS CSLASTPSLAST Select TCHs last for CS and select TCHs last for PS CSPSNOPRF

The new printout ‘CELL CHANNEL ALLOCATION DATA’ shall show CSPSALLOC for the cells. The commands RLCLC and RLCLP shall be used in RCCHPA. These commands shall handle changing and printing of the CSPSPRIO parameter per cell. RLCLC

It shall be possible to change the value of CSPSPRIO for the cell. RCCHPA shall then distribute the parameter value to RCCD in this function.

RLCLP

It shall be possible to print the value of CSPSPRIO for the cells in a specific, several cells or for all cells. RCCHPA shall then fetch current parameter values for the requested cells.


71 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Parameters: CSPSPRIO=cspsprio CS or PS priority This parameter determines if the CS selection preference for nonhopping TCHs on the BCCH frequency has higher or lower priority than the criterion to avoid TCH groups with PS priority. CSPRIO

PSPRIO

The CS selection preference for non-hopping TCHs on the BCCH frequency has higher priority than the criterion to avoid TCH groups with PS priority. The criterion to avoid TCH groups with PS priority has higher priority than the CS selection preference for non-hopping TCHs on the BCCH frequency.

Default value: PSPRIO The new printout ‘CELL CHANNEL ALLOCATION DATA’ shall show the value of CSPSPRIO for cells.

5.3.4.3

The third part, Packing Improvements and Optimization of TCH Usage No impact.

5.3.4.4

The fourth part, On-demand PDCH Limit Administration of Channel Allocation Data The existing commands RLGAC and RLGAP shall be used in RCCHPA in order to change and print the new parameter, ODPDCHLIMIT per channel group. RLGAC

It shall be possible to change the value of ODPDCHLIMIT for the channel group. RCCHPA shall then distribute the parameter value to RCCGD in this function.


72 (125)

No.

esteeds Approved

Checked


RLGAP


Rev

2010-12-22

Pa1

Reference

It shall be possible to print the value of ODPDCHLIMIT for the channel groups in a specific, several cells or for all cells. RCCHPA shall then fetch current parameter values for the channel groups in requested cells.

RLGAC (Existing command): Radio Control Cell, Channel Group Allocation Data, Change Syntax: / RLGAC:CELL=cell [,CHGR=chgr]|[,SAS=sas] \

\ [,ODPDCHLIMIT=odpdchlimit]|;

/

Parameters: ODPDCHLIMIT=odpdchlimit On-demand PDCH limit This parameter limits the total number of on-demand PDCHs in the channel group. The parameter indicates a percentage value of number of deblocked Full Rate (FR) Traffic Channels (TCHs) in the channel group that can be allocated as on-demand PDCHs. Note: The number of TCHs that can be used as on-demand PDCHs will be The existing printout ‘CELL CHANNEL GROUP ALLOCATION DATA’ shall show the value of ODPDCHLIMIT for the channel groups in the cells. 5.3.5

STS New or Modified Counters In part 3, RMHOAC shall order RMCNT to step the new STS counter ‘HOSUCTCHOPT – Number of successful Intra Cell Handover due to TCH optimization’ in the existing object type ‘CELEVENTI – Intra Cell Channel Change per Cell’ after a successful Intra Cell Handover.


73 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

No counters have been modified.

5.3.6

HW No impact.

5.4

441, DTM Improvements Package: DTM_1, DTM_2

5.4.1

Description Link to IP 1/159 41-426/FCP 103 4829 The feature DTM was introduced in R11. This IP describes a number of stand-alone improvements for the feature. 1) Max 10 dB output difference between CS and PS part of connection. The reason for this improvement is to be compliant with 3GPP, which specifies that there should only be max 10 dB output difference between CS and PS part of connection. 2) Performance Management. This improvement increases the possibility of monitoring the performance of DTM. 3) DTM request in CS signalling mode. This improvement reduces the time to enter DTM for a MS that resides in CS signalling or data mode when a request for DTM is received. 4) Alignment with flexible abis. This improvement contains two sub improvements. i.

First improvement considers the possibility of upgrading abis paths from 16K to 64K. Due to this E- and G-TCHs with 16K abis path shall be regarded as a G-TCH at channel allocation and not as a B-TCH as in R11 release. The reason why not treat a E-TCH with 16 K abis path as a E-TCH is that it will not be possible to change TBF mode for a DTM connection in R12.

ii.

Second improvement is that the exchange property FLEX64KGPRS was not considered in R11 when determining the number of PDCHs to be allocated for a GPRS only MS. An example of this is that one E-TCH was regarded as a better choice then two B-TCHs, even though only 16K abis path was set up. This improvement takes care of this problem.

5) MPDCH consideration at DTM allocation. The reason for this improvement is that in the design base no considerations was made to see if the MPDCH was allowed to be used for DTM traffic or not.


74 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

6) Subcell Considerations at DTM allocation. In the design base the subcell to allocate in was decided from SCALLOC. This improvement also considers the subcell where the MS currently exists.

5.4.2

AXE parameter Existing optional feature DTM should be enabled. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=DTM, VALUE=1;

5.4.3

Exchange Property 1) Max 10 dB output difference between CS and PS part of connection This functionality shall be able to activate/deactivate on BSC level with the new BSC Exchange property, DTMBTSPOWREG, and handled by RQUPD. The BSC exchange property indicates if there are limitations or not at BTS power regulation for a DTM connection. The default value shall be that limitations of BTS power regulation exists. RAEPC:PROP=DTMBTSPOWREG- ; 4) Alignment with flexible abis RNTCH shall be a user of the existing BSC exchange property FLEX64KGPRS.

5.4.4

Command 1) Max 10 dB output difference between CS and PS part of connection It shall be possible to determine if measurement results shall be considered or not for DTM connections, due to this a new parameter called DTMFILTER shall be included in format 2 of command RAMDC. The parameter shall only be allowed to be changed if the optional feature DTM is enabled. ROMRRC shall store this parameter in ROMRR. When ROMRRC orders ROMRR to initiate the recording then ROMRR includes DTMFILTER in the request to the function Measurement Result Statistics Collection (block RQRCQSU). The new parameter DTMFILTER shall be included the printout MRRFIL. ROMRRC shall fetch the new parameter DTMFILTER from ROMRR and include the parameter in the printout MEASUREMENT RESULT RECORDING DEFINITION DATA. RAMDC (existing command):


75 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Radio Control Administration, Measurement Result Recording Definition, Change Syntax Format 2: / \/ \ RAMDC:RID=rid|,CONTYPE=contype||,DTMFILTER=dtmfilter| \ /\ / / \ |,MEASTYPE=NOTYPE | | | | / \ | | |,MEASLIM=measlim | | |,MEASTYPE=PLDIFF,MEASINT=measint+ + | | |,MEASLIMN=measlimn| | | \ / | | | +,MEASTYPE=RXQUALLEV,MEASINT=measint,MEASLINK=measlink,+ | MEASLIM=measlim… | | | |,MEASTYPE=RXLEVTA,MEASINT=measint,MEASLINK=measlink, | | MEASLIM=measlim... | | | |,MEASTYPE=RXQUALTA,MEASLINK=measlink,MEASLIM=measlim..| | | |,MEASTYPE=meastype,MEASINT=measint,MEASLIM=measlim... | \ /

Parameters: DTMFILTER=dtmfilter DTM filter This parameter controls if measurement results shall be collected from DTM connections or not. NODTM

No measurement results will be collected for DTM

DTM

Only measurement results for DTM connections will be collected

BOTH

Measurement results for both DTM and non DTM connections will be collected

Note: Default value is BOTH.

Table: New parameter DTMFILTER in command RAMDC.

5.4.5

STS New or Modified Counters


76 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The counter TDTMALLOCATT is added in the object type CLDTMEST. 5.4.6

HW No impact.

5.5

94, Enhanced Measurement Reporting (EMR) Package: EMR_1

5.5.1

Description Link to IP 1/159 41-406/FCP 103 4829 As a measure of speech quality, the RxQual parameter as derived from the currently used Measurement Report (MR), is not considered very detailed and accurate, due to the relatively low correlation to the user perceived speech quality. In this feature the GSM message Enhanced Measurement Report is introduced as an alternative to currently used Measurement Report for the MS to report DL measurements, including additional measurement data. The EMR feature also enables refined BTS performed UL measurements to be included in the Measurement Result message, when sent to BSC. By this, e.g improved Rxlev and BEP (Bit Error Probability) information is provided in BSC with more detailed granularity than RxQual. For refined UL and DL power control, new target parameters for speech quality and signal strength (QDES and SSDES) are added to be separately applied on different speech versions (FR/ HR/AFR/ AHR/CSD) and hopping/non-hopping channel. Existing optional feature “AMR Power Control” is renamed to “CS Service Power Control” and function “Administration of Dynamic MS and AMR Power Control Data” is renamed to “Administration of Dynamic MS Power Control Data”. EMR is an optional feature and requires EMR capability of the MS as well as the BTS. It shall be implemented for all CS services. Full benefit of the EMR feature is achieved in combination with the subsequent SQS Enhancement feature, partly based on the EMR feature.

5.5.2

AXE parameter Being an optional feature, EMR shall be attached an optional feature parameter. Existing optional feature “AMR Power Control” shall be renamed to “CS Service Power Control” and function “Administration of Dynamic MS and AMR Power Control Data” shall be renamed to “Administration of Dynamic MS Power Control”.


No.

esteeds Approved

Checked


5.5.3

77 (125)


Rev

2010-12-22

Pa1

Reference


5.5.4

Command New commands RLEMI, –E, -P shall be created for the activation/deactivation/printout of the feature.

5.5.4.1

Administration of Cell Measurement Frequencies SISMS, block RCMFA CC, block RCCD

New command RLEMI Radio Control Cell, Enhanced Measurement Reporting, Initiate Syntax: RLEMI; Parameter: None Command receiving block: RCMFA Purpose: Activate EMR. It shall be checked that the EMR feature parameter EMRSUPPORT is activated before RLEMI is allowed to be executed. New command RLEME Radio Control Cell, Enhanced Measurement Reporting, End Syntax: RLEME; Parameter: None Command receiving block: RCMFA Purpose: Deactivate EMR. It shall be checked that the EMR feature parameter EMRSUPPORT is activated before RLEME is allowed to be executed. New command RLEMP


78 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Radio Control Cell, Enhanced Measurement Reporting, Print Syntax: RLEMP; Parameter: None Command receiving block: RCMFA Purpose: Print out of EMR status, active or not active. It shall be checked that the EMR feature parameter EMRSUPPORT is activated before RLEMP is allowed to be executed. Print out in accordance with POD. Printout: Enhanced Measurement Reporting EMRSTATE emrstate END

5.5.4.2

Administration of Dynamic BTS Power Control Data. RCQS, block RQBPWAU, RQCDU Ambition level 2: A number of power control parameters, currently being stored in RQCD on subcell level and entered with command RLBCC, shall instead be stored on BSC level in RQCD, entered with new commands RLBPC and RLBAC. Those commands, with corresponding print commands, shall be created in RQBPWA and command RLBCC shall be. Parameters, excluded from command RLBCC for storage on BSC level are QDESDL, SSDESDL, QCOMPDL and LCOMPDL to be included in command RLBPC and QLENDL, SSLENDL and REGINTDL to be included in command RLBAC. The parameters QDESDLAFR and SSDESDLAFR, shall be excluded from the RLAPC command and be included in command RLBPC for storage on BSC level.


79 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

New parameters for enhanced power control, shall also be included in the RLBPC command: QDESDLFR, QDESDLFRHOP, QDESDLAFRHOP, QDESDLHR, QDESDLHRHOP, QDESDLAHR, QDESDLAHRHOP, QDESDLCSD, QDESDLCSDHOP, SSDESDLFR, SSDESDLFRHOP, SSDESDLAFRHOP, SSDESDLHR, SSDESDLHRHOP, SSDESDLAHR, SSDESDLAHRHOP, SSDESDLCSD, SSDESDLCSDHOP The set of parameters within the RLBPC command comprises a profile of PC parameters for the BSC. 16 profiles shall be possible to enter and store with RLBPC, distinguished with a profile number (the DBPPROFILE parameter in the command). The 16 profiles shall initially be stored with Ericsson recommended values as default values. The subset of parameters in the profile that are valid, however (and possible to store), depends on the availability of the features Dynamic BTS Power Control and AMR Power Control. Existing optional feature parameter AMRPWRCTRL shall be made accessible to RQBPWA to enable the check of AMR Power Control (CS Service Power Control) feature. New command RLBPC Radio Control Cell, Dynamic BTS Power Control BSC Profile Data, Change Syntax: RLBPC: DBPPROFILE = dbpprofile { [,QDESDL=qdesdl]

[,QDESDLFR=qdesdlfr][,QDESDLFRHOP=qdesdlfrhop] [,QDESDLAFR=qdesdlafr][,QDESDLAFRHOP=qdesdlafrhop] [,QDESDLHR=qdesdlhr][,QDESDLHRHOP=qdesdlhrhop] [,QDESDLAHR=qdesdlahr][,QDESDLAHRHOP=qdesdlahrhop] [,QDESDLCSD=qdesdlcsd][,QDESDLCSDHOP=qdesdlcsdhop] [,SSDESDL=ssdesdl] [,SSDESDLFR=ssdesdlfr][,SSDESDLFRHOP=ssdesdlfrhop] [,SSDESDLAFR=ssdesdlafr][,SSDESDLAFRHOP=ssdesdlafrhop] [,SSDESDLHR=ssdesdlhr][,SSDESDLHRHOP=ssdesdlhrhop] [,SSDESDLAHR=ssdesdlahr][,SSDESDLAHRHOP=ssdesdlahrhop] [,SSDESDLCSD=ssdesdlcsd][,SSDESDLCSDHOP=ssdesdlcsdhop] [,LCOMPDL=lcompdl][,QCOMPDL=qcompdl] };

Parameters: Parameter name

Description

DBPPROFILE QDESDL

Profile no Desired qual DL

30

1 - 16 0 - 77

dtqu

1)

QDESDLFR

Desired qual DL Full rate Desired qual DL Full rate, freq hopping

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

QDESDLFRHOP

Default value

Value Unit Range

Valid


esteeds Approved

No.

Checked


QDESDLAFR QDESDLAFRHOP QDESDLHR QDESDLHRHOP QDESDLAHR QDESDLAHRHOP QDESDLCSD QDESDLCSDHOP SSDESDL SSDESDLFR SSDESDLFRHOP

SSDESDLAFR SSDESDLAFRHOP

SSDESDLHR SSDESDLHRHOP

SSDESDLAHR SSDESDLAHRHOP

SSDESDLCSD SSDESDLCSDHOP

QCOMPDL

80 (125)


Rev

2010-12-22

Pa1

Desired qual DL AMR Full rate Desired qual DL AMR Full rate, freq hopping Desired qual DL Half rate Desired qual DL Half rate, freq hopping Desired qual DL AMR Half rate Desired qual DL AMR Half rate, freq hopping Desired qual DL CS Data Desired qual DL CS Data, freq hopping Desired signal strength DL Desired signal strength DL Full rate Desired signal strength DL Full rate, freq hopping Desired signal strength DL AMR Full rate Desired signal strength DL AMR Full rate, freq hopping Desired signal strength DL Half rate Desired signal strength DL Half rate, freq hopping Desired signal strength DL AMR Half rate Desired signal strength DL AMR Half rate, freq hopping Desired signal strength DL CS Data Desired signal strength DL CS Data, Freq hopping Quality deviation compensator factor DL

Reference

40

0 - 77

dtqu

2)

40

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

- 90

-110 -47

dBm

1)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

- 90

-110 -47

dBm

2)

0100

%

3)

30


81 (125)

No.

esteeds Approved


Checked


LCOMPDL

Date

Rev

2010-12-22

Pa1

70

Path loss compensator factor DL

0100

Reference

%

3)

1) Valid if Dynamic BTS Power Control feature is available AND AMR Power Control feature NOT available. 2) Valid if AMR Power Control feature available. 3) Valid if Dynamic BTS Power Control feature OR AMR Power Control feature available. Note: AMR Power Control is the existing feature name, will be changed to CS Service Power Control in this feature. Purpose: Storage of DL Power Control data on BSC level, structured in different profiles. New command RLBPP Radio Control Cell, Dynamic BTS Power Control BSC Profile Data, Print Syntax: / \ |profile| RLBPP: DBPPROFILE = + + ; | ALL |

\

/

Parameters: DBPPROFILE

profile

Numeral 1 – 16. The profile number for which data shall be printed All 16 profiles shall be printed

ALL Purpose: Print out of DL Power Control data for BSC per profile, stored with the RLBPC command. New command RLBAC Radio Control Cell, Dynamic BTS Power Control Additional BSC Data, Change Syntax: RLBAC: { [REGINTDL=regintdl] [,SSLENDL=sslendl] [,QLENDL=qlendl] };

Parameters:


82 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

Parameter name

Description

Default value

Value Unit Range

REGINTDL

Regulation interval DL

1

1 - 10

SSLENDL

Length of signal strength filter DL

3

3 - 15

QLENDL

Length of stationary quality filter DL

3

1 - 20

SACCH periods SACCH periods SACCH periods

Purpose: Storage of DL Power Control additional data on BSC level. New command RLBAP Radio Control Cell, Dynamic BTS Power Control Additional BSC Data, Print Syntax: RLBAP ; Parameters:: None Purpose: Print out of DL Power Control additional data on BSC level, stored with the RLBAC command. Changed command RLBCC Radio Control Cell, Dynamic BTS Power Control Cell Data, Change Syntax: / \ | / \ | | | sctype| | RLBCC:CELL=cell |,SCTYPE = + + | [,DBPPROFILE=dbpprofile] | | ALL | | | \ / | \ / / |,BSPWRMINP=bspwrminp + |,BSPWRMINN=bspwrminn \

\ | + ; | /


83 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

Parameters:

5.5.5

DBPPROFILE

New parameter Profile number for selected Power Control data Numeral 1 – 16. Default: 1

CELL SCTYPE BSPWRMINP BSPWRMINN

Existing. Existing. Existing. Existing.

Administration of Dynamic MS and AMR Power Control Data. RCQS, block RQPWAU, RQCDU Ambition level 2: A number of power control parameters, currently being stored in RQCD on subell level and entered with commands RLPCC and RLAPC, shall instead be stored on BSC level in RQCD, entered with new commands RLMPC and RLMAC. Those commands, with corresponding print commands, shall be created in RQPWA and command RLPCC shall be. Command RLAPC shall be removed. Parameters, excluded from command RLPCC for storage on BSC level are QDESUL, SSDESUL, QCOMPUL and LCOMPUL, to be included in command RLMPC, and QLENUL, SSLENUL and REGINTUL to be included in command RLMAC. The parameters QDESULAFR and SSDESULAFR, shall be excluded from the RLAPC command and be included in command RLMPC for storage on BSC level. New parameters for enhanced power control, shall also be included in the RLMPC command: QDESULFR, QDESULFRHOP, QDESULAFRHOP, QDESULHR, QDESULHRHOP, QDESULAHR, QDESULAHRHOP, QDESULCSD, QDESULCSDHOP, SSDESULFR, SSDESULFRHOP, SSDESULAFRHOP, SSDESULHR, SSDESULHRHOP, SSDESULAHR, SSDESULAHRHOP, SSDESULCSD, SSDESULCSDHOP The set of parameters within the RLMPC command comprises a profile of PC parameters for the BSC. 16 profiles shall be possible to enter and store with RLMPC, distinguished with a profile number (the DMPPROFILE parameter in the command). The 16 profiles shall initially be stored with Ericsson recommended values as default values. The subset of parameters in the profile that are valid, however (and possible to store), depends on the availability of the features Dynamic MS Power Control and AMR Power Control. Validity and default values are described in the parameter description in chapter 5.1.15.1


84 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

Feature AMR Power Control shall be renamed to CS Service Power Control. The optional feature parameter AMRPWRCTRL shall be reused. Function “Administration of Dynamic MS and AMR Power Control Data” shall be renamed to “Administration of Dynamic MS Power Control Data”. New command RLMPC Radio Control Cell, Dynamic MS Power Control BSC Profile Data, Change Syntax: RLMPC: DMPROFILE = dmpprofile { [,QDESUL=qdesul]

[,QDESULFR=qdesulfr][,QDESULFRHOP=qdesulfrhop] [,QDESULAFR=qdesulafr][,QDESULAFRHOP=qdesulafrhop] [,QDESULHR=qdesulhr][,QDESULHRHOP=qdesulhrhop] [,QDESULAHR=qdesulahr][,QDESULAHRHOP=qdesulahrhop] [,QDESULCSD=qdesulcsd][,QDESULCSDHOP=qdesulcsdhop] [,SSDESUL=ssdesul] [,SSDESULFR=ssdesulfr][,SSDESULFRHOP=ssdesulfrhop] [,SSDESULAFR=ssdesulafr][,SSDESULAFRHOP=ssdesulafrhop] [,SSDESULHR=ssdesulhr][,SSDESULHRHOP=ssdesulhrhop] [,SSDESULAHR=ssdesulahr][,SSDESULAHRHOP=ssdesulahrhop] [,SSDESULCSD=ssdesulcsd][,SSDESULCSDHOP=ssdesulcsdhop] [,LCOMPUL=lcompul][,QCOMPUL=qcompul] };


Description

DMPPROFILE QDESUL

Profile no Desired qual UL

30

1 - 16 0 - 77

dtqu

1)

QDESULFR

Desired qual UL Full rate Desired qual UL Full rate, freq hopping Desired qual UL AMR Full rate Desired qual UL AMR Full rate, freq hopping Desired qual UL Half rate Desired qual UL Half rate, freq hopping Desired qual UL AMR Half rate Desired qual UL AMR Half rate,

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

40

0 - 77

dtqu

2)

40

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

QDESULFRHOP QDESULAFR QDESULAFRHOP QDESULHR QDESULHRHOP QDESULAHR QDESULAHRHOP

Default value

Value Unit Range

Valid


85 (125)

No.

esteeds Approved

Checked


QDESULCSD QDESULCSDHOP SSDESUL SSDESULFR SSDESULFRHOP

SSDESULAFR SSDESULAFRHOP

SSDESULHR SSDESULHRHOP

SSDESULAHR SSDESULAHRHOP

SSDESULCSD SSDESULCSDHOP

QCOMPUL

LCOMPUL


Rev

2010-12-22

Pa1

freq hopping Desired qual UL CS Data Desired qual UL CS Data, freq hopping Desired signal strength UL Desired signal strength UL Full rate Desired signal strength UL Full rate, freq hopping Desired signal strength UL AMR Full rate Desired signal strength UL AMR Full rate, freq hopping Desired signal strength UL Half rate Desired signal strength UL Half rate, freq hopping Desired signal strength UL AMR Half rate Desired signal strength UL AMR Half rate, freq hopping Desired signal strength UL CS Data Desired signal strength UL CS Data, Freq hopping Quality deviation compensator factor UL Path loss compensator factor UL

Reference

30

0 - 77

dtqu

2)

30

0 - 77

dtqu

2)

- 92

-110 -47

dBm

1)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

- 92

-110 -47

dBm

2)

30

0100

%

3)

70

0100

%

3)

1) Valid if Dynamic MS Power Control feature is available AND AMR Power Control feature NOT available. 2) Valid if AMR Power Control feature available. 3) Valid if Dynamic MS Power Control feature OR AMR Power Control feature available.


86 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

Note: AMR Power Control is the existing feature name, will be changed to CS Service Power Control in this feature. Purpose: Storage of UL Power Control data on BSC level, structured in different profiles. New command RLMPP Radio Control Cell, Dynamic MS Power Control BSC Profile Data, Print Syntax:: / \ |profile| RLMPP: DMPPROFILE = + + ; | ALL |

\

/

Parameters: DMPPROFILE

profile ALL

Numeral 1 – 16. The profile number for which data shall be printed All 16 profiles shall be printed

Purpose: Print out of UL Power Control data for BSC per profile, stored with the RLMPC command. New command RLMAC Radio Control Cell, Dynamic MS Power Control Additional BSC Data, Change Syntax: RLMAC: { [REGINTUL=regintul] [,SSLENUL=sslenul] [,QLENUL=qlenul] };


Description

Default value

Value Unit Range

REGINTUL

Regulation interval UL

1

1 - 30

SACCH periods


87 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

SSLENUL

Length of signal strength filter UL

3

3 - 15

QLENUL

Length of stationary quality filter UL

3

1 - 20

SACCH periods SACCH periods

Purpose: Storage of UL Power Control additional data on BSC level.

New command RLMAP Radio Control Cell, Dynamic MS Power Control Additional BSC Data, Print Syntax: RLMAP ;

Parameters:: None Purpose: Print out of UL Power Control additional data on BSC level, stored with the RLMAC command. Changed command RLPCC Radio Control Cell, Dynamic MS Power Control Cell Data, Change Syntax: / \ | / \ | | | sctype| | RLPCC:CELL=cell |,SCTYPE = + + | | | ALL | | | \ / | \ / [,DMPPROFILE=dmpprofile] ,DTXFUL=dtxful ;

Parameters: DMPPROFILE

New parameter. Profile number for selected Power Control data Numeral 1 – 16. Default: 1

CELL

Existing.


88 (125)

No.

esteeds Approved


Checked


SCTYPE DTXFUL

Date

Rev

2010-12-22

Pa1

Reference

Existing. Existing.

Deleted command RLAPC Radio Control Cell, Dynamic AMR Power Control Cell Data, Change Command RLAPC shall be removed. Parameters in the command shall be moved to command RLBPC and RLMPC, stored on BSC level instead of subcell level.

Changed commands RLAPI, RLAPE and RLAPP The command titles for RLAPI, RLAPE and RLAPP shall be changed to “CS Service Power Control Cell Data” Changed POD for command RLAPP Radio Control Cell, CS Service Power Control Cell Data, Print The printout for command RLAPP shall be changed due to the removed parameters in deleted command RLAPC. Title shall be changed according to changed feature name. 5.5.6

STS No impact.

5.5.7

HW No impact.

5.6

432, R12 Impact on Data Transcript Package: EITQP_1

5.6.1

Description Link to IP 4/159 41-409/FCP 103 4829 Ericsson Instant Talk Quality Package is a feature that aims to improve the quality of Ericsson Instant Talk (EIT), which is the Ericsson implementation of Push To Talk over Cellular (PoC). PoC is a kind of Walkie-Talkie service in a cellular network using a Voice over IP application (VoIP). Support for EIT was introduced already in BSS R11. The implementation in R11 gave the basic support for PoC services.


89 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The additions in R12 will improve the overall quality of the EIT service. Admission Control is a sub-feature that ensures that the EIT users get the requested Quality of Service to as large extent as possible. The rest of the sub-features will further adapt the system to the needs of EIT. There are improvements in the following areas: • Decreased access times • Shorter delays • Improved cell re-selection • Increased robustness Quality improvements in R12 R11 introduced the basic support for EIT and focused mainly on improving the capacity for the streaming bearer used for EIT. This was done by the introduction of multiplexing EIT streaming bearers on the same PDCH. In R12 the main focus for EIT will be to improve and guarantee the quality for the end user. Studies have been performed to analyse possible improvements to the EIT performance. The first improvement area is to achieve better guarantees so that the EIT user receives the requested QoS. The sub-feature in this area is: •

Admission Control

The second area of improvements is related to further modification of procedures and algorithms in BSS. This to make the system better suited for characteristics requirements for EIT. Improvements is this area are as follows: • • •

Improved inter-BSC Cell Change Improved RLC polling that reduces the delay caused by re-transmissions. Shorter access times to the system. Proposals in this area are EGPRS Access on CCCH and ARAC Retransmission.

5.6.2

AXE parameter

5.6.3

Optional Feature Dependency The EIT Quality Package introduces the following optional features: • EITQP • ADMCTRL • INTERNACC EITQP controls the availability of the subfeatures: • Improved RLC Polling • ARAC Retransmission • EGPRS Access on CCCH ADMCTRL controls the availability of the subfeature Admission Control


90 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

INTERNACC controls the availability of the subfeature Improved inter-BSC Cell Reselection. The dependency to existing optional features GPRS and EIT is indicated in Figure.

GPRS

NACC

EIT

INTERNACC

- Improved Inter BSC Cell Reselection

EITQP

- Improved RLC Polling - ARAC Retransmission - EGPRS Access on CCCH

ADMCTRL

- Admission Control

Figure Optional feature dependency

5.6.3.1

EITQP A new BSC wide optional feature shall be introduced to switch on support for subfeatures. The proposal for the optional feature is: •

Global Parameter: EITQP

The EITQP shall be an AXE Parameter and shall have the following possible values: 0 = FEATURE UNAVAILABLE 1 = FEATURE AVAILABLE


91 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The default value shall be 0. The CLASS of the parameter shall be ‘FEATURE’ and the distribution shall be ‘IMMEDIATE’. The value shall be given on a commercial agreement basis only. The AXE parameter shall be implemented in the block RGRLCU and also used by RGCONU. Note: EITQP will be unavailable if the optional feature GPRS is unavailable or if the optional feature EIT is unavailable. 5.6.3.2

ADMCTRL A new BSC wide optional feature shall be introduced to switch on support for the Admission Control feature. The proposal for the optional feature is: •

Global Parameter: ADMCTRL

The ADMCTRL shall be an AXE Parameter and shall have the following possible values: 0 = FEATURE UNAVAILABLE 1 = FEATURE AVAILABLE The default value shall be 0. The CLASS of the parameter shall be ‘FEATURE’ and the distribution shall be ‘IMMEDIATE’. The value shall be given on a commercial agreement basis only. The AXE parameter shall be implemented in the block RGRLCU. Note: ADMCTRL will be unavailable if the optional feature GPRS is unavailable or if the optional feature EIT is unavailable. 5.6.3.3

INTERNACC A new BSC wide optional feature shall be introduced to switch on support for the Improved Inter BSC Cell re-selection feature. The proposal for the optional feature is: •

Global Parameter: INTERNACC

The INTERNACC shall be an AXE Parameter and shall have the following possible values: 0 = FEATURE UNAVAILABLE 1 = FEATURE AVAILABLE The default value shall be 0. The CLASS of the parameter shall be ‘FEATURE’ and the distribution shall be ‘IMMEDIATE’. The value shall be given on a commercial agreement basis only. The AXE parameter shall be implemented in the block RGRLCU.RGCONU. Note: INTERNACC will be unavailable if the optional feature GPRS is unavailable or if the optional feature NACC is unavailable.


No.

esteeds Approved


Checked


5.6.4

92 (125)

Date

Rev

2010-12-22

Pa1

Reference


5.6.5

Command Title: RLBDC, Radio Control Cell, Configuration BPC Data, Change Change: EGPRS Access on CCCH: Add parameter EACPREF Title: RLGQC, Radio Control Cell, GPRS Quality of Service Data, Change Change: Admission Control: Add parameter EITEXCLUDED

5.6.6

STS

5.6.6.1

Influence on STS

Counters per BSC Counters per Cell

2


2 * 512 =1024 W16

The two counters are inserted in the STS object type TRAFGPRS2.

5.6.6.2

New or Modified Counters New STS Counters

5.6.6.3

Counter

Size

ADMCTRLREQ

W16

ADMCTRLREJ

W16

Affected Counters Modified STS Counters

Counter

Size

Comment


93 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

PSCHREQ W16 Incremented also for EGPRS Packet Channel Requests on CCCH

5.6.7

PREJOTH

W16 Incremented also for EGPRS Packet Channel Requests on CCCH

PREJTFI

W16 Incremented also for EGPRS Packet Channel Requests on CCCH

HW No impact.

6

Shipment 6

6.1

239.1, R12 Impact on Data Transcript Package: IABIS_1

6.1.1

Description Link to IP 1/159 41-428/FCP 103 4829 Improved Abis Utilization is intended for more efficient use of available bandwidth on Abis. This Implement Proposal covers ambition level 1: •

The ambition level 1, referred to as a sub-feature Enhancements to Flexible Abis,

The ambition level 1, referred to as a sub-feature Enhancements to Flexible Abis, introduces several improvements to the existing optional feature Flexible Abis to prevent congestion on Abis. Abis congestion is here understood lack of Abis paths in any of the two pools that prevents activation of a Circuit Switched (CS) or Packet Switched (PS) channel. The following functionalities will be included in this feature: • • • • • • • • • •

Packing of 16 kbps Abis paths in 64KRES pool Packing of 16 kbps GSL devices in the RPPs Support for CS-3 and CS-4 when FLEXHIGHGPRS set to 16 kbps Pre-emption at Abis congestion Consider upgrade from B- to E-PDCH in TBF upgrade/re-reservation Move of cell enhancements BSC Exchange Property FLEX64KGPRS changed to cell parameter Re-structuring of block RTAPH Improvement to use GSL individual on LPDCH Improved downgrading of Abis Path


No.

esteeds Approved

Checked


6.1.2

94 (125)


Rev

2010-12-22

Pa1

Reference

AXE parameter The ambition level 1, referred to as a sub-feature Enhancements to Flexible Abis, introduces several improvements to the existing optional feature Flexible Abis (FLEXABIS) DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=FLEXABIS, VALUE=1;

6.1.3

Exchange Property The BSC Exchange Property FLEX64KGPRS shall be removed and replaced with the new cell parameter FLEXHIGHGPRS. The cell parameter FLEXHIGHGPRS is a new parameter in the existing command RLGSC.

6.1.4

Command Title: RXMOI Radio X-ceiver Administration, Managed Object, Initiate Change: New parameter ABIS64KTHR Title: RXMOC Radio X-ceiver Administration, Managed Object, Change Change: New parameter ABIS64KTHR Title: RXMSC Radio X-ceiver Administration, Managed Object in Service Data, Change Change: New parameter ABIS64KTHR Title: RLGSC Change: Add the new cell parameter FLEXHIGHGPRS indicates whether to allocate 64 kbps or 16 kbps Abis paths for none-EGPRS capable mobiles, the values can be: •0 = 16 kbps Abis path. •1 = 64 kbps Abis path.

6.1.4.1

RXMOI (existing command) Radio X-ceiver Administration, Managed Object, Initiate Syntax: In BTS Logical Model G12 RXMOI:MO=mo...,COMB=comb,RSITE=rsite,SWVER=swver [,TRACO=traco][,SIGDEL=sigdel] [,ABISALLOC=abisalloc]


95 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

[,ABIS64KTHR=abis64kthr];

Parameters: ABIS64KTHR=abis64kthr Packing threshold for 64KRES pool of Abis paths This parameter defines a threshold value for packing of flexibly allocated Abis paths in 64KRES pool. The threshold is expressed as a percentage of the total number of Abis paths in 64KRES pool. The packing is started when the number of idle Abis paths in 64KRES pool drops below the threshold value and stopped when the number of idle Abis paths in 64KRES pool exceeds the value determined by this parameter. The availability of this parameter depends on commercial agreements. Numeral 0 – 100 Note: Default value is 0.

Table: New parameter ABIS64KTHR

6.1.4.2

RXMOC (existing command) Radio X-ceiver Administration, Managed Object Data, Change Syntax: In BTS Logical Model G12 / RXMOC:MO=mo...+[,FHOP=fhop][,SWVER=swver][,COMB=comb] \ [,RSITE=rsite][,TRACO=traco][,CONFACT=confact] [,CONFMD=confmd][,SIGDEL=sigdel][,AHOP=ahop]

[,ABISALLOC=abisalloc] \ [,ABIS64KTHR=abis64kthr]+; /

Parameters: See above


No.

esteeds Approved

Checked


6.1.4.3

96 (125)


Rev

2010-12-22

Pa1

Reference

RXMSC (existing command) Radio X-ceiver Administration, Managed Object In Service Data, Change Syntax: In BTS Logical Model G12 / RXMSC:MO=mo...+[,SWVER=swver][,RSITE=rsite] \ [,CONFACT=confact][,CONFMD=confmd] [,AHOP=ahop][,ABISALLOC=abisalloc], \ [,ABIS64KTHR=abis64kthr]+; /

Parameters: See above

6.1.5

STS

6.1.5.1

Influence on STS Counters per BSC Counters per Cell

3

Counters per TG

7

Counters per … Total Number of Counters for a BSC/TRC 6.1.5.2

5120

New or Modified Counters RCS Two new STS counters shall be implemented per cell in RNLCT. The STS counters will be in the existing DID CELLFLXABCNT. The counters are used to give a ratio between the number of successful allocations of 16k flexible Abis paths for CS and number of attempts to allocate 16k flexible Abis paths for CS. RNLCT shall step the new counter FLXCS16ATT for each attempt to allocate a 16k Abis path for CS. RNLCT shall step the new counter FLXCS16SUCC for each successful allocation of a 16k Abis path for CS. There is a new counter PMTABCONG implemented in RGCNTU that counts when there is pre-emption due to Abis congestion. This new counter will be in the existing DID CELLGPRSCNT.


97 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

No existing STS counters have been modified. RTS Two new object types 64KRES and NON64KRES shall be introduced. The object types will be defined as follows: Object Type = 64KRES Status of the 64KRES pool of Abis paths Type -----ST

Counter name -----------MIN64K

Description ---------------------------Minimum number of idle 64 kbps Abis paths in 64KRES pool during last 15 minutes, calculated from samples taken every minute

ST

MAX64K

Maximum number of idle 64 kbps Abis paths in 64KRES pool during last 15 minutes, calculated from samples taken every minute

ST

AVG64K

Average number of idle 64 kbps Abis paths in 64KRES pool during last 15 minutes, calculated from samples taken every minute

ST

FRAG64K

Fragmentation level of the 64KRES pool, i.e. the number of fragmented (partly used) 64 kbps Abis paths in the 64KRES pool

Object Type = NON64KRES Status of the non-64KRES pool of Abis paths Type -----ST

Counter name -----------MIN16K

Description ---------------------------Minimum number of idle 16 kbps Abis paths in non-64KRES pool during last 15 minutes, calculated from samples taken every minute

ST

MAX16K

Maximum number of idle 16 kbps Abis paths in 64KRES pool during last 15 minutes, calculated from samples taken every minute

ST

AVG16K

Average number of idle 16 kbps Abis paths in 64KRES pool during last 15 minutes, calculated from samples taken every minute


98 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The block RTAPH shall report two new DIDs with the signal interface DIDINFO/ACK: • 64KRESCNT – corresponding to the object type 64KRES • NON64RESCNT – corresponding to the object type NON64KRES The counters for both objects will be located in ANI file. The size of the file will be the same as in the design base, i.e. 512 individuals. The counters shall be presented per TG. To do that, the block RTAPH shall use the existing DID COMMOTGTRANTAB (381) to translate ANI pointer to TG designation. The length of all the counters in the object type 64KRES shall be 8 bits. The length of all the counters in the object type NON64KRES shall be 16 bits.

6.1.6

HW No impact.

6.2

239.2, R12 Impact on Data Transcript Package: IABIS_1

6.2.1

Description Link to IP 2/159 41-428/FCP 103 4829 This IP describes a proposal to implement ambition level 3 of the RS ‘Improved Abis Utilization’. All of the functionality introduced in this subfeature will be included in one and the same ambition level in this IP. However, this ambition level consist of the following three parts: Allocation of (AMR) HR channels The design base feature ‘Dynamic Halfrate Allocation’ allocates AMR HR and HR channels when there is a lack of AMR FR and FR channels in a cell. In BSC R12, the same functionality shall be triggered also if there is a shortage of resources in the non-64KRES Abis pool. Move from (AMR) FR to (AMR) HR The design base features ‘HR Packing’ and ‘Dynamic FR/HR Mode Adaptation’ packs AMR HR and HR channels respectively moves AMR FR and FR channels to AMR HR and HR when there is a lack of AMR FR or FR in a cell. In BSC R12, the same functionality shall be triggered if there is a shortage of resources in the non-64KRES Abis pool. Allocation of AMR FR with reduced codec set It shall be possible to allocate AMR FR connections with codecs restricted to a maximum of 7.4 kbps and use half of a 16 kbps Abis path for the connection.


99 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

One and each of these new functionalities shall be implemented as an optional feature. This means that they shall work on their own but also be able to co-exist with each other. All three features will be administered by means of the existing commands RXMOI, RXMOC, RXMSC. New parameters will be introduced that will define a thresholds for packing of Abis paths. These commands will also include a parameter to enable/disable the feature ‘Dynamic AMR FR Codec Reduction’ on a TG level. New commands RLDAC and RLDAP shall be introduced to enable/disable the features ‘Dynamic HR Allocation on Abis’ and ‘Dynamic FR/HR Mode Adaptation on Abis’ on a cell level. 6.2.2

AXE parameter The function Administration of Managed Objects (RXEATA) shall control the availability of new optional features, thus the following AXE Parameters need to be introduced within parameter set CME20BSCF with class Feature. •

Feature: Dynamic HR Allocation on Abis: DHAABIS

•

Feature: Dynamic FR/HR Mode Adaptation on Abis: DYMAABIS

•

Feature: Dynamic AMR FR Codec Reduction: DAMRREDUCE

DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=DHAABIS, VALUE=1; DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=DYMAABIS, VALUE=1; DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=DAMRREDUCE, VALUE=1; 6.2.3


6.2.4

Command Doc. No: x Rev: x Title: RLDAC, Radio Control Cell, Dynamic Allocation on Abis, Change Change: New command Doc. No: x Rev: x Title: RLDAP, Radio Control Cell, Dynamic FR/HR Mode Adaptation, Print Change: New command Doc. No: 2/190 82-CNT 241 1389 Rev: H1 Title: RXMOI, Radio X-ceiver Administration Managed Object, Initiate Change: Add new parameters DHRAABISTHR, DFRMAABISTHR, DAMRREDABISTHR, DAMRCR and faultcode


100 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Doc. No: 3/190 82-CNT 241 1389 Rev: H Title: RXMOC, Radio X-ceiver Administration Managed Object, Change Change: Add new parameters DHRAABISTHR, DFRMAABISTHR, DAMRREDABISTHR, DAMRCR and faultcode Doc. No: 13/190 82-CNT 241 1389 Rev: B Title: RXMSC, Radio X-ceiver Administration Managed Object in Service Data, Change Change: Add new parameters, DHRAABISTHR, DFRMAABISTHR, DAMRREDABISTHR, DAMRCR and faultcode

6.2.4.1

RLDAC, Allocation of (AMR) HR channels The block RCCHPA shall be defined as a user of the optional feature parameter ‘DHAABIS’. Two new commands, RLDAC and RLDAP shall be introduced to control behavior of the feature on cell level. Parameter ‘DHABIS’ shall be introduced in command RLDAC to make it possible for the operator to enable/disable the feature ‘Dynamic HR Allocation for Abis’ per cell. The default value shall be set to ‘off’ and the optional feature parameter shall be checked every time the feature shall be turned on per cell. If the optional feature is not available in the BSC, the existing fault code 164 ‘Functionality not supported by this exchange’ shall be printed. If the parameter is changed, RCCD shall store and use the existing signal interface to inform the block RNLCT in the function ‘THOLC’ about the changes. It shall be possible to print the parameter DHABIS by using new command RLDAP. When the command RLDAP is entered new POD ‘CELL DYNAMIC ALLOCATION ON ABIS’ shall be issued. Command RLDAC (New) Radio Control Cell, Dynamic Allocation on Abis, Change Syntax: RLDAC:CELL=cell,DHABIS=dhabis;


101 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

Parameters: DHABIS = DHABIS Dynamic Half Rate (HR) Allocation for Abis OFF

Dynamic HR Allocation for Abis is disabled.

On

Dynamic HR Allocation for Abis is enabled.

Note: Default value is OFF.

Table: New parameter DHABIS in command RLDAC.

Command RLDAP (New) Radio Control Cell, Dynamic Allocation on Abis, Print Syntax: / \ |cell …| RLDAP:CELL=+ +; |ALL | \ /

6.2.4.2

RLDAC, Move from (AMR) FR to (AMR) HR The block RCCHPA shall be defined as a user of the optional feature parameter ‘DYMAABIS’. A new parameter, with proposed name ‘DMABIS’ shall be added to the new command RLDAC. The parameter shall be introduced to make it possible for the operator to enable/disable the feature ‘Dynamic FR/HR Mode Adaptation on Abis’ per cell. The default value shall be set to ‘off’ and the new optional feature parameter (DYMAABIS) shall be checked every time this parameter is enabled per cell. If the optional feature is not available in the BSC, the existing fault code 164 ‘Functionality not supported by this exchange’ shall be printed. If the parameter is changed, RCCD shall store and use the existing signal interface to inform the block RNLCT in the function ‘THOLC’ about the changes.


102 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

It shall be possible to print the parameter DMABIS by using new command RLDAP. When the command RLDAP is entered new POD ‘CELL DYNAMIC ALLOCATION ON ABIS’ shall be issued. Command RLDAC (New) Radio Control Cell, Dynamic Allocation on Abis, Change Syntax: / \ RLDAC:CELL=cell+[,DHABIS=dhabis][DMABIS=dmabis]+; \ /

DMABIS = dmabis Parameters:

Dynamic FR to HR Mode Adaptation on Abis OFF

The feature is deactivated.

ON

The feature is activated

Note: Default value is OFF.

Table: New parameter DMABIS in command RLDAC. 6.2.4.3

Summery for RXMOI, RXMOC, RXMSC, The following threshold parameters need to be introduced for new features. •

Feature: Dynamic HR Allocation on Abis: DHRAABISTHR

•

Feature: Dynamic FR/HR Mode Adaptation on Abis: DFRMAABISTHR

•

Feature: Dynamic AMR FR Codec Reduction: DAMRREDABISTHR

For the feature Dynamic AMR FR Codec Reduction, extra optional parameter DAMRCR needs to be introduced on the TG level in order to be able to switch on/off the feature per TG. The new parameters will be optional and will be output in the following cases:

• DHRAABISTHR output if optional feature Flexible Abis and optional feature Dynamic HR Allocation on Abis are available and existing parameter ABISALLOC=FLEXIBLE.


103 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

• DFRMAABISTHR output if optional feature Flexible Abis and optional feature Dynamic FR/HR Mode Adaptation on Abis are available and existing parameter ABISALLOC=FLEXIBLE. • DAMRCR output if optional feature Flexible Abis and optional feature Dynamic AMR FR Codec Reduction are available and existing parameter ABISALLOC=FLEXIBLE. • DAMRREDABISTHR output if optional feature Flexible Abis and optional feature Dynamic AMR FR Codec Reduction are available and existing parameter ABISALLOC=FLEXIBLE. Also parameter DAMRCR shall be set to ON.

6.2.4.4

RXMOI (existing command) Radio X-ceiver Administration, Managed Object, Initiate Syntax: In BTS Logical Model G12 RXMOI:MO=mo...,COMB=comb,RSITE=rsite,SWVER=swver [,TRACO=traco][,SIGDEL=sigdel] [,ABISALLOC=abisalloc][,DHRAABISTHR=dhraabisthr] [,DFRMAABISTHR=dfrmaabisthr][,DAMRCR=damrcr] [,DAMRREDABISTHR=damrredabisthr];


104 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Parameters: DHRAABISTHR=dhraabisthr Dynamic HR allocation threshold for 16 kbps pool of Abis paths This parameter defines a threshold value for starting and stopping the allocation of AMR HR and HR channels using Abis devices from the 16 kbps pool. The threshold value is expressed as percentage of idle 16 kbps Abis devices, out of nominal number of devices in the pool. The allocation of HR channels due to shortage of Abis resources is started when number of idle 16 kbps Abis devices falls below the threshold value. When value 0 is given then this allocation is stopped. The availability of this parameter depends on commercial agreements. Numeral 0 – 100 Note: Default value is.

DFRMAABISTHR=dfrmaabisthr DYMA threshold for 16 kbps pool of Abis paths This parameter defines a threshold value for starting and stopping packing of FR and AMR FR channels and for starting and stopping of move from FR to HR channels, including AMR, using 16 kbps Abis devices in the 16 kbps pool. The threshold value shall be expressed as percentage of idle 16 kbps devices out of nominal number of devices in the pool. The packing and moving of channels due to shortage of Abis resources is started when number of idle 16 kbps Abis devices falls below a threshold value. When value 0 is given then this packing and moving is stopped. The availability of this parameter depends on commercial agreements. Numeral 0 – 100 Note: Default value is 0.


esteeds Approved

105 (125)

No.

Checked



Rev

2010-12-22

Pa1

Reference

DAMRCR=damrcr AMR FR with reduced codec allocation control This parameter is used to control the availability of the feature per TG. The availability of this parameter depends on commercial agreements. OFF – Feature is deactivated ON – Feature is activated Note: Default value is OFF.

DAMRREDABISTHR=damrredabisthr AMR FR with reduced codec allocation threshold for 16 kbps pool of Abis paths This parameter defines a threshold value for starting and stopping the allocation of AMR FR channels with reduced codec set using devices from the 16 kbps pool. The threshold value is expressed as percentage of idle 16 kbps devices, out of nominal number of devices in the pool. The allocation of these channels due to shortage of Abis resources is started when number of idle 16 kbps devices falls below a threshold value. The availability of this parameter depends on commercial agreements. Numeral 1 – 100 Note: Default value is 20. Table: New parameters DHRAABISTHR, DFRMAABISTHR, DAMRCR, DAMRREDABISTHR


No.

esteeds Approved

Checked


6.2.4.5

106 (125)


Rev

2010-12-22

Pa1

Reference

RXMOC (existing command) Radio X-ceiver Administration, Managed Object Data, Change Syntax: In BTS Logical Model G12 / RXMOC:MO=mo...+[,FHOP=fhop][,SWVER=swver][,COMB=comb] \ [,RSITE=rsite][,TRACO=traco][,CONFACT=confact] [,CONFMD=confmd][,SIGDEL=sigdel][,AHOP=ahop] [,ABISALLOC=abisalloc][,DHRAABISTHR=dhraabisthr] [,DFRMAABISTHR=dfrmaabisthr][,DAMRCR=damrcr] \ [,DAMRREDABISTHR=damrredabisthr]+; /

6.2.4.6

RXMSC (existing command) Radio X-ceiver Administration, Managed Object In Service Data, Change Syntax: In BTS Logical Model G12 / RXMSC:MO=mo...+[,SWVER=swver][,RSITE=rsite] \ [,CONFACT=confact][,CONFMD=confmd] [,AHOP=ahop][,ABISALLOC=abisalloc], [,DHRAABISTHR=dhraabisthr][,DFRMAABISTHR=dfrmaabisthr] \ [,DAMRCR=damrcr][,DAMRREDABISTHR=damrredabisthr]+; /


No.

esteeds Approved


Checked


6.2.4.7

107 (125)

Date

Rev

2010-12-22

Pa1

Reference

RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT DATA (existing printout) RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT DATA . . . |/ ||MO ||motg-G12 || || || || || || || || || || || || ||. ||. ||. ||MO ||motg-G12 || || || || || || || || || |\ . .

6.2.5

6.2.5.1

\| MODEL|| model|| || SWVERREPL SWVERDLD SWVERACT || [swverrepl] [swverdld] [swveract] || || CONFMD CONFACT TRACO ABISALLOC || confmd confact traco [abisalloc] || || DHRAABISTHR DFRMAABISTHR DAMRCR DAMRREDABISTHR || [ahraabisthr][dfrmaabisthr][damrcr][damrredabisthr] || || TGFID SIGDEL BSSWANTED || tgfid sigdel [bsswanted] || || || || RSITE AHOP COMB FHOP MODEL|| rsite [ahop] comb fhop model|| || SWVERREPL SWVERDLD SWVERACT || [swverrepl] [swverdld] [swveract] || || CONFMD CONFACT TRACO ABISALLOC || confmd confact traco [abisalloc] || || DHRAABISTHR DFRMAABISTHR DAMRCR DAMRREDABISTHR || [ahraabisthr][dfrmaabisthr][damrcr][damrredabisthr] || /| RSITE rsite

AHOP COMB [ahop] comb

FHOP fhop

STS

Counters per BSC

-

Counters per Cell

3


1536 (3*512)

New or Modified Counters This IP introduces the following new cell counters: •

TCHF8KABIS, included in the existing DID CELLFLXABCNT.


No.

esteeds Approved

Checked


6.2.5.2

108 (125)


Rev

2010-12-22

Pa1

Reference

•

AMRABHOSUCFRHR, included in the existing DID CLRATECHGCNT.

•

NAMRABHOSUCFRHR, included in the existing DID CLRATECHGCNT.

Affected Counters The existing counters HOSUCFRHRAMR and HOSUCFRHRNAMR will in BSC R12 also count the number of successful intra cell handovers initiated by the DYMA-Abis optional feature.

6.2.6

HW No impact.

6.3

238, Statistics Enhancements R12 Package: STATENH_2

6.3.1

Description The Statistics Enhancements R12 are described in two different IP’s, one for CS and the other one for PS.

The IP for the CS-part is divided into six technical parts: •

Counter for number of Immediate Assignment Discards

•

Hard time congestion counters for half rate

•

New SDCCH time congestion counters

•

New dropped call counters when the connection is established and change collection of measurement statistic

•

New SDCCH establishment failure counters

•

New Cause Codes for dropped calls

The IP for the PS-part is divided into four technical parts: •

Existing QoS counters and R-PMO monitors modified to cope with users that have parallel active PFCs

•

New throughput counters that are based on MS GPRS/EGPRS capability

•

Measure GPRS IP buffer discards in real time


No.

esteeds Approved

Checked


• 6.3.2

109 (125)


Rev

2010-12-22

Pa1

Reference

MS 3GPP R97/R99 or R4 capability as a parameter in the R-PMO IP latency monitors AXE parameter No impact.

6.3.3


6.3.4

Command No impact.

6.3.5

STS

6.3.5.1

Influence on STS for the CS-part

Counters per BSC

-

Counters per Cell

11


11

New or Modified Counters •

DISCIMMASS – Number of discarded Immediate Assignments (for CS and PS) in the BTS

•

THTHARDCONGS - Counts the time when all radio resources (TCH/HR) are occupied (hard congestion) and an allocation attempt is made in the underlaid subcell.

•

THTHARDCONSUB - Counts the time when all radio resources (TCH/HR)are occupied (hard congestion) and an allocation attempt is made in the overlaid subcell.

•

CSCSTCONG – Signalling Connection setup time congestion for procedures requiring a TCH. The counter is incremented when it is not possible to setup an SDCCH or TCH signalling.

•

CSCSOPTCONG - Signalling Connection setup time congestion for other procedures that can be completed on a SDCCH.

•

NREJEMC – Number of mobile originating emergency calls rejected by the Processor Load Control in BSC/TRC function or MSC Overload


No.

esteeds Approved

Checked


6.3.5.2

110 (125)


Rev

2010-12-22

Pa1

Reference

•

NREJPRIO – Number of normal mobile originating connections rejected by the Processor Load Control in BSC/TRC function or MSC Overload

•

NREJNPRIO - Number of location updates rejected by the Processor Load Control in BSC/TRC function or MSC Overload

•

NREJIEX - Number of mobile terminating calls rejected by the Processor Load Control in BSC/TRC function or MSC Overload

•

TFNCEDROP - Dropped connections that occur in underlaid subcell when a subscriber to subscriber connection is established. This is between the DTAP messages Connect Acknowledge and Release or Disconnect.

•

TFNCEDROPSUB - Dropped connections that occur in overlaid subcell when a subscriber to subscriber connection is established. This is between the DTAP messages Connect Acknowledge and Release or Disconnect.

•

THNCEDROP - Dropped connections that occur in underlaid subcell when a subscriber to subscriber connection is established. This is between the DTAP messages Connect Acknowledge and Release or Disconnect.

•

THNCEDROPSUB - Dropped connections that occur in overlaid subcell when a subscriber to subscriber connection is established. This is between the DTAP messages Connect Acknowledge and Release or Disconnect.

•

CESTCHACTIV - SDDCH establishment failure that occurs until Channel Activation

•

CESTIMMASS - SDCCH establishment failure due to timeout after sending Immediate Assignment

•

RXQUAL and SQI counters will be incremented in another way than in the design base. The new way to increment the counters will give much better statistic. These counters will only be incremented when Banswer is detected in the BSC.

Influence on STS for the PS-part

Counters per BSC Counters per Cell

8 * 512


8


111 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

New or Modified Counters •

The R11 counters in the object type CELLQOSG, CELLQOSEG and CLDTMQOS shall be Modified so that for periods where one user has an active PFC on top of a PFC with lower priority, the PFC with lower priority do not contribute to the accumulated LLC data volume and the PFC activity time. (See 5.1.1.2)

•

New Qos throughput counters based on MS capability: A total of 8 new cell level proposed counters DLMSEGTHR, ULMSEGTHR, DLMSGTHR, ULMSGTHR, DLMSGDATA, ULMSGDATA, DLMSEGDATA and ULMSEGDATA shall be implemented in RGMACR (m_qos).

6.3.6

HW No impact.

6.4

43, R12 Impact on Data Transcript Package: AQM_1, AQM_2

6.4.1

Description Link to IP 1/159 41-404/FCP 103 4829 The AQM feature is a queue management feature for the radio link in downlink. For applications using TCP as transmission (e.g. FTP, web browsing, email), it is important with a rapid feedback of the radio link data rate to the TCP protocol in the server. Feedback of the radio link data rate is reported to TCP sender in the server by discarding IP-packets. In this way the TCP sender will faster adjust its send rate according to the radio link capacity and TCP slow-starts are avoided. The queue management feature starts to discard data in the buffers in the BSC at certain thresholds of buffer fullness. Data is discarded starting from front of the buffers. The feature also attempts to identify complete IP-packets, such that one complete IP-packet is discarded and not parts of one or two IPpackets. The thresholds of when to start discarding data is set to lower than the actual buffer size to get a smooth slow down in the data rate from the server.

6.4.2

AXE parameter The Optional Feature Parameter GPRSAQM is owned by RGRLCU. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=GPRSAQM, VALUE=1;


No.

esteeds Approved

Checked


6.4.3

112 (125)


Rev

2010-12-22

Pa1

Reference

Exchange Property There are five new BSC exchange properties for this feature, which can be set by operator command: • • • • •

AQMSUPPORT AQMMINBUFF AQMRTTCONST AQMMINIPSIZE AQMMAXIPSIZE

The new exchange properties are checked and set by function block ROEPC. They are owned by RGRLCU. The operator shall be able to switch on/off the AQM feature for data of R97 QoS per BSC, for data of R99 QoS per BSC and AQM support for MSs of all releases. The AQMSUPPORT exchange property could be defined like this: 0 = AQM deactivated 1 = AQM supported 2 = AQM support only for R97 QoS 3 = AQM support only for R99 QoS Default value shall be 0, AQM deactivated. The AQMSUPPORT shall only be possible to set if the optional feature GPRSAQM is activated. Note: If QoS is not supported for any MS release and AQM wants to be active, the AQMSUPPORT exchange property shall be set 1. The operator shall be able to set the value of AQMMINBUFF per BSC. The AQMMINBUFF exchange property gives the value of MinTmin which ensures that at least a few IP-packets are buffered at very low leak rate. The default value shall be 4 Kbytes and the value range shall be 1 to 200 Kbytes. The end to end roundtrip time can be divided in to one constant part and one varying part. The end to end roundtrip time is then used for calculation of the estimated pipe capacity. The RTTconst is the constant part of the roundtrip time. The constant part includes delays in server, core network, BSC, MS and laptop as well as transmission delays on the interface such as Gn, Gb and Abis. The operator shall be able to set the value of AQMRTTCONST per BSC. The default value is 600ms and the value range shall be 100 to 4000 ms in steps of 10ms. It shall also be possible for the operator to set the upper limit, AQMMAXIPSIZE, and lower limit, AQMMINIPSIZE, per BSC. The limits represent the total size of a number of LLC PDU’s constituting the largest and the smallest IP-Packet sizes respectively. The default values shall be AQMMAXIPSIZE = 1700 bytes and AQMMINIPSIZE = 300 bytes and the value ranges 100 to 2000 bytes. It shall be implemented a check in RGRLCU that controls that the AQMMAXIPSIZE is set higher than the AQMMINIPSIZE.


113 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

RAEPC:PROP=AQMSUPPORT-1; RAEPC:PROP=AQMMINBUFF-4; RAEPC:PROP=AQMRTTCONST-600; RAEPC:PROP=AQMMINIPSIZE-300; RAEPC:PROP=AQMMAXIPSIZE-1700; 6.4.4

Command No impact.

6.4.5

STS There are two new counters in Object Type BSCGPRS: AQMDELIVDATA: 32 bits, peg counter, Total amount of data delivered by AQM in Kbit. This is generated per BSC. AQMRECDATA: 32 bits, peg counter, Total amount of data received by AQM in Kbit. This is generated per BSC.

6.4.6

HW No impact.

6.5

390, R12 Impact on Data Transcript Package: PCUCAP_3 See description in Shipment 3.

6.6

368, R12 Impact on Data Transcript Package: RPMO_3 See description in Shipment 2.

6.7


6.7.1

Description No IP.


114 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

6.7.2

AXE parameter

6.7.3

Exchange Property

6.7.4

Command

6.7.5

STS

6.8

40, GPRS/EGPRS Performance Booster

Reference

Package: MSCLASS_ULDL_2 See description in Shipment 3.

6.9

438, Adaptive AMR Thresholds Package: AAMRT_1

6.9.1

Description Link to IP 2/159 41-420/FCP 103 4829 This feature is divided into two ambition levels. Ambition level 1: This feature will give an operator a possibility to prolong the lifetime for an AMR connection, when a failure in decoding the SACCH messages occurs, by introducing four new specific AMR radio link timeout. In DB (R11) the existing parameters RLINKT and RLINKUP are used for both non AMR and AMR connections to decide when to disconnect a call due to a failure in decoding the SACCH messages. In order to prolong the lifetime for an AMR connection, when a failure in decoding the SACCH messages occurs, four new AMR specific radio link timeout parameters are introduced for AMR/FR and AMR/HR: RLINKTAFR - AMR/FR on DL RLINKTAHR - AMR/HR on DL RLINKUPAFR - AMR/FR on UL RLINKUPAHR - AMR/HR on UL Ambition level 2: In order to improve the performance of AMR, the adaptive codec mode change AMR thresholds for each EMR capable mobile will be implemented.


115 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

In order to improve the performance of AMR, adaptive AMR thresholds for EMR capable mobiles shall be implemented. The thresholds will be individually adjusted for each MS that, according to adaptation algorithm in the BSC (based on the number of received blocks – NBR_RCVD_BLOCKS and FER value), uses an AMR codec mode with too high codec rate. 6.9.2

AXE parameter Ambition level 2, Adaptive AMR thresholds shall be implemented as an optional feature. It will be possible to turn the functionality on/off per BSC. New Optional feature parameter: •

ADAMRTHR

Values: 0 Unavailable 1 Available default value: 0 Owner: RQUPD DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=ADAMRTHR, VALUE=1; The ‘EMR’ feature must be supported for the implementation of the functionality in ambition level 2.

6.9.3

Exchange Property Ambition level 2, Adaptive AMR thresholds New BSC Exchange Property: •

ADAPTIVEAMRTHR

Values: 0 OFF 1 ON default: 0 Owner: RQUPD RAEPC:PROP=ADAPTIVEAMRTHR-1;


116 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

6.9.4

Command

6.9.4.1

Ambition level 1, Handling of RLINKTAFR and RLINKTAHR An existing parameter RLINKT is set (as before) by command RLSSC and sent out to all mobiles on the BCCH in SI3 and also to a specific MS on the SACCH in SI6. Two new parameters, RLINKTAFR - for AMR FR and RLINKTAHR - for AMR HR, will be introduced in command RLSSC. When SI6 is to be sent out, the chosen speech version will be checked and if it indicates AMR, one of the new parameters will be sent out on SI6 instead of RLINKT. At change of channel or channel mode change, the radio link timeout value has to be checked and if needed, the new value shall be sent on the SACCH. The OSS shall support the new parameters. Value range and default value for two new parameters are the same as for RLINKT. Command RLSSC and PrintOut ‘Cell System Information SACCH and BCCH Data’ will be changed to handle the new parameters RLINKTAFR and RLINKTAHR.

Command syntax: RLSSC:CELL=cell{[,ACCMIN=accmin][,CCHPWR=cchpwr][,CRH=crh] [,DTXU=dtxu][,NCCPERM=nccperm...] [,RLINKT=rlinkt][,NECI=neci][,MBCR=mbcr] [,RLINKTAFR=rlinktafr] [,RLINKTAHR=rlinktahr]}

Parameters:

RLINKT=rlinkt Radio link time-out on DL for non AMR This parameter defines the time before an MS disconnects a call due to failure in decoding Slow Associated Control Channel (SACCH) messages for non AMR. The parameter is given as number of SACCH periods (480ms). Default value 16 Numeral 8 - 64 in steps of 4 RLINKTAFR=rlinktafr Radio link time-out on DL for AMR FR This parameter defines the time before an MS disconnects a call due to failure in decoding Slow Associated Control Channel (SACCH) messages for AMR FR. The parameter is given as number of SACCH periods (480ms). Default value 16 Numeral 8 - 64 in steps of 4 RLINKTAHR=rlinktahr Radio link time-out on DL for AMR HR This parameter defines the time before an MS disconnects a call due to failure in decoding Slow Associated Control Channel (SACCH) messages for AMR HR. The parameter is given as number of SACCH periods (480ms). Default value 16 Numeral 8 - 64 in steps of 4


No.

esteeds Approved

Checked


6.9.4.2

117 (125)


Rev

2010-12-22

Pa1

Reference

Ambition level 1, Handling of RLINKUPAFR and RLINKUPAHR An existing parameter RLINKUP is set (as before) by command RLLDC and is used in the RP-unit RQRCQSR. Two new parameters, RLINKUPAFR - for AMR FR and RLINKUPAHR for AMR HR, will be introduced in command RLLDC. These parameters will be distributed to the function ‘Supervision of Radio Connections’ (RQRCQSR unit), in the same way as parameter RLINKUP. RQRCQSR unit will check the channel rate and channel speech version to decide which parameter to use. When CHANNEL MODE CHANGE occurs, the new channel mode data is received in ‘Update of RCQS Data’ function and the new channel mode parameters are stored in RQRCQSR. Value range and default value for two new parameters RLINKUPAFR and RLINKUPAHR are the same as for RLINKUP. Command RLLDC and PrintOut ‘Cell Locating Disconnect Data’ will be updated to handle the new parameters RLINKUPAFR and RLINKUPAHR. Command syntax: RLLDC:CELL=cell{[,MAXTA=maxta][,RLINKUP=rlinkup] [,RLINKUPAFR=rlinkupafr] [,RLINKUPAHR=rlinkupahr]}

Parameters: RLINKUP=rlinkup Radio link timeout on UL for non AMR The maximum value of the radio link counter for non AMR. Default value 16 Numeral 1 - 63 SACCH periods RLINKUPAFR=rlinkupafr Radio link timeout on UL for AMR FR The maximum value of the radio link counter for AMR FR. Default value 16 Numeral 1 – 63 SACCH periods RLINKUPAHR=rlinkupahr Radio link time-out on UL for AMR HR The maximum value of the radio link counter for AMR HR. Default value 16 Numeral 1 - 63 SACCH periods

Printout format:

6.9.4.3

Ambition level 2, Handling of Adaptive AMR thresholds


118 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

The AMR thresholds are set in command RLADC in the BSC and sent out to the BTS and MSs. Depending on the carrier-to-interference-plus noise ratio (SINR) and the AMR thresholds the MS request the BTS to use a certain AMR codec mode (DB functionality). 6.9.5

STS No impact.

6.9.6

HW No impact.

7

Shipment 7

7.1

239, R12 Impact on Data Transcript Package: IABIS_3 See description in Shipment 6.

7.2

396, R12 Impact on Data Transcript

7.2.1

Description Link to IP 1/159 41-421/FCP 103 4829 SQS Enhancements shall be implemented as an enhancement to the existing SQS feature. The first ambition level, the introduction of the new air interface message, EMR (Enhanced Measurement Report), makes it possible to improve the information regarding transmission quality for specific MS reported to the BSS. The introduction of EMR is a prerequisite for SQS Enhancements in BSS R12. With the SQSE feature, the SQI DL value is calculated in the BTS, and forwarded to the BSC. By having SQI statistics for the downlink in addition to the existing UL SQI statistics, it will be possible to compare the UL with the DL. The possibility to gather and extract statistics regarding FER is a very strong market requirement from the North American operators AWS, Cingular and Tmobile.


119 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Today, RxQual is not considered very detailed and accurate as a measure of speech quality (especially in tight frequency reuse networks), due to the relatively low correlation between reported RxQual values and user perceived speech quality. FER is seen as a better measure as it is insensitive to changed radio conditions (frequency hopping or not, fast or slow moving mobiles, etc). The BTS sends in the EMR feature, information needed to calculate the FER value for both UL and DL.

The second ambition level provides R-PMO with SQI DL, FER UL & DL and FER drop causes.

7.2.2

AXE parameter

7.2.3

Exchange Property

7.2.3.1

FER UL & DL This function shall handle 10 new exchange properties:

Exchange Property HIGHFERULHR

Codec type/direction HR/UL

Value Range 0-96

4 FER units

RQUPD

HIGHFERULFR

FR/UL

0-96

4 FER units

RQUPD

HIGHFERULEFR

EFR/UL

0-96

4 FER units

RQUPD

HIGHFERULAHR

AMR HR/UL

0-96

4 FER units

RQUPD

HIGHFERULAFR

AMR FR/UL

0-96

4 FER units

RQUPD

HIGHFERDLHR

HR/DL

0-96

4 FER units

RQUPD

HIGHFERDLFR

FR/DL

0-96

4 FER units

RQUPD

HIGHFERDLEFR

EFR/DL

0-96

4 FER units

RQUPD

HIGHFERDLAHR

AMR HR/DL

0-96

4 FER units

RQUPD

HIGHFERDLAFR

AMR FR/DL

0-96

4 FER units

RQUPD

Default Value

Owned by

All these new exchange properties are thresholds values in FER units. Filtered FER measurements are compared to these exchange properties when evaluating urgency conditions. It shall be possible to modify the new Exchanges Properties ONLY when the optional feature parameter SQSSUPPORT is available. This means that RQUPD shall make this check.


No.

esteeds Approved

Checked


7.2.4

120 (125)


Rev

2010-12-22

Pa1

Reference

Command RLSQC Title: Radio Control Cell, Speech Quality Supervision, Change Change: New command. RLSQP Title: Radio Control Cell, Speech Quality Supervision, Print Change: New command. Title: RAMDC, Radio Control Administration, Measurement Result Recording Definition, Change. Change: Add new values for existing parameters MEASLIM and MEASTYPE. Title: RLLFC, Radio Control Cell Locating Filter Data, Change. Change: Add new parameter FERLEN.

7.2.4.1

FER UL & DL A new parameter FERLEN is needed in order to know how many FER values shall be stored to calculate a filtered FER value, to be used when a call is dropped. This parameter shall be added to the existing command RLLFC. RQLAA shall be added as user of the feature parameter SQSSUPPORT. Changed command RLLFC Radio Control Cell Locating Filter Data, Change Command receiving block: RQLAA Syntax: Typed in bold describes what shall be added


121 (125)

No.

esteeds Approved


Checked


Date

Rev

2010-12-22

Pa1

Reference

/ | RLLFC:CELL=cell + [, SSEVALSD=ssvalsd] [,QEVALSD=qevalsd] | \ [, SSEVALSI=ssevalsi] [, QEVALSI=qevalsd] [, SSLENSD=sslensd] [, QLENSD=qlensd] [, SSLENSI=sslensi] [QLENSI=qlensi] [, SSRAMPSD=ssrampsd] [, SSRAMPSI=ssrampsi] \ | [, FERLEN=ferlen] |+; | / Parameters Parameter name FERLEN

7.2.4.2

Description Filter length FER, speech

Default value

Value range

3 FER values

1-10

FER UL & DL In order to manipulate the 4 thresholds described in function SQS Data Collection (Error: Reference source not found), two new commands and one new POD are introduced. RQLOA shall be added as user of feature parameter SQSSUPPORT. Both commands shall be forlopp adapted. New command RLSQC Radio Control Cell, BSC Speech Quality Supervision Data, Change Command receiving block: RQLOA Syntax:


122 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

/ | RLSQC: + [, FERTHR1=ferthr1] [, FERTHR2=ferthr2] [, FERTHR3=ferthr3] | \ \ | [, FERTHR4=ferthr4] +; | / Parameters:

Parameter name

Description

Default value

Value range

FERTHR1

Threshold that separates bin1 and bin2

1 FER units

0-96

FERTHR2


2 FER units

0-96

FERTHR3


3 FER units

0-96

FERTHR4


4 FER units

0-96

Purpose: The RLSQC command defines the four thresholds needed to define the 5 user definable intervals in the range from and including 0 to 96, on BSC level. New command RLSQP Radio Control Cell, BSC Speech Quality Supervision Data, Print Command receiving block: RQLOA Syntax: RLSQP; Purpose: Print out the FER thresholds used to define the 5 user definable intervals in the range from and including 0 to 96, on BSC level. Parameters: None. Implementation:


123 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

RLSQP is only supported if the optional feature SQSSUPPORT is activated. If the feature is unavailable, fault code 164, shall be printed: “FUNCTIONALITY NOT SUPPORTED BY THIS EXCHANGE”. RQLOA shall fetch the thresholds from RQCD. New POD for command RLSQP Printout: BSC SPEECH QUALITY SUPERVISION DATA FERTHR1 ferthr1

FERTHR2 ferthr2

FERTHR3 ferthr3

FERTHR4 ferthr4

END 7.2.5

STS

7.2.6

HW

7.3

238, Statistics Enhancements R12 Package: STATENH_1 See description in Shipment 6.

7.3.1

39, Incremental Redundancy on the UL (EGPRS) Package: IRU_1

7.3.2

Description Link to IP 1/159 41-412/FCP 103 4829 EGPRS provides two different modes to adapt the robustness of the uplink to the current propagation loss. The two modes are Link Adaptation (LA), already implemented, and IR. IR increases the probability of successful decoding of a RLC data block by combining several transmissions of the same block. The receiver stores soft information from the unsuccessful decoded RLC data block and combines this information with the retransmitted block. IR shall work together with LA in the uplink in the same way as it is done for the downlink. The benefit of introducing the IR on UL is increased system capacity on uplink. This can be achieved by that more users can be served since it will take each user a shorter time to transmit a given amount of data in uplink.


124 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

Incremental Redundancy on UL (IRU) consists of two ambition levels. The first ambition level introduces IRU support in the BSC and ambition level 2 introduces the BLER algorithm on UL. All sections not marked with “ambition level 2” are considered to be a part of ambition level 1.

7.3.3

AXE parameter A new wide BSC optional feature parameter shall be introduced to switch on support for Incremental Redundancy on UL. The proposed name for the optional feature is: EGPRSIRU The EGPRSIRU shall be a Commercial Market Parameter and shall have the following possible values: 0 = FEATURE UNAVAILABLE 1= FEATURE AVAILABLE The default value shall be 0. The CLASS of parameter shall be ‘FEATURE’ and the distribution shall be ‘IMMEDIATE’. The parameter shall be implemented in the CP block RGRLCU. DBTSC:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=EGPRSIRU, VALUE=1;

7.3.4

Exchange Property There shall be two new BCS exchange properties for the Incremental Redundancy on UL feature, which can be set by the RAEPC operator command if the optional feature EGPRSIRU is activated: EGPRSIRUL LQCMODEUL The EGPRSIRUL shall be defined as : 0 = IR Deactivated 1 = IR activated The default vale shall be set to 1. The LQCMODEUL shall be defined as: 0 = LA mode 1 = LA/IR mode


125 (125)

No.

esteeds Approved

Checked



Rev

2010-12-22

Pa1

Reference

2 = LA/IR BLER mode (Ambition level 2) The default value shall be set to 0. In order to create logical naming and usage of the LQC exchange properties UL and DL, the DL LQC exchange property called LQCIR shall change name to LQCMODEDL. The default values and the values used by the property shall be kept as in design base. 7.3.5

Command No impact.

7.3.6

STS

7.3.6.1

New or Modified Counters There are no new STS counters introduced for this feature.

7.3.6.2

Affected Counters There will probably be an increased UL throughput when introducing IRU. The affected counters are: ULTHP1EGTHR, ULTHP2EGTHR, ULTHP3EGTHR and ULBGEGTHR. All the above counters are found in object type CELLQOSEG (EGPRS Quality of Service counters per cell).

7.3.7

HW No impact.

7.4

432, R12 Impact on Data Transcript Package: EITQP_2 See description in Shipment 5.

7.5

Feature name

7.5.1

Description

7.5.2

AXE parameter

7.5.3

Exchange Property

7.5.4

Command

7.5.5

STS

7.5.6

HW

BSC R12 DT Impact

Recommend Documents