01_RN33211EN40GLA1_RU40 Release Hands-On Workshop

1 © Nokia Siemens Networks RN33211EN40GLA1 For public use – IPR applies

RN3321-40A RU40 Release Hands-on Workshop (Practical)


Nokia Siemens Networks Academy

Legal notice Intellectual Property Rights All copyrights and intellectual property rights for Nokia Siemens Networks training documentation, product documentation and slide presentation material, all of which are forthwith known as Nokia Siemens Networks training material, are the exclusive property of Nokia Siemens Networks. Nokia Siemens Networks owns the rights to copying, modification, translation, adaptation or derivatives including any improvements or developments. Nokia Siemens Networks has the sole right to copy, distribute, amend, modify, develop, license, sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individuals can use the Nokia Siemens Networks training material for their own personal self-development only, those same individuals cannot subsequently pass on that same Intellectual Property to others without the prior written agreement of Nokia Siemens Networks. The Nokia Siemens Networks training material cannot be used outside of an agreed Nokia Siemens Networks training session for development of groups without the prior written agreement of Nokia Siemens Networks.


Objectives

After completing this training the participant shall be able to:

• - Describe, Activate and test selected RU40 features


RU40 Voice and Data Features • RAN2135 Layering in RRC connection release *** • RAN2124 HSPA 128 Users per cell •RAN1645 - HSUPA 16QAM • RAN971 HSUPA DL Physical channel power control *** • RAN1913 High speed Cell_FACH (UL) *** • RAN2451 Fast Dormany profiling *** • RAN1910 Flexible RLC in UL • RAN1908 UE_DRX in Cell_FACH *** • RAN2302 Dynamic HSUPA BLEr *** • RAN2494 Fast Cell_PCH Switching *** • RAN2509 Application Aware RAN *** • RAN2179 Dual Band HSDPA 42Mbps • RAN 1907 - Dual Cell HSDPA with MiMo 84Mbps • RAN2435 - SRVCC from LTE and CSFB with HO • RAN2717 - – Smart LTE Layering


RU40 O&M, Performance Management and Servicebility Features

• RAN1877 End-user experienced DL Throughput • RAN2526 - 1 Hour RNC Release Software Upgrade • RAN2539 - OMS RNC Connectivity Increase • RAN2446 - Emergency Symptom Data Collection for IPA-RNC

RAN1805 – Event Triggered Symptom Data Collection for IPA-RNC


RU40 Transmission and Transport Feature

• RAN2296 Transport sub-Module "FTIF" Eth+E1/Ta/JT1 for FSM3 outdoor


RU40 BTS and Site Solution Features

• RAN2117 RNC2600 Co-Sitting with Multicontroller RNC

• RAN2240 mcRNC Flexible Dimensioning up to 50Gbps HW Release 2

• RAN2262 Flexi Multiradio System Modules, FSMF and FBBA extension module

• RAN2317 240W Multiradio remote RF

• RAN2429 Flexi 3-sector RF Module 2100 80W FXDB (RU30 EP2 on top)


• RAN2157 Flexi Lite BTS 2100 ***

• RRH FHDB 60W+60W

• RAN2489 - Carrier Bandwidth 3.8MHz

• RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices

• RAN2591 – Selective BTS Resource Re-Balancing in mcRNC


RU40 Voice and Data Features


RAN2135 Layering in RRC Connection Release


RAN2135 - Layering in RRC Connection Release

• Brief description

• Allows the operator to define the preferred idle mode layer in RRC connection release, in order to push the UE to this layer.

• RNC triggers layering in order to direct a UE to other WCDMA layer. This is done during RRC Connection Release

• Layering is supported from common and dedicated channels (trasitions from Cell_DCH, Cell_FACH, Cell/URA_PCH)

• Layering decision takes into account UE band capability

• Used service does not affect the layering decision


RAN2135 - Layering in RRC Connection Release, cont. Summary: Feature RAN2135: Layering in RRC Connection Release allows the operator to define the preferred idle mode layer in RRC connection release, in order to push the UE to this layer. Benefits: End-user benefits The end user benefits from an enhanced application experience because of the distributed RRC connection setup load. Operator benefits Without this feature the UE easily camps on a layer with better coverage, such as lower frequency band, for example, 900 MHz. This could cause an excessive number of RRC connection setup requests on the layer. The feature RAN2135: Layering in RRC Connection Release can push the UE in idle mode to a preferred layer, for example, 2100 MHz, so that the RRC connection setup request that happens after is performed on the preferred layer.)

•The operator is able to control the UEs’ idle mode camping routines – idle mode UEs are distributed across different WCDMA carriers.

•If data or voice connections are needed, requests are sent on different layers - this helps to avoid high load states in particular cells

•End-user experience can also be improved due to better resource utilization (PLMN level) •Only supported inside WCDMA

Impacts on system performance and capacity

RRC connection setup load can be distributed to desired frequencies.



• Benefits • UEs easily camp on due to better coverage

• The operator is able to control the UEs’ idle mode camping routines

• Idle mode UEs are distributed across different WCDMA carriers.

• For data or voice connections, requests are sent on different layers - this helps to avoid high load states in particular cells

• End-user experience can also be improved

• Only supported inside WCDMA

*If the UE is in state CELL_PCH or URA_PCH, the RNC must first page it to state CELL_FACH before releasing the RRC connection.



UE goes to Idle Mode and camps on this WCDMA layer

Target UARFCN is given to

the UE within this RRC message

If layer change is triggered, the new frequency info is included to “RRC Connection release message”

• Rel6 and later UEs can read this frequency information

• It is expected that UE goes to one of the frequency given to it in Redirection info IE after receiving RRC Connection Release and stays there in idle mode if the coverage is good enough.

• Define other cell reselection parameters so that ping-pong is avoided.


RAN2135 - Layering in RRC Connection Release, cont. Functional description The RAN2135: Layering in RRC Connection Release feature introduces the connected-mode mechanism that pushes the UE to perform idle-mode camping on a particular carrier. Idle-mode camping is controlled with the cell reselection parameters. During the RRC connection release procedure, the RNC triggers the RAN2135: Layering in RRC Connection Release feature if the UE needs to be directed to another layer after the RRC connection is released for this UE. The preferred layer (frequency) is defined by the operator with the cell-level parameter in order to push the UE to this preferred idle mode layer. The preferred layer could be another band, or another carrier within the same band. The RNC sends the information on the preferred frequency to the UE in the Redirection info Information Element (IE) included in the RRC CONNECTION RELEASE message. This IE includes the UARFCN downlink (Nd) IE that points out the frequency with which the UE attempts to camp. After receiving this message, the UE goes to the frequency given to it and stays on this frequency in idle mode if the coverage is good enough. The possible RRC connection setup request that happens after is performed on the same layer. This process is illustrated in Figure 17 Layering in RRC connection release. If the coverage is not good enough, the UE changes the layer. Before sending the RRC CONNECTION RELEASE message, the RRC entity in the RNC checks if the conditions for moving the UE to another layer are satisfied. The UE can be on the dedicated or common channel. Both channels are supported by the feature. The UE is directed to another FDD UMTS frequency layer if the following conditions are met:



• There are no means of redirecting UEs to a specific frequency layer during RRC connection releasing

• UEs go to Idle Mode, camps on a frequency layer with better coverage which has served terminated voice or data call and follow standard cell reselection procedures.

No UARFCN Target Info is given to UE when releasing RRC connection

RAN2135 Not activated



• It is possible to distribute Idle Mode UEs across different frequency layers using Frequency Info IE included in RRC Connection Release message

• All frequency layers are loaded evenly with Idle Mode UEs - this avoids excessive number of RRC Connection Setup requests on particular layer

UE is ordered to camp on a specific frequency layer (UARFCN)

RAN2135 Activated



New Parameters: Parameter Object Range Default Description

LayeringRRCRelEnabled WCEL Disabled (0), Enabled (1) Disabled (0) Defines whether the layering in RRC Connection Release is enabled

in the cell.

LayeringRRCConnRelTargFreq WCEL Structure parameter

This parameter structure defines the possible target frequencies for layering in RRC connection release. Up to 8 different frequencies can be defined.

TargetFrequency WCEL 0...16383, step 1 0

This parameter defines the target frequency for layering in RRC connection release. The frequencies are given in UTRA Absolute Radio Frequency Channel Number (UARFCN) format, which defines the downlink channel number and the downlink carrier frequency. Default value 0 means that UE is not directed to other frequency in RRC Connection Release due to Layering in RRC connection Release.

New Counter: • License:

• Long-term ON/OFF

Counter ID Name

M1006C269 RRC Connection Release WCDMA Redirection




RAN2135 - Layering in RRC Connection Release, cont. A restart of the RNC and the BTS is not required after the activation of this feature. This procedure does not cause downtime and the feature can be activated at any time of the day. Make sure you have access to the following applications:

• OMS Element Manager • Application Launcher • Man-machine interface (MMI)

The feature code for this feature is 3898. To set the feature state to ON, use the following command: for IPA-RNC: ZW7M:FEA=3898:ON; for mcRNC: set license feature-mgmt id 0000003898 feature-admin-state on In Flexi Direct RNC there is no need to configure the license


RAN2124 HSPA 128 Users per cell


RAN2124 - HSPA 128 Users per cell

• Maximum number of HSPA end users in the CELL_DCH* state is increased up to 128

• Instant access to data services for more HSPA users per cell is provided

• Quality of experience (QoE) for more HSPA end users is increased

• Number of users in other states remain unchanged

• Non-serving HSUPA users per cell limit is removed and just serving HSUPA users are taken into account, however the BTS is limiting this amount RRC states and state transitions

UTRAN Connected Mode

Idle mode

CELL_PCH URA_PCH

CELL_DCH CELL_FACH

With this feature 128 simultaneous HSPA serving users (HSDPA and HSUPA) per cell are supported.


RAN2124 - HSPA 128 Users per cell, cont.

Max no. of active users in HS CELL_FACH per cell – 12

Max no. of active users in HS CELL_FACH per BTS – 192

Max no. of inactive users in HS CELL_FACH per cell – 600

Max no. of users in HS CELL_FACH per cell – 1024

inactive

CELL_DCH (transmission of bigger messages, dedicated channel resources); CELL_DCH is the only RRC state which allows UE to establish soft and softer handover

connections. Both dedicated channels and HSUPA support soft and softer handover. The use of soft handover helps to improve air-interface performance towards the cell edge If the paging message was for a CS service then the UE will be moved into CELL_DCH. The

UE may also be moved to CELL_DCH for PS services, depending upon the quantity of data to transfer.

CELL_FACH (the UE monitors a forward access channel (FACH));

CELL_PCH (the UE listens to the PCH transport channel);

URA_PCH (the location of the UE is known on the UTRAN registration area (URA) level)

NRT users are wanted to be kept as long as possible in CELL_DCH state even if they have no data to be transferred


RAN2124 - HSPA 128 Users per cell 64 UEs

(19 HSUPA) 64 UEs (19 HSUPA)

64 UEs (19 HSUPA)

The maximum number of HSPA users per cell is 128 (both HSUPA and HSDPA). The limit of E-RGCH/E-HICH codes is removed and depends on the BTS

128 UEs

128 UEs

128 UEs

RA

N 2

124

A

ctiv

ated

R

AN

2124

N

ot a

ctiv

ated

RU10: The maximum number of users per cell is 64 for HSDPA and 19 for HSUPA. The limit of E-RGCH/E-HICH codes is equal to 1

RU20: The maximum number of HSPA users per cell is 72 (both HSUPA and HSDPA). The limit of E-RGCH/E-HICH codes is increased to 4

72 UEs

72 UEs

72 UEs

Serving and non-serving HSUPA users are taken for the limit

Serving HSUPA users only are taken for the limit



Number of HSPA users will in general increased numbers of control channels. RAN1686 has introduced the requirements for the dynamical handling of increased numbers of HS-SCCH and E-RGCH/E-HICH. As well as for flexible allocation of DL code space. RAN2124 feature requires extending of the implemented mechanisms for higher user counts.



UE

DCH BTS of the active set (non-serving BTS)

E-DCH BTS of the active set (non-serving BTS)

E-DCH/ HS-DSCH (serving BTS)

With this feature the UE is taken for the users limit in the cell B only

A

B

C

Without feature HSPA 128 Users per Cell the UE is taken for the limit in the cell A and B



Functional description This feature increases the number of serving HSPA (HSDPA and HSUPA) users per cell in CELL_DCH state to 128. It mainly deals with the BaseBand capacity enhancements brought with the new HW and SW. The BTS provides resources and handles the increased number of users, while the RNC takes care of enhanced admission and overload control. Maximum number of E-HICH/E-RGCH codes is increased accordingly. Note that completely inactive users are released by the RNC even before the limit of users is reached when the noise rise is high for a given period. The RAN1686: HSPA 72 Users per Cell feature has introduced the requirements for the dynamic handling of increased numbers of HS-SCCH and E-RGCH / E-HICH, as well as for flexible allocation of DL code space. This feature requires extending of the implemented mechanisms for higher user counts. For the UL, only serving users are counted and checked, but the number of non-serving E-DCH users is limited, according to the maximum amount of E-HICH/E-RGCH codes. The maximum number of HS-DSCH MAC-d flows is 1024 per one cell.



RAN1913

RAN2124 HSPA 128 Users

per Cell

RAN1201 RAN971

RAN1644

• RAN1686: HSPA 72 Users per Cell • RAN1644 - Continuous Packet Connectivity • RAN1201 - Fractional DPCH

- Note: It is required for the CS Voice over HSPA feature

• RAN971 - HSUPA Downlink Physical Channel Power Control • RAN1308 - HSUPA Interference Cancellation Receiver

- Beneficial for the feature

• RAN1913 - High Speed CELL_FACH - Note: CS Voice over HSPA is not possible in the CELL_FACH state

Recommended features to achieve maximum number of HSPA users

Optional Enhancements

RAN1686

RAN1308



Interdependencies between features This feature requires the following features up and running:

RAN971: HSUPA Downlink Physical Channel Power Control RAN1201: Fractional DPCH (recommended for air interface capacity reasons) RAN1644: Continuous Packet Connectivity (recommended for air interface capacity reasons) RAN1686: HSPA 72 Users per Cell

Optional Enhancements • RAN1308 - HSUPA Interference Cancellation Receiver • RAN1913 - High Speed CELL_FACH This feature impacts interfaces as follows: Uu:

higher number of HSPA UEs/Cell - load and interference issues, higher ranges of UE identifiers like E-RNTI and H-RNTI

This feature impacts system performance and capacity as follows:

Number of HSPA users per cell is increased from 72 to 128.


RAN2124 - HSPA 128 Users per cell • Hardware requirements:

• RAN2382 Flexi BTS Multimode System Module – FSMC, or • RAN1016 Flexi BTS Multimode System Module – FSMD, or • RAN1848 Flexi BTS Multimode System Module – FSME, or • RAN2262 Flexi BTS Multiradio System Module – FSMF, or • RAN2157 Flexi Lite BTS 2100

RAN1016 Flexi BTS

Multimode System Module – FSMD

RAN2124 HSPA 128 Users

per Cell

RAN2262 Flexi BTS

Multiradio System Module – FSMF

RAN1848 Flexi BTS

Multimode System Module – FSME

RAN2382 Flexi BTS

Multimode System Module – FSMC

RAN2157 Flexi Lite BTS

2100



Network Design Impact of HSPA 128 Users per Cell

Carrier capacity usage

Downlink spreading code tree occupation

HSPA 128 Users per Cell

• More capacity is remaining for the DCH transmission

• Better BTS spreading code tree usage



Network design impact: • Air Interface aspects:

- Possible Higher number of HSPA active UEs per cell from 72 to 128

- Significant gains in downlink spreading code tree occupation

- More available E-HICH/E-RGCH codes reservations

• Baseband aspects: - HSPA schedulers admit up to 128 users per cell



Abbreviated name Full name Managed object

HSPA128UsersPerCell HSPA 128 Users Per Cell WCEL ULLoadStateTTT UL loaded state time to trigger RNPS ULLoadStateHSUOffset UL loaded state for HSPA users offset WCEL ULLoadStateHSUBRLimit UL loaded state for HSPA users bit rate limit WCEL

Abbreviated name Full name Managed

object MaxNumberHSDSCHMACdFlows Maximum number of HS-DSCH MAC-d flows WCEL MaxNumberHSDPAUsers Maximum number of HSDPA users WCEL

MaxNumbHSDSCHMACdFS Max number HSDSCH MACd flows per MAChs/ehs scheduler WCEL

MaxNumbHSDPAUsersS Max number HSDPA users per MAChs/ehs scheduler WCEL MaxNumberEDCHCell Maximum number of E-DCHs in the cell WCEL MaxNumberEDCHLCG Maximum number of E-DCHs in the local cell group WBTS NumberEDCHReservedSHOBranchAdditions Number of E-DCHs reserved for SHO branch additions WCEL RsrvdSignaturesOffset Reserved E-RGCH and E-HICH signatures per cell WCEL HSPDSCHMarginSF128 HS-PDSCH code upgrade margin for SF128 codes WCEL HSDPA48UsersEnabled HSDPA 48 users enabled RNFC HSDPA64UsersEnabled HSDPA 64 users enabled WCEL HSPA72UsersPerCell HSPA 72 Users per Cell WCEL HSUPAXUsersEnabled HSUPA x users enabled WBTS InacUsersOverloadFact Inactive users overload preventive factor RNHSPA RncOptions RNC Options RNC

New Parameters:

Modified Parameters:



If this feature is not enabled, the RNC allows only 16, 48, 64 or 72 HSDPA users per cell and only 3, 12, 60 users per BTS or LCG or 72 HSUPA users per cell HSPA128UsersPerCell:

This parameter determines whether the HSPA 128 Users per Cell feature is enabled in the cell or not. If this feature is enabled, a maximum of 128 users with HS-DSCH in downlink and 128 users with E-DCH in uplink can be admitted per cell; Disabled (0), Enabled (1); Default = 0.

ULLoadStateTTT:

This parameter defines time to trigger value to activate and deactivate UL loaded state (UL loaded state for HSPA users) and HSPA load state; Range 0..10 s, step 0.5 s; default= 2 s.

ULLoadStateHSUOffset:

This parameter defines an offset related to the maximum received target power. The sum of this offset and target power is used to trigger the UL loaded state for the purposes of HSPA users checking; Range -3..3 dB, step 0.1 dB; Default = -0.5 dB.

ULLoadStateHSUBRLimit:

This parameter defines user based bit rate limit for NRT services mapped to E-DCH that must be exceeded so that UL loaded state for HSPA users is not triggered. If bit rate per user is under this limit, then UL loaded state for HSPA users is triggered if load of UL is high enough; Range 0..128 kbps, step 1 kbps; Default = 8 kbps


Offset


time

PrxTotal

ULLoadStateTTT start ULLoadState not activated ULLoadState activated ULLoadState released

PrxNoise + PrxMaxTargetBTS

ULLoadStateHSUOffset



• UL load state for HSPA users is triggered by high UL load • When a cell in UL load state for HSPA users, then the following

preventive actions take place: – New users with extended inactivity timer running are not allowed

• The cell is set to UL loaded state if level of PrxTotal is higher than the following sum of parameters for at least time defined by ULLoadStateTTT:

– PrxNoise + PrxMaxTargetBTS + ULLoadStateHSUOffset

• If the condition is not fulfilled for at least time indicated by the

management parameter ULLoadStateTTT then the UL loaded state is canceled

• New management ULLoadStateHSUBRLimit parameter defines user based bit rate limit for NRT services mapped to E-DCH that must be exceeded so that UL loaded state for HSPA users is not triggered


RAN2124 - HSPA 128 Users per cell Before the HSPA 128 Users per Cell feature there were no counters to analyze the activity of over 72 HSPA users per cell, therefore the following new counters are introduced with the HSPA 128 Users per Cell feature:

• M1000C384 - DURA_HSUPA_USERS_73_TO_80 • M1000C385 - DURA_HSUPA_USERS_81_TO_96 • M1000C386 - DURA_HSUPA_USERS_97_TO_112 • M1000C387 - DURA_HSUPA_USERS_113_OR_MORE • M1000C388 - MAX_HSUPA_USERS_IN_SERV_CELL • M1000C389 - SUM_HSUPA_USERS_IN_SERV_CELL • M1000C390 - DURA_HSDPA_USERS_73_TO_80 • M1000C391 - DURA_HSDPA_USERS_81_TO_96 • M1000C392 - DURA_HSUPA_USERS_97_TO_112 • M1000C393 - DURA_HSUPA_USERS_113_OR_MORE • M5000C415 - HSDPA_USERS_ONE_TTI • M5000C416 - HSDPA_USERS_TWO_TTI • M5000C417 - HSDPA_USERS_THREE_TTI • M5000C418 - HSDPA_USERS_FOUR_TTI



M1000C384 - DURA_HSUPA_USERS_73_TO_80: The counter indicates the amount of time that 73 to 80 active HSUPA users are simultaneously allocated during the measurement period. Sampling interval is equal to 1s



M1000C387 - DURA_HSUPA_USERS_113_OR_MORE: The counter indicates the amount of time that 113 or more active HSUPA users are simultaneously allocated during the measurement period. Sampling interval is equal to 1s

M1000C388 - MAX_HSUPA_USERS_IN_SERV_CELL: The maximum number of simultaneous HSUPA users in serving E-DCH cell. The number of HSUPA users is sampled with defined time interval. Sampling interval is equal to 1s

M1000C389 - SUM_HSUPA_USERS_IN_SERV_CELL: The sum of sampled values for measuring the number of simultaneous HSUPA users in serving E-DCH cell. The counter, provides the average number of HSUPA users (E-DCH allocations) in the serving E-DCH cell. Sampling interval is equal to 1s

M1000C390 - DURA_HSDPA_USERS_73_TO_80 The counter indicates the amount of time that 73 to 80 active HSDPA users are simultaneously allocated during the measurement period. Sampling interval is equal to 1s



Example: Number of Active Serving HSUPA Users


RAN2124 - HSPA 128 Users per cell, cont. M1000C391 - DURA_HSDPA_USERS_81_TO_96

The counter indicates the amount of time that 81 to 96 active HSDPA users are simultaneously allocated during the measurement period. Sampling interval is equal to 1s

M1000C392 - DURA_HSDPA_USERS_97_TO_112 The counter indicates the amount of time that 97 to 112 active HSDPA users are simultaneously allocated during the measurement period. Sampling interval is equal to 1s.

M1000C393 - DURA_HSDPA_USERS_113_OR_MORE The counter indicates the amount of time that 113 or more active HSDPA users are simultaneously allocated during the measurement period. Sampling interval is equal to 1s

M5000C415 - HSDPA_USERS_ONE_TTI The number of one per TTI scheduled HSDPA users in WCELL Incremented for every TTI for which there is data in the HSDPA user buffers and the data (MAC-hs PDU) is scheduled to be send to one user

M5000C416 - HSDPA_USERS_TWO_TTI The number of two simultaneously scheduled HSDPA users per TTI in WCELL Incremented for every TTI for which there is data in the HSDPA user buffers and the data (MAC-hs PDU) is scheduled to be send to two users

M5000C417 - HSDPA_USERS_THREE_TTI The number of two simultaneously scheduled HSDPA users per TTI in WCELL Incremented for every TTI for which there is data in the HSDPA user buffers and the data (MAC-hs PDU) is scheduled to be send to three users.

M5000C418 - HSDPA_USERS_FOUR_TTI The number of two simultaneously scheduled HSDPA users per TTI in WCELL Incremented for every TTI for which there is data in the HSDPA user buffers and the data (MAC-hs PDU) is scheduled to be send to four users.



Licensing:

RNC level License Key: “HSPA 128 Users per Cell” Long-term capacity license Number of BTS Controlled on the cell level HSPA 128 Users per Cell use together with RAN1644 CPC is controlled by the License Key: “CPC for 128 Users LK”

• RAN2124 HSPA 128 Users per Cell is ASW feature and it is controlled by the RNC level LK “HSPA 128 Users per Cell” with the following requirements:

License control attribute: Long-term capacity license License capacity info: Number of BTS The use of the feature is controlled on the cell level

• The use of RAN2124 HSPA 128 Users per Cell together with RAN1644 CPC feature is controlled by the “CPC for 128 Users LK”



State of the HSPA 128 Users per Cell license is “On” HSPA128UsersPerCell parameter must be set to “Enabled” HSPA72UsersPerCell parameter must be set to “Enabled” HSDPAenabled and HSUPAEnabled parameters must be set to “Enabled” If the CPC is enabled then the CPC for 128 HSPA Users LK must be “On”

Activation Aspects:

Parameters related with number of supported HSPA users per cell, BTS or LCG should be adjusted

To achieve the maximum number of HSPA users: F-DPCH and CPC are recommended in RNC HSUPA Downlink Physical Channel Power Control in BTS



• The following conditions have to be fulfilled to apply RAN2124 in a cell: – State of the HSPA 128 Users per Cell license is “On” – The HSPA128UsersPerCell activation parameter is set to value “Enabled” – The HSPA 72 Users per Cell feature is enabled in the cell using HSPA72UsersPerCell – HSDPA and HSUPA features are enabled using HSDPAenabled and HSUPAEnabled – If the CPC is enabled then the CPC for 128 HSPA Users LK must be “On”

• To increase the number of supported HSPA users per cell, BTS or LCG the range of related management parameters should be increased if necessary it might include:

WCEL – MaxNumberEDCHCell WBTS – MaxNumberEDCHLCG WCEL – MaxNumberHSDSCHMACdFlows WCEL – MaxNumberHSDPAUsers WCEL – MaxNumbHSDPAUsersS WCEL – MaxNumbHSDSCHMACdFS

• These parameters by default do not provide any restrictions • To achieve maximum number of HSPA users F-DPCH and CPC are recommended in RNC and HSUPA Downlink Physical Channel Power Control in BTS




RAN2124 - HSPA 128 Users per cell, cont. Restart of the RNC and the WBTS is not required after activation of this feature. This procedure requires cell locking. Make sure you have access to the following applications:

OMS Element Manager Application Launcher

To set the feature state to ON, use the following command: for IPA-RNC

ZW7M:FEA=1796:ON; for mcRNC

set license feature-mgmt code 0000001796 feature-admin-state on RAN 2124: HSPA 128 Users per Cell feature needs the following features to be activated before it can be enabled:

HSDPA HSUPA

RAN1686: HSPA 72 Users per cell To achieve the maximum number of HSPA users it is recommended to have the following features activated:

in RNC: RAN1201: Fractional DPCH RAN1644: Continuous Packet Connectivity (to use RAN1644 simultaneously with RAN2124, CPC for 128 HSPA Users license key must be set to ON)

in BTS: RAN971: HSUPA Downlink Physical Channel Power Control



Release Information WCDMA Release RU40 Flexi Direct Flexi Direct Rel5 RNC Release RN7.0 mcRNC Release mcRNC3.0 BTS (Flexi) WBTS8.0 NetAct OSS5.4 CD set 3 HW Requirements RAN2382, or RAN1016, or RAN1848, or RAN2262, or RAN2157 UE Release 3GPP Rel-5 Common O&M Platform Feature No BSW/ASW ASW RAS SW Component RAN License Control Long-term ON/OFF License Control in Network Element RNC LK


RAN1645 HSUPA 16QAM


RAN1645 - HSUPA 16QAM

Enables 11.5Mbps peak UL data rate by sending four bits per symbol instead of two

HSUPA 16QAM = 11Mbps

0110 1111 1001 1001 0101

10 1011

11 01

00 1010 0000 1000

1110

1111

0010

0100 1100 0110

0111 0101 1101

0011 1001 0001

Q Q

I I

QPSK 2 bits/symbol 16 QAM 4 bits/symbol


RAN1645 - HSUPA 16QAM, cont.

• GPP Rel-7 introduces 16QAM modulation for HSUPA in addition to QPSK modulation • 16QAM modulation is supported by HSUPA terminal category 7

• HSUPA peak data rate is increased from 5.8Mbps to 11.5 Mbps • HSUPA 16QAM is an optional feature for UEs • 16QAM capability is signaled to the RNC by the UE in the RRC

connection setup message • Throughput can be limited by radio channel conditions,

interference level, allowed noise rise, and both receiver and transmitter imperfections • QPSK symbols carry two bits of information while 16QAM symbols carry

four bits of information allowing a higher peak rate at the cost of a reduction of the Euclidian distance between adjacent symbols

• A good SNR (signal-to-noise ratio) is required to achieve the same BER (bit error rate)

http://en.wikipedia.org/wiki/Euclidean_distance



• This feature requires the following features: • RAN981: HSUPA 5.8 Mbps • RAN1016: Flexi BTS Multimode System Module - FSMD • RAN1848: Flexi BTS Multimode System Module - FSME • RAN1226: HSPA Peak Rate Upgrade for RNC196 and RNC450 • RAN1470: HSUPA 2ms TTI • RAN1702: Frequency Domain Equalizer • RAN2261: Flexible User Plane Capacity in RNC196 and RNC450

RAN1645 HSUPA 16QAM

RAN981 HSUPA 5.8Mbps

RAN1470 HSUPA 2ms

TTI

RAN1702 Frequency

Domain Equalizer

RAN1016/1848 Multimode SM FSMD/FSME

RAN1226 RNC196/450 HSPA Peak

Rate Upgrade



Counter ID Counter name Measurement

M5000C359 SUM OF ACTIVE 16QAM UL USERS M5000 HSPA in WBTS

M5000C360 SUM OF CORRECTLY RECEIVED MAC-E PDUs WITH 16QAM UL M5000 HSPA in WBTS

M5000C361

SUM OF INCORRECTLY RECEIVED MAC-E PDUs WITH 16QAM UL M5000 HSPA in WBTS

Counters:



E-DCH category 3GPP Release Code configuration for Max. data rate

Highest order

modulation

Max. data rate (Mbps)

10 ms E-DCH TTI 2 ms E-DCH TTI

Category 1

Rel 6

1 x SF4

QPSK

0.7 Not supported

Category 2 2 x SF4 1.4 1.4

Category 3 2 x SF4 1.4 Not supported

Category 4 2 x SF2 2.0 2.9

Category 5 2 x SF2 2.0 Not supported

Category 6 2 x SF2 + 2 x SF4 2.0 5.8

Category 7 Rel 7 2 x SF2 + 2 x SF4 16QAM 2.0 11.5


RAN1645 - HSUPA 16QAM, cont. Summary HSUPA 16QAM enables 11.5 Mbps peak UL data rate by sending four bits per symbol instead of two. Together with RAN1905 DC-HSUPA a peak rate of 23 Mbps can be obtained. Benefits for the Customer 16QAM offers higher UL peak rates and better UL capacity. Functional Description 3GPP Rel-7 introduces 16QAM modulation for HSUPA. HSUPA terminal category 7 supports 16QAM. 16QAM modulates 4 bits per symbol and increases the HSUPA peak data rate to 11.5 Mbps. Category 1-6 maximum is 5.8 Mbps. 16QAM is an optional feature for the UE, and the 16QAM capability is signaled to RNC in the RRC connection setup. The maximum theoretical throughput of cat7 terminal is 11.5 Mbps. Practical throughput achievable with this feature is limited by radio channel, interference, allowed noise rise and both receiver and transmitter imperfections. Interdependencies between Features RAN981: HSUPA 5.8 Mbps and RAN1702: Frequency Domain Equalizer are required for this feature. RAN1910: Flexible RLC in UL is needed for achieving the 11.5 Mbps peak UL data rate. HW Requirements This feature requires RAN1016/RAN1848: Flexi BTS Multimode System Module . For RNC196 and RNC450, RAN2261 Flexible User Plane Capacity in RNC196 and RNC450 is required



E-DPDCH 4

E-DPDCH 3

E-DPDCH 1

E-DPDCH 2

4 symbols + 4 symbols

SF = 2

SF=2

SF=4

SF=4

C ch,2,1 β ed,1

4PAM modulation mapper

C ch,4,1 β ed,3


C ch,256,0 β c

BPSK modulation mapper

β ed,4


C ch,2,1 β ed,2


C ch,256,1 β ec

E-DPCCH BPSK modulation

mapper

Σ

Σ

I

j

I+jQ

Q

S

E c E s E b

4 symbols +

4 symbols

16 symbols

= 16QAM

C ch,4,1

E-DPCCH



Release Information RAS Release - RU40 RNC Release - RN7.0 IPA Platform - A14 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) mcRNC Release - mcRNC3.0 Flexi Direct Release - ADA5.0 BTS Release (Flexi) - WBTS8.0 BTS release (Flexi Lite) - WBTS8.0 BTS Release (Flexi 10) - FSMr3 WBTS8.0 BTS HW Release - Flexi Rel2 Flexi Rel3.0 NetAct - OSS5.4 CD set 3 SGSN - SG7.0 MSC UE Release - 3GPP Rel-7



Activating HSUPA 16QAM: • Licence Feature Code – 1497 • HSUPA needs to be enabled and working • This feature can be activated by selecting the HSUPA16QAMAllowed parameter

from the drop down menu and then selecting Apply


RAN1645 - HSUPA 16QAM, cont.

1. Open the OMS Element Manager. 2. Go to Tree View. Expand the topology tree of the RNC. 3. Configure the following WCEL parameters.

1. Select Edit parameters from the WCEL object. 2. Under the Admission Control tab, set the HSUPA16QAMAllowed

parameter to Enabled. 3. Under the Packet Scheduler tab, set the MaxTotalUplinkSymbolRate parameter to 5760

kbit/s (2*SF2+2*SF4). 4. Save the changes. 1. Click the Validate button. 2. Click the Apply button


RAN971 HSUPA Downlink Physical Channel Power Control


HSUPA Downlink Physical Channel Power Control RAN971 (BSW)

Adjusts HSUPA downlink control channels transmit power : E-AGCH, E-RGCH) and E-HICH according to the required power level at the UE. If F-DPCH is configured, it also adapts the transmit power of the F-DPCHfor each UE.

Tx Power F-DPCH

Tx Power E-HICH

Tx Power E-RGCH

Tx Power E-AGCH

CQI

DL TPC

L1 HSPA ACK & NACK

Power offsets from RNC databuild

DL Power Control

Inner Loop & Outer Loop


HSUPA Downlink Physical Channel Power Control RAN971 (BSW), cont. •This feature dynamically adjusts HSUPA downlink control channels: •E-DCH Absolute Grant Channel (E-AGCH) •E-DCH Relative Grant Channel (E-RGCH) •E-DCH Hybrid ARQ Indicator Channel (E-HICH) transmit powers according to the required power level at the UE •Fractional Dedicated Physical Channel (F-DPCH) •If F-DPCH is configured, it adapts the transmit power for each UE •The E-DCH serving BTS adjusts the downlink control channel transmit powers

•Inner loop algorithm, based on HS-DPCCH feedback information i.e. CQI for F-DPCH and DL TPC will be used in case of non F-DPCH •Outer loop algorithm, based on Hybrid Automatic Repeat Request (ARQ) acknowledgements (ACK/NACK), for adjusting the L1 BLER target. Note that this outer loop algorithm is not related to or does not replace the RNC based OLPC algorithm for the adjustment of the UL SIR target values


HSUPA Downlink Physical Channel Power Control RAN971 (BSW) • This feature requires the following features:

• RAN 826 Basic HSUPA • RAN 968 HSUPA BTS Packet Scheduler • RAN 973 HSUPA Basic RRM • RAN1016/1848 Multimode SM FSMD/FSME

RAN971

HSUPA Downlink Physical Channel Power Control

RAN826 Basic

HSUPA

RAN968 HSUPA BTS

Packet Scheduler


RAN973 HSUPA

Basic RRM


HSUPA Downlink Physical Channel Power Control RAN971 (BSW)

Release Information RAS Release - RU40 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) BTS Release (Flexi) - WBTS8.0 BTS release (Flexi Lite) - WBTS8.0 BTS Release (Flexi 10) - FSMr3 WBTS8.0 BTS HW Release - Flexi Rel2 NetAct - OSS5.4 CD set 3 UE Release - 3GPP Rel-6


RAN1913 High Speed Cell_FACH


RAN1913 - High Speed Cell_FACH

• HSPA is used in Cell_FACH state to transport smaller data volumes • More users can be supported in Cell_FACH • Smooth data transmission is provided for users not requiring large data

volumes • Seamless transitions from Cell_FACH to Cell_DCH and from Cell_DCH

to Cell_FACH


RAN1913 - High Speed Cell_FACH RAN1637 HS-Cell_FACH DL

RAN1913 HS-Cell_FACH Activated

Dedicated channels

Common channels

Common channels

common channels also on HSPA

Cell_PCH to Cell_FACH

Low data volume Transmission on HSPA

in Cell_FACH

High data volume Transmission on HSPA

in Cell_DCH



• HS-Cell_FACH Logical channel to transport and physical channel mapping for 2 X CCPCH

Logical Channel

Transport Channel

Physical Channel

BCCH CCCH DCCH DTCH

BCH PCH

S-CCPCH

PCCH

FACH-c FACH-u

P-CCPCH S-CCPCH

HS-DSCH

HS-PDSCH

CCCH DCCH DTCH

RACH

PRACH E-DPDCH

E-DCH

Rel.7 Rel.8

Downlink (RNC UE Uplink (UE RNC


RAN1913 - High Speed Cell_FACH, cont.

RAN1637 HS-Cell_FACH DL

• The FACH scheduling in the downlink is performed in the RNC MAC layer and mapped to the SCCPCH at the BTS

• The FACH carries the following logical channels for the UEs in the Cell_FACH state: • Broadcast Control Channel (BCCH), which includes the RRC: System Information Change Indications • Dedicated Control Channel (DCCH) for UEs having the RRC connection established • Dedicated Traffic Channel (DTCH), which allows data transmission for the RRC connected UEs • Common Control Channel (CCCH), which is used by UEs for establishing the RRC connection and

when UEs access a new cell/URA area due to cell/URA reselection. • The PRACH in the uplink comprises a preamble part and a message part

• The AICH is the downlink physical channel that is used to acknowledge the preambles transmitted by the

UEs in the PRACH state • The preamble acknowledgements are transmitted when the signature included in the preamble can be

correctly detected • If no AICH is detected

• the UE increases the preamble power • The preamble is retransmitted in the next available access slot with increased transmission power


RAN1913 - High Speed Cell_FACH, cont. • HS-Cell_FACH in RU40 introduces support of HSUPA in CELL_FACH state and idle mode • This is introduced in 3GPP Release 8 in order to

• Increase the available uplink peak date rate for UEs in CELL_FACH state • Reduce the state transition delay from CELL_FACH state to CELL_DCH state • Reduce the latency of user and control plane in the IDLE mode, CELL_FACH, CELL_PCH and

URA_PCH state • The Enhanced UL access procedure is similar to the 3GPP Rel-3 RACH procedure

• preamble transmission with power ramping • BUTwith fast E-DCH resource allocation

• The PRACH preamble part is still used for power ramping but an ACK on AICH not only acknowledges reception but also assigns a common E-DCH resource to the UE

• Once a common E-DCH resource is allocated, UE starts transmitting user data in the UL using the E-DPDCH

• This data transmission still has the possibility of collision due to users competing for UL RESOURCES until further potential collision is resolved by the BTS via a UE specific E-RNTI on AGCH

• After this, UE transmits exclusively on this allocated common E-DCH resource until this resource is released by either the BTS or by the UE

• After the common E-DCH resource is released, any further UL transmissions require the above described access procedure to be performed again

• This E-DCH Enhanced Random access procedure is only required at the start of each UL transmission



• Each common E-DCH resource consists of parameters used by the UE to transmits and receive data in High Speed CELL_FACH operation e.g. • F-DPCH code and time-offset • E-RGCH/E-HICH code and signature • E-AGCH code • HS-DPCCH parameters (power offsets, CQI) • Up to 32 common E-DCH resources can be configured in the cell and are broadcast by system SIB

5/5bis • Common E-DCH resource allocation are under direct control of the BTS • A Common E-DCH is configured in the cell by the RNC but it is not involved in the assignment of these

resources to UEs • The UE can determine a particular E-DCH resource configuration to use from the index indicated by the

AICH/E-AICH in response to its preamble transmission



• HS-Cell_FACH in RU40 introduces support of HSUPA in CELL_FACH state and idle mode • This is introduced in 3GPP Release 8 in order to

• Increase the available uplink peak date rate for UEs in CELL_FACH state • Reduce the state transition delay from CELL_FACH state to CELL_DCH state • Reduce the latency of user and control plane in the IDLE mode, CELL_FACH, CELL_PCH and

URA_PCH state • The Enhanced UL access procedure is similar to the 3GPP Rel-3 RACH procedure

• preamble transmission with power ramping • BUTwith fast E-DCH resource allocation

• The PRACH preamble part is still used for power ramping but an ACK on AICH not only acknowledges reception but also assigns a common E-DCH resource to the UE

• Once a common E-DCH resource is allocated, UE starts transmitting user data in the UL using the E-DPDCH

• This data transmission still has the possibility of collision due to users competing for UL RESOURCES until further potential collision is resolved by the BTS via a UE specific E-RNTI on AGCH

• After this, UE transmits exclusively on this allocated common E-DCH resource until this resource is released by either the BTS or by the UE

• After the common E-DCH resource is released, any further UL transmissions require the above described access procedure to be performed again

• This E-DCH Enhanced Random access procedure is only required at the start of each UL transmission



• Each common E-DCH resource consists of parameters used by the UE to transmits and receive data in High Speed CELL_FACH operation e.g. • F-DPCH code and time-offset • E-RGCH/E-HICH code and signature • E-AGCH code • HS-DPCCH parameters (power offsets, CQI) • Up to 32 common E-DCH resources can be configured in the cell and are broadcast by system SIB

5/5bis • Common E-DCH resource allocation are under direct control of the BTS • A Common E-DCH is configured in the cell by the RNC but it is not involved in the assignment of these

resources to UEs • The UE can determine a particular E-DCH resource configuration to use from the index indicated by the

AICH/E-AICH in response to its preamble transmission



• Uplink • PRACH Preamble Part is used for Power ramping phase before transmission

on common E-DCH • E-DPDCH is used for Uplink user data • E-DPCCH is used for Control signaling for E-DPDCH (RSN, E-TFCI and

Happy Bit) • HS-DPCCH (if configured) is used for HS-DSCH control signaling CQI, HARQ

ACK/NACK • DPCCH is used for Power Control Commands

• Downlink • AICH is used for access grant and allocation of E-DCH resources • E-HICH is used for HARQ ACK/NACK (E-DCH) • E-AGCH is used for collision resolution, scheduling and release of common E-

DCH resources • E-RGCH (if configured) is used for scheduling • F-DPCH is used for Power Control Commands


RAN1913 - High Speed Cell_FACH)

• E-DCH procedure (RAN1913)

DL

UL

{ 1

PRACH

2

AICH response

AICH

3

AICH responds Common E-DCH resource assigned

BTS start transmitting on F-DPCH and synchronizes UE starts transmitting on DPCCH and synchronizes

Collision probability is high

E-DPDCH E-DPCCH

4

RACH type random access with preambles and power ramping



• E-DCH procedure (RAN1913)

DL

UL

{ 1

PRACH

2

AICH response

AICH

3

E-DPDCH E-DPCCH

4

E-AGCH

5

Common E-DCH resources exclusively used by this UE

E-DPDCH E-DPCCH

E-DPDCH E-DPCCH

5

First E-AGCH transmission with the UE’s E-RNTI is used for collision detection/resolving It marks the end of the collision detection phase It is also used as the absolute grant



1. UE receives system information: • UL interference level • AS & signature setting • Thresholds • sub-channels • Access Class (AC) to Access Service Class (ASC) mapping • Initial gain factor (or initial bit-rate) • Outer Loop Power Control (OLPC), select access slot and signature

2. Rel. 99 RACH type random access with preambles and power ramping 3. Channel access and resource assignment 4. BTS start transmitting on F-DPCH and synchronizes 5. UE starts transmitting on DPCCH and synchronizes



Overall timing relations for E-DCH Transmission in Cell_FACH and Idle state from a UE perspective when using HS-Cell_FACH



1. UE receives system information: • UL interference level • AS & signature setting • Thresholds • sub-channels • Access Class (AC) to Access Service Class (ASC) mapping • Initial gain factor (or initial bit-rate) • Outer Loop Power Control (OLPC), select access slot and signature

2. Rel. 99 RACH type random access with preambles and power ramping 3. Channel access and resource assignment 4. BTS start transmitting on F-DPCH and synchronizes 5. UE starts transmitting on DPCCH and synchronizes 6. E-DPCCH and E-DPDCH transmission. During the collision resolution phase, the UE’s E-RNTI is

included in all MAC-i PDUs 7. E-HICH for HARQ functionality 8. First E-AGCH transmission with the UE’s E-RNTI is used for collision detection/resolving.It marks the end

of the collision detection phase. It is also used as absolute grant 9. HS-DPCCH to support DL HS-DSCH transmission

10. Stop the transmission: •UE runs out of data •BTS stops transmission •Transition to CELL_DCH



• In idle mode or if no E-RNTI identifier is allocated to the UE only Common Control Channel (CCCH) data transmission is possible

• Once the E-RNTI has been allocated collision resolution can be carried out and dedicated data transmission and control signaling is granted on E-DCH

• When the UL resources have been assigned, inner loop power control is started and the UE is able to send ACK/NACK and CQI for the HSDSCH

• If High Speed Cell_FACH is not used in the uplink for Rel7 or older UEs then Rel99 RACH is used

• There is no dedicated uplink feedback signaling channel and HSDPA HARQ cannot be used

• The MAC layer can be configured to execute fixed downlink retransmissions.

• High Speed Cell_FACH allows fast service for a large number of users at the same time



• For bursty data like SMSs and push-email the response times allow a Cell_FACH state data transfer without frequent switching to Cell_DCH state

• With High Speed Cell_FACH uplink, the collision probability remains very low when the Rel99 PRACH has already reached a probability of 1

• BTS baseband resources are efficiently shared between High Speed Cell_FACH state UEs since resources are not reserved for a UE during inactivity

• This improves resource utilization at the RNC since the Cell_DCH setup is not needed for a short data burst.

• Considering the increasing amounts of keep-alive messaging from smartphones High Speed Cell_FACH has major benefits for BTS and RNC resource utilization

• The control of state transitions takes into account the UE device type.



• This feature requires the following features: • RAN1637: High Speed Cell_FACH DL • RAN1910: Flexible RLC Uplink • RAN1638: Flexible RLC Downlink • RAN1016/RAN1848: Flexi BTS Multimode System Module • RAN2261: Flexible User Plane Capacity in RNC196 and RNC450

RAN1913 HS-Cell_FACH

RAN1910 Flexible RLC

Uplink

RAN1638 Flexible RLC

Downlink


RAN1226 RNC196/450 HSPA Peak

Rate Upgrade



Release Information RAS Release - RU40 RNC Release - RN7.0 IPA Platform - A14 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) mcRNC Release - mcRNC3.0 RNC Flexi Direct Release - ADA5.0 BTS Release (Flexi) - WBTS8.0 BTS release (Flexi Lite) - WBTS8.0 BTS Release (Flexi 10) - FSMr3 WBTS8.0 BTS HW Release - Flexi Rel2/Flexi Rel3.0 NetAct - OSS5.4 CD set 3 UE Release - 3GPP Rel-8



Activating HS-Cell_FACH: • Set the feature license ON

• For IPA-RNC: • ZW7M:FEA=1795:ON; • For mcRNC:

set license feature-mgmt id 0000001795 feature-admin-state on

• HSDPA/HSUPA should already be enabled and working • Cell requires locking • Set the following parameters

• WCEL - PowerSaveHSPAType parameter is set to 0 (NoHSPA05ReConf) or 2 (HSPA5)



• WCEL – HSFACHEnabled is set to ‘Enabled’

• WCEL – HSRACHEnabled parameter is set to ‘Enabled’



• RNFC - FRLCEnabled parameter is set to ‘Enabled‘ • RNFC - FlexULRLCEnabled parameter is set to ‘Enabled’


RAN2451 Fast Dormancy Profiling


RAN2451 - Fast Dormancy Profiling

Significant Control plane load reduction in the RNC by identifying smart phones causing extra signalling load


RAN2451 - Fast Dormancy Profiling, cont. • Legacy smartphones causing unnecessary signalling load are identified and moved Cell_PCH/URA_PCH

state • Shorter inactivity timers are used to avoid signalling connection release • Higher traffic volume measurement thresholds for the use of common channels is configured to avoid state

transition to Cell_DCH for keep-alive messages • PS call setup from idle state to Cell_DCH state requires almost ten times more signaling when compared to

Cell_PCH use and sending smaller packets in Cell_FACH state • Control plane load of Iub, Iu and core network is reduced • Users will benefit in terms of longer battery life • Identification is based on the signalling connection release triggered by the UE. • When the UE sends the Signalling Conection Release Indication (SCRI) to the RNC without any cause then

this UE is treated as Legacy Fast Dormancy (LFD) phone and is moved to Cell_PCH/URA_PCH state • If the UE creates new RRC connection while the IMSI is still stored (old double reservation functionality) the

UE is classified as a "legacy fast dormancy phone“ • To prevent these UEs from sending the SCRI again and going to idle mode the RNC uses shorter

inactivity/idle timers so that the RNC reacts faster than the UE • When this idle timer expires, RNC moves the UE to Cell_PCH/URA_PCH state before they initiate the

connection release • The RNC can control the UE state • UE battery consumption is kept low

• Uisng Cell_PCH state only requires about one third of the RAN signalling when compared to the signalling amount required to perform RRC connection setup again after it is released

• Frequent RRC connection releases and setups causes additional uneccessary load to the core network. • PCH state has to be supported in the RNC before Fast Dormancy Profiling can be used



Release Information RAS Release - RU40 RNC Release - RN7.0 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) mcRNC Release - mcRNC3.0 Flexi Direct Release - ADA5.0 NetAct - OSS5.4 CD set 3



•Activating Fast Dormancy Profiling: •Licence feature Code - 3384 •Check and activate the licence •IPA-RNC:

• ZW7I:FEA,LIM:FEA=3384,FSTATE=ON; • ZW7M:FEA=3384:ON;

•mcRNC and I-HSPA Adapter: set license feature-mgmt id 0000003384 feature-admin-state on •Expand the RNFC object •Select Edit parameters from the RNFC object •Set the LFDProfEnabled parameter to Enabled


RAN1910 Flexible RLC in UL


RAN1910 - Flexible RLC in UL • Fixed RLC PDU in UL (3GPP Rel-7) is a

bottleneck: – HSUPA RLC peak rate is limited due to

number of concatenated overheads – RLC PDU size is fixed and independent from

the current radio conditions

• Flexible RLC PDU in UL (3GPP Rel-8) omits that bottleneck:

– RLC PDUs can be as large as IP packet – RLC PDU size reflects radio conditions – HSUPA RLC peak rate is increased – Average network throughput is increased – New functional entities of MAC-i and MAC-is

are added to MAC layer to handle new variable RLC PDUs

– Less RLC processing since the number of packets to be processed is reduced

IP packet 1500 bytes

3GPP Rel-7

RLC

PDCP

3GPP Rel-8

RLC packet size equals to 40 or 80 bytes

IP packet 1500 bytes

RLC packet size flexible between 2 – 1505 bytes

RLC …

PDCP


RAN1910 - Flexible RLC in UL, cont. Benefits End-user benefits Feature RAN1910: Flexible RLC in UL enables higher bit rates for single end users. Operator benefits This feature benefits the operator as follows: increases overall data throughput in the network reduces the Layer 2 overhead and padding in combination with the optimum transport block size for different radio conditions Functional description The flexible RLC PDU size reduces processing needs both in the UE and the RNC. The feature is part of 3GPP Rel-8, optional for the UE. It is applied for the UE supporting flexible RLC in the UL, recognized in the RAN by the UE capability. Feature RAN1910: Flexible RLC in UL is characterized by the following:

• The size of the uplink RLC PDUs can be significantly larger with the feature activated and it is determined autonomously by the RLC layer within the limits given by upper layers.

• There is no need to use padding to reach a certain predefined PDU size. The feature is applicable for:

• radio bearers (RBs) using acknowledged mode (AM) RLC or unacknowledged mode (UM) RLC and mapped on the enhanced dedicated transport channel (E-DCH) using MAC-i or MAC-is in CDSP-DH card

• signaling radio bearers (SRBs) using AM or UM RLC and mapped on the E-DCH transport channel using MAC-i or MAC-is in CDSP-DH card


RAN1910 - Flexible RLC in UL

…

RAN1910 Activated


TCP/IP Payload TCP/IP header

RLC SDU

MAC-es/e headers Paddings

MTU: 1500 bytes

RLC PDUs

TCP/IP Payload TCP/IP header

RLC SDU

MTU: 1500 bytes

MAC-is/i headers

RLC PDU Padding

Control data = 3.72% of whole transport block • When the transmission error occurs one small RLC PDU

needs to be retransmitted

19 MAC-es/e headers required + optional padding

19 fixed RLC PDUs (656 bits each) required per 1500 bytes IP packet

One MAC-is/i header required + optional padding

One RLC PDU is required per 1500 bytes IP packet

Control data = 0.27% of whole transport block • It corresponds to 93% drop of control data for typical IP

packet size of 1500 bytes • When the transmission errors occur one big RLC PDU

needs to be retransmitted


RAN1910 - Flexible RLC in UL, cont. Flexible RLC is used in the uplink for the E-DCH. RLC operation is simplified; the IP packet received from the upper layer in the service data unit (SDU) can be passed to the MAC layer typically in one or two RLC PDUs. Segmentation is used when the IP packet size exceeds the maximum RLC PDU payload size, which in the 3GPP specifications is 1503 bytes. In order to support flexible RLC PDU sizes in the WCDMA UL, new MAC entities are necessary for the RNC, BTS, and UE:

• MAC-i is introduced in the BTS and the UE • MAC-is is introduced in the RNC and the UE

The MAC layer supports handling of SDUs with different sizes, and their segmentation when needed. MAC-i (together with the E-DCH scheduler) handles E-DCH specific functions in the BTS, such as:

• E-DCH scheduling • E-DCH control • de-multiplexing of MAC-i PDUs • reading UE ID • hybrid automatic repeat request (HARQ)

MAC-is handles E-DCH specific functions (not covered in the MAC-i entity in the BTS) such as: • disassembly of MAC-is PDUs • reordering queue distribution and reordering of received MAC-is PDUs • macro diversity selection • re-assembly of segmented MAC-d or MAC-c PDUs • cyclic redundancy check (CRC) error detection



RAN826 Basic HSUPA

RAN1638 Flexible RLC (DL)

RAN1910 Flexible RLC in UL

• Software requirements: – Flexible RLC (DL) (RAN1638) – Basic HSUPA (RAN826)

RAN1016 Flexi BTS

Multimode System Module – FSMD

RAN1848 Flexi BTS

Multimode System Module – FSME

RAN2382 Flexi BTS

Multimode System Module – FSMC

or

• Hardware requirements: – Flexi BTS Multimode System Module – FSMC

(RAN2382), or – Flexi BTS Multimode System Module – FSMD

(RAN1016), or – Flexi BTS Multimode System Module – FSME

(RAN1848)

or


Flexible RLC in Uplink Overview (simplified)

RLC

MAC-d

MAC-is/i MAC-i MAC-is

RLC

MAC-d

UE BTS RNC

• UE selects the E-TFC and TBS according to current grant on TTI basis • RLC operations (segmentation and concatenation) on RLC SDUs are

performed to fit maximum RLC PDU size • New MAC-is/i are introduced in order to handle flexible instead of fixed

size RLC PDUs – MAC-i is introduced in the UE and BTS – MAC-is is introduced in the UE and RNC

Uu Iub


Flexible RLC in Uplink MAC-is/-i structure in the BTS and in the RNC for DCCH/DTCH transmission • RNC’s MAC-is handles E-DCH specific functionality:

– Disassembly of MAC-is PDUs – Reordering queue distribution – Reordering of received MAC-is PDUs – Macro diversity selection – Reassembly of segmented MAC-d/c PDUs – CRC error detection (needs RAN1913)

MAC-i

MAC-is

RLC

MAC-d

BTS

RNC

Iub

Uu

• BTS’s MAC-i together with the E-DCH scheduler handles HSUPA specific functions: – E-DCH scheduling – E-DCH control – De-multiplexing of MAC-i PDUs – Reading UE’s id – HARQ associated procedures


• 3GPP Rel. 9 TS 25.306 specification define new E-DCH categories (the feature was itself was specified earlier, in 3GPP Rel. 8) which support MAC-i/is and therefore support FRLC in UL

• Those categories include: – E-DCH Category 8 and 9

• In the table below some details concerning new categories are presented:

• The information concerning the support of the MAC-i/is is indicated in the new UE information element named “Support of MAC-i/is”

– The absence of IE indicates that UE does not support MAC-i/is operation

E-DCH Cat.

Max. number of E-DCH codes per TB

Maximum modulation order

Dual Cell E-DCH operation

Min. spreading factor

Max. number of bits of an E-DCH TB within TTI

Support of E-DCH TTI

Max. L1 throughput* [Mbit/s]

8 4 QPSK supported SF2 11484 2ms** only 5.742

9 4 16QAM*** supported SF2 22996 2ms** only 11.498

Flexible RLC in Uplink New E-DCH UE Categories

*- No DC E-DCH operation is assumed **- Requires HSUPA 2ms TTI (RAN1470) *** - Requires HSUPA 16QAM (RAN1645)



New Parameters:


FlexULRLCEnabled Flexible UL RLC Enabled RNFC


object HSUPAUserLimit16QAM HSUPA user limit for 16QAM usage WCEL AMRLCRelatTxWindowRate8 AM RLC relative Tx window size defining data rate 8 RNRLC AMRLCRelatTXWindowRate8Size AM RLC relative Tx window size assigned to data rate 8 RNRLC

Modified Parameters:


RAN1910 - Flexible RLC in UL, cont. New Parameters: FlexULRLCEnabled:

This parameter enables/disables use of feature Flexible UL RLC. If the parameter is enabled (1), then feature Flexible UL RLC is used in the RNC. If the parameter is disabled (0), then feature Flexible UL RLC is not used in the RNC. Range: 0 (Disabled), 1 (Enabled); Default= 0.

Modified parameters: HSUPAUserLimit16QAM:

This parameter defines the limit for the amount of active HSUPA users in a cell in the process of determining the usage of HSUPA 16QAM with both fixed and flexible UL RLC. For flexible UL RLC: If the amount of active HSUPA users in a cell is lower than or equal to the threshold, defined by this parameter, the HSUPA 16QAM usage is allowed with flexible UL RLC PDU size. For fixed UL RLC: If the amount of active HSUPA users in a cell is lower than or equal to the threshold defined by this parameter, the fixed UL RLC PDU size must be 656 bits. Otherwise an UL RLC PDU size of 336 bits can be used. The HSUPA 16QAM usage is allowed if the UL RLC PDU size is 656 bits. Range:1..10, step 1. Default:2 (Default value of 2 enables UE-UE call in cell with 16QAM)

AMRLCRelatTxWindowRate8: This parameter defines the eighth transport channel user data rate for the definition of the relative transmission window size of the AM RLC. Range: 8..85000 kbps, step 8 kbps. Default=85000 kbps. The final size of the transmission window is defined for UL transport channel data rate by sharing out the RLC buffer of the UE between the transport channels in the ratio of their relative window sizes

AMRLCRelatTXWindowRate8Size: This parameter assigns the relative transmission window size of the AM RLC to the eighth transport channel user data rate. The window size is defined as the number of AM PDUs. This parameter also defines the relative transmission window size for all of the non-zero transport channel user data rates which are higher than data rate number 8. Range:8..85000, step 8. Default=31000


RAN1910 - Flexible RLC in UL • Following counters were introduced to verify feature usage performance

– M1001C706 - UE SUPPORT FOR FLEXIBLE RLC UPLINK – M1006C233 - RADIO BEARER CONFIGURED FOR FLEXIBLE RLC UL

• Following counters were modified to verify feature usage performance – M5000C1xx - MAC-E PDU RETRANSMISSIONS from 0 to 12 COUNTER – M5000C142 - MAC-E PDU HARQ FAILURE COUNTER – M5000C144 - MAC-E PDU RETRANSMISSIONS UNKNOWN COUNTER – M5000C15x - HSUPA MINIMUM or MAXIMUM MAC-D THROUGHPUT – M5000C153 - HSUPA AVERAGE MAC-D THROUGHPUT – M5000C32x - HSUPA MACE PDUS WITH 2MS or 10MS TTI – M5000C36x - SUM OF (IN)CORRECTLY RECEIVED MAC-E PDUs WITH 16QAM UL – M5002C2 - E-DCH DATA VOLUME FOR SERVING CELL UL – M5002Cx - E-DCH DATA VOLUME FOR NON-SERVING CELL IN (NON-)SERVING E-DCH

RLS UL – M5002Cxx - TOTAL HSUPA DATA FOR SPI from 0 to 15 – M5002C38 - UE HSUPA THROUGHPUT CLASS from 00 to 11 – M5003Cx – (E-)xCH DATA VOLUME TO IUB-INTERFACE – M5003C19 - MAC-E PDU LOST


RAN1910 - Flexible RLC in UL, cont. New WCEL, RNC Counters: M1001C706 - UE SUPPORT FOR FLEXIBLE RLC UPLINK The number of RRC connections established by UEs supporting Flexible-RLC in the uplink direction. Updated: When an RRC connection is successfully established with RRC: RRC CONNECTION SETUP COMPLETE message or incoming relocation/HHO/ISHO by a UE that supports Flexible-RLC in the uplink direction. M1006C233 - RADIO BEARER CONFIGURED FOR FLEXIBLE RLC UL The number of successful radio bearer setups and reconfigurations to use Flexible-RLC in uplink direction. M1006C202 can be updated in parallel with this counter because it indicates the Flexible-RLC usage in the downlink direction. When the UE replies with RRC: RADIO BEARER SETUP COMPLETE or RRC: RADIO BEARER RECONFIGURATION COMPLETE indicating a successful configuration of Flexible-RLC in uplink direction that was not in use before the reconfiguration. M5000C1xx - MAC-E PDU RETRANSMISSIONS from 0 to 12 COUNTER (xx = 28 -> 40) Number of MAC-e PDUs that are received correctly with the number retransmissions indicated in the counter name in E-DCH Serving Cell. These counters are also applicable for MAC-i. When a MAC-e PDU is received correctly with the number of retransmissions indicated in the counter name. These counters are also applicable for MAC-i. Particular counters are updated only for serving cell. M5000C142 - MAC-E PDU HARQ FAILURE COUNTER Number of MAC-e PDUs that are not received correctly despite retransmission in E-DCH Serving Cell. This counter is also applicable for MAC-i. When the UE replies with RRC: RADIO BEARER SETUP COMPLETE or RRC: RADIO BEARER RECONFIGURATION COMPLETE indicating a successful configuration of Flexible-RLC in uplink direction that was not in use before the reconfiguration


RAN1910 - Flexible RLC in UL New KPIs

Average HSUPA Session Throughput, Cell Level:

duration periodt MeasuremenAM RLC usinguplink in ed transmittbytes SDU ofNumber Cell SessionThpHSUPA Avg =

WCEL)FOR AM RLC ULFOR PERIOD TIME EMENTsum(MEASUR WCEL)FOR TRAFFIC PS OF PAYLOAD SDU AM RLC UL*sum(8

Summarization Formula:

Average number of active users with HSUPA 16QAM:

RDENOMINATO USERSSPECIFIC CELL USERS) UL16QAM ACTIVE OF (SUM SUMHSUPA16QAMusr act no Avg =


RAN1910 - Flexible RLC in UL, cont. Avg HSUPA SessionThp Cell:

Average HSUPA Session Throughput, Cell Level Average HSUPA Session throughput. This KPI is based on the number of SDU bytes transmitted in uplink using RLC Acknowledge Mode and on the actual transmission time.

Avg no act usr HSUPA16QAM: Average number of HSUPA users using QAM16 modulation Average number of active HSUPA users using 16QAM modulation is given with cell specific granularity. Operator can also see summary levels such as: Network, City, Area, RNC, Cluster of cells, and Cell MEASUREMENT(S): HSPA in WBTS

M5000C359 - EDCH_16QAM_UE_ACT_SUM : The sum of sampled number of active 16QAM UL users (user configured with 16QAM and 16QAM is currently in use). Applicable only for a serving cell. The counter is updated periodically and the updated value is a snapshot of the current situation. The 16QAM modulation usage is checked from last Narq HARQ processes. Narq equals to the total number of HARQ processes. SAMPLING INTERVAL: 100ms MEASUREMENT(S): HSPA in WBTS

M5000C327 - DENOM_CPC_USERS CELL SPECIFIC USERS DENOMINATOR The counter is updated by value 1 when the number of users is sampled periodically. MEASUREMENT(S): HSPA in WBTS


RAN1910 - Flexible RLC in UL New KPI

Utilization of the HSUPA 16QAM mode:

COUNTER) UNKNOWNSIONSRETRANSMIS PDU E-MACCOUNTER 12 SIONSRETRANSMIS PDU E-MACCOUNTER 11 SIONSRETRANSMIS PDU E-MACCOUNTER 10 SIONSRETRANSMIS PDU E-MAC

COUNTER 9 SIONSRETRANSMIS PDU E-MACCOUNTER 8 SIONSRETRANSMIS PDU E-MACCOUNTER 7 SIONSRETRANSMIS PDU E-MACCOUNTER 6 SIONSRETRANSMIS PDU E-MACCOUNTER 5 SIONSRETRANSMIS PDU E-MACCOUNTER 4 SIONSRETRANSMIS PDU E-MACCOUNTER 3 SIONSRETRANSMIS PDU E-MACCOUNTER 2 SIONSRETRANSMIS PDU E-MACCOUNTER 1 SIONSRETRANSMIS PDU E-MAC

COUNTER 0 SIONSRETRANSMIS PDU E-(MAC SUM UL)16QAM WITHPDUs E-MAC RECEIVED CORRECTLY OF (SUM SUM* 100mode 16QAMHSUPA Util

++++++++++++

+=

MEASUREMENT(S): HSPA in WBTS


RAN1910 - Flexible RLC in UL, cont. New RNC, WCEL Counters: (Measurement HSPA in WBTS

Util HSUPA 16QAM mode: Utilization of the HSUPA 16QAM mode comparing to all received MAC-E PDUs.

M5000C360 - MACE_PDU_RX_COR_16QAM: SUM OF CORRECTLY RECEIVED MAC-E PDUs WITH 16QAM UL The number of correctly received MAC-e / MAC-i PDUs sent by 16QAM modulation in uplink. Applicable only for a serving cell. The counter is updated whenever a MAC-e / MAC-i PDU is correctly received (CRC ok) and the PDU was sent using 16QAM modulation

M5000C128 - MACE_PDU_RETR_00_COUNTER: MAC-E PDU RETRANSMISSIONS 0 COUNTER umber of MAC-e PDUs that are received correctly without retransmissions in E-DCH Serving Cell. This counter is also applicable for MAC-i. When a MAC-e PDU is received correctly with the number of retransmissions indicated in the counter name. This counter is also applicable for MAC-i. Counter updated only for serving cell.

M5000C129 - MACE_PDU_RETR_XX_COUNTER: MAC-E PDU RETRANSMISSIONS XX COUNTER (with XX = 01 to 12) Number of MAC-e PDUs that are received correctly with XX retransmissions in E-DCH Serving Cell.This counter is also applicable for MAC-i. When a MAC-e PDU is received correctly with the number of retransmissions indicated in the counter name. This counter is also applicable for MAC-i. Counter updated only for serving cell.

M5000C144 - MACE_PDU_RETR_UNKNOWN_COUNTER: Number of MAC-e PDUs that are received correctly but the number of retransmissions is unknown. This counter is also applicable for MAC-i. When a MAC-e PDU is correctly received but the number of retransmissions is not known. This counter is also applicable for MAC-i. Counter updated only for serving cell.


RAN1910 - Flexible RLC in UL New KPIs

Nbr of Radio Bearers using UL Flexible RLC:

( )LC_ULFLEXIBLE_RRB_CONFIG_RLCFlex ULRBs ofNbr SUM=

UEs with Flexible UL RLC capability ratio:

ACC_COMP)RRC_RELOC_ PNN_ACC_COMSUM(RRC_CO)LEX_RLC_UL(UE_SUPP_F SUMratio cap RLC Flex UL UEs

+=

HSUPA throughput utilization per BTS

−

+

+

=t) throughpuratepeak (Licensed

60)*RATION(PERIOD_DU

8)*H_UL)NSC_NS_EDCEDCH_DATA__ULNSC_S_EDCHEDCH_DATA_

_SCELL_UL(EDCH_DATAsum( * 100

BTSper utilHSUPA thr


RAN1910 - Flexible RLC in UL, cont.

New KPIs: Nbr of RBs UL Flex RLC: Number of Radio Bearers which were configured to use Flexible UL RLC MEASUREMENT(S): RRC signalling M1006C233 - RB_CONFIG_FLEXIBLE_RLC_UL: RADIO BEARER CONFIGURED FOR FLEXIBLE RLC UL The number of successful radio bearer setups and reconfigurations to use Flexible-RLC in uplink direction. When the UE replies with RRC: RADIO BEARER SETUP COMPLETE or RRC: RADIO BEARER RECONFIGURATION COMPLETE indicating a successful configuration of Flexible-RLC in uplink direction that was not in use before the reconfiguration. MEASUREMENT(S): RRC signalling UEs Flex UL RLC cap ratio: This KPIs give the percetange of UEs capable of using Flexible-RLC in the uplink direction related to all Ues. Ue capability are determined based on RRC: RRC CONNECTION SETUP COMPLETE message or incoming relocation/HHO/ISHO M1001C706 - UE_SUPP_FLEX_RLC_UL: UE SUPPORT FOR FLEXIBLE RLC UPLINK The number of RRC connections established by UEs supporting Flexible-RLC in the uplink direction. When an RRC connection is successfully established with RRC: RRC CONNECTION SETUP COMPLETE message or incoming relocation/HHO/ISHO by a UE that supports Flexible-RLC in the uplink direction. MEASUREMENT: ServiceLevel


RAN1910 - Flexible RLC in UL, cont. M5002C2 - EDCH_DATA_SCELL_UL:

E-DCH DATA VOLUME FOR SERVING CELL UL Amount of MAC-e PDU data transferred in the E-DCH serving cell in the uplink direction during the measurement interval. The MAC-e header includes to the MAC-e PDU data calculation. This counter is also used for MAC-i PDU data amount calculation.The MAC-i header includes to the MAC-i PDU data calculation. The counter is updated when the connection is released or the measurement interval ends. MEASUREMENT: Cell_Throughput_WBTS UNIT: kbyte M5002C3 - EDCH_DATA_NSC_S_EDCH_UL: E-DCH DATA VOLUME FOR NON-SERVING CELL IN SERVING E-DCH RLS UL Amount of MAC-e PDU data transferred in the E-DCH non-serving cell in the serving radiolink set in the uplink direction during the measurement interval. The MAC-e header includes to the MAC-e PDU data calculation. This counter is also used for MAC-i PDU data amount calculation.The MAC-i header includes to the MAC-i PDU data calculation. The counter is updated when the connection is released or the measurement interval ends. MEASUREMENT: Cell_Throughput_WBTS UNIT: kbyte

M5002C4 - EDCH_DATA_NSC_NS_EDCH_UL: E-DCH DATA VOLUME FOR NON-SERVING CELL IN NON-SERVING E-DCH RLS UL Amount of MAC-e PDU data transferred in the E-DCH non-serving cell in the non-serving radiolink set in the uplink direction during the measurement interval. The MAC-e header includes to the MAC-e PDU data calculation. This counter is also used for MAC-i PDU data amount calculation.The MAC-i header includes to the MAC-i PDU data calculation. The counter is updated when the connection is released or the measurement interval ends. MEASUREMENT: Cell_Throughput_WBTS UNIT: kbyte



WCDMA Release RU40 Flexi Direct Flexi Direct RU40 RNC Release RN7.0 mcRNC Release mcRNC3.0 BTS (Flexi) WBTS8.0 NetAct OSS5.4 CD set 3 HW Requirements Flexi Rel2 UE Release 3GPP Rel-8

Release Information:


RAN1908 UE DRX in Cell_FACH


RAN1908 - UE DRX in Cell_FACH

Battery savings

Rx On

HS-SCCH frames

Rx On Rx Off

Discontinuous reception of HS-DSCH in Cell_FACH state allows to:

• Periodically turn off the receiver • Read HS-SCCH frames at regular

fixed interval (when RX is on)

It enables to transfer periodically short packets i.e. keep-alive messages

DRX reception allows to decrease UE battery consumption comparing to legacy Cell_FACH (without DRX)

The latency for downlink traffic is increased by the DRX process


RAN1908 - UE DRX in Cell_FACH, cont.

Brief Description:

• Feature enables a discontinuous reception (UE DRX) for High Speed Cell_FACH state according to 3GPP Rel8 UEs onwards

• UE doesn’t need to decode all the downlink HS-SCCH frames in Cell_FACH state

• DRX operation in Cell_FACH state is interrupted when data transmission is started

• Feature is dedicated especially for smartphone users Benefits: End-user benefits

• Discontinuous reception in High Speed Cell_FACH state results in reduced UE battery consumption.

Operator benefits

• Lower battery consumption enables longer Cell_FACH state times, resulting in faster

• response times.



Without UE DRX in Cell_FACH feature there is a certian power loss in cell_fach state due to RX always switched on even if no data are being transmitted.

With UE DRX in Cell_FACH feature there is more rational power utilization at UE in cell_fach state. Less power is lost when transmission is not present due to RX switched off.

Data

HS-SCCH frames

Data

RX continous switched on

Unnecessary power loss

No data transmission Data

HS-SCCH frames

Data

RX off

No power loss

No data transmission

RX on RX on


RAN1908 - UE DRX in Cell_FACH Feature Requirements: • RAN1913 High Speed Cell_FACH • RAN2261 Flexible User Plane Capacity is needed for RNC196 and RNC450 (all capacity steps) • RAN1016/RAN1848 Flexi BTS Multimode System Module • UEs: 3GPP Rel8

RAN1016 RAN1848

Flexi BTS Multimode SM

RAN1913 High Speed Cell_FACH

RAN1908* UE DRX in Cell_FACH

*RAN1908 UE DRX in Cell_FACH with RAN1913 High Speed Cell_FACH is based on Cell_FACH state. In RAN1644 CPC similar functionality of UE DRX exists but it is based on Cell_DCH state

RAN2261 Flexible User Plane

Capacity Only for RNC196 and RNC450


RAN1908 - UE DRX in Cell_FACH DRX Process

DRX process includes: • RX burst length – the duration in frames during which UE reads HS-SCCH transmission • DRX cycle sum – includes RX burst length and DRX cycle • DRX cycle is the time during which UE will not read HS-SCCH frame

Rx burst length

DRX cycle sum

DRX cycle sum

DRX cycle sum

Inactivity time

E-DCH/HS-DSCH resource allocated

RX off RX off RX off RX off

DRX cycle

Rx burst length

DRX cycle

Rx burst length

DRX cycle

After inactivity time new

DRX cycle starts

Rx burst is described by HS-DSCH Rx burst

FACH parameter

Inactivity time is sort of a buffer protecting Rx burst from cancellation

(due to too fast jump from RX to DRX state) DRX cycle is described by

HS-DSCH DRX cycle FACH parameter




HSFACHDRXEnabled UE DRX with High Speed Cell FACH Enabled WCEL

T321 High Speed Cell FACH DRX operation timer WCEL

DRXCycleHSFACH Discontinuous Reception Cycle HS-FACH WCEL

RXBurstHSFACH HS-FACH Reception Burst WCEL

DRXInterruptHSDSCHData DRX Interruption by HS-DSCH data WCEL

DRXInactiveTimerHSFACH Inactivity Supervision Timer of HSFACH for DRX User WCEL

New Parameters:

DRX cycle

E-DCH/HS-DSCH resource allocated

DRX operation

RX burst

Enabled/Disabled

T321

NO DATA TRANSMISSION

UE change to

CELL_PCH

Or

URA_PCH

T321 is restarted at the end of HS-SCCH subframe


RAN1908 - UE DRX in Cell_FACH, cont. New Parameters: HSFACHDRXEnabled:

UE DRX with High Speed Cell FACH Enabled The parameter enables / disables the use of HSFACH in DL in the cell, that is the use of HSDPA in the cell for the UE on CELL_FACH state. Range: Disabled (0), Enabled (1); Default value = Disabled (0)

T321: High Speed Cell FACH DRX operation timer This parameter indicates the time the UE waits until initiating DRX operation in High Speed CELL_FACH. UE enters HS-DSCH DRX cycle after the expiry of this timer Range: 100 ms (0), 200 ms (1), 400 ms (2), 800 ms (3); Default value = 100 ms (0)

DRXCycleHSFACH: Discontinuous Reception Cycle HS-FACH. This parameter indicates the length of the DRX Cycle during DRX operation in High Speed CELL_FACH. Range: 4 frames (0), 8 frames (1), 16 frames (2), 32 frames (3); Default value = 16 frames (2)

RXBurstHSFACH: HS-FACH Reception Burst This parameter indicates the period within the DRX Cycle that the UE continuously receives HS-DSCH. Range 1 frames (0), 2 frames (1), 4 frames (2), 8 frames (3), 16 frames (4); Default value 1 frames (0)




object SUM_OPER_TIME_HSFACH_RX SUM OF TIME UE IN HSFACH RX HSDPA_WBTS

SUM_OPER_TIME_HSFACH_DRX SUM OF TIME UE IN HSFACH DRX HSDPA_WBTS

New Counters:


RAN1908 - UE DRX in Cell_FACH, cont. DRXInterruptHSDSCHData:

DRX Interruption by HS-DSCH data This parameter indicates whether DRX operation in High Speed CELL_FACH can be interrupted by HS-DSCH data or not. Range: Disabled (0), Enabled (1); Default value = Disabled (0)

DRXInactiveTimerHSFACH: Inactivity Supervision Timer of HS-FACH for DRX User This timer is used on MAC -c to detect the idle periods on data transmission (NRT HSPA RBs and SRBs) for the Rel8 and newer UEs on CELL_FACH using HS-FACH with DRX Mode. Based on this timer the MAC -c shall give No_Data indication to RRC, which further can change the state of the UE from Cell_FACH state to the Cell_PCH state (or URA_PCH state). Range: 1... 120 s; Default value 2 s

New Counters: SUM_OPER_TIME_HSFACH_RX: SUM OF TIME UE IN HSFACH RX Duration of UE in HSFACH RX (Reception) state This counter is updated when the UE state is changing to the DRX state. MEASUREMENT: HSDPA_WBTS SUM_OPER_TIME_HSFACH_DRX SUM OF TIME UE IN HSFACH DRX Duration of UE in HSFACH DRX (Discontinuous Reception) state This counter is updated when the UE state is changing to the RX state. MEASUREMENT: HSDPA_WBTS



WCDMA Release RU40 I-HSPA System I-HSPA Rel5 RNC Release RN7.0 mcRNC Release mcRNC3.0 BTS (Flexi) WBTS 8.0 NetAct OSS5.4 CD set 3 HW Requirements Flexi Rel2 or 3 UE Release 3GPP Rel8 Licence Control in NE RNC LK



RAN2302 Dynamic HSUPA BLER


RAN2302 - Dynamic HSUPA BLER

Peak throughput UE

UE

UE RNC Flexi BTS

Constant transmission (full buffer traffic), potentially lots of retransmission due to cell

edge, causing increased UL Interference level Bursty traffic

10% BLER target in OLPC



Without the feature, HSUPA BLER target in Outer Loop Power Control (OLPC) in RNC is constant regardless to the radio transmission conditions, nature of the traffic (Continuous, Bursty , Peak data rates) and E-DCH TTI length (2ms, 10 ms)


RAN2302 - Dynamic HSUPA BLER Dynamic HSUPA BLER is enabled with Parameter HSUPADynBLEREnabled (RNFC) •In Setup and reconfiguration phase, OLPC controller shall receive a set of HSUPA BLER target values and max rate for each RBs. Earlier only one target value was send to OLPC.

Connections with high throughput

Connections with bursty activity

Other Connections

Apply Low BLER Target to allow a further increase in throughput

Apply moderate BLER Target to help improve latency i.e. Reduced requirements for re-transmission

Apply Higher BLER Target to optimise cell capacity and coverage


RAN2302 - Dynamic HSUPA BLER, cont.

Optimized BLER target for different user scenarios and radio conditions: • Close to BTS: optimizing BLER to get peak data rates • Cell edge continuous data transmission: optimizing radio

coverage and cell capacity • Bursty traffic: optimizing latency

HSUPA BLER target in outer loop power control in RNC is dynamically adjusted to optimize the operating point for the above different conditions.

BLER target is automatically adjusted to achieve best HSUPA

peak data rates and optimize HSUPA cell throughput & coverage.




HSUPA Non-Real Time traffic

10%BLER target on 1st Tx

BLER target is fixed to 10% on first transmission (1st Tx) and on every ReTx regardless to: • UE scenario: UE - BTS distance (cell edge / close to the BTS / peak data rates) • Nature of traffic: Bursty / continuous data transmission • E-DCH TTI length: 2ms / 10ms



RAN2302 Activated

• Close to BTS (peak data rates): minimized BLER to maximize UE peak data rates for bursty or continuous data flow

1% BLER on 1st ReTx*

10ms TTI:

20% BLER on 1st ReTx*

10%BLER on 1st ReTx*

• HSUPA Capacity gain*: ~ 20% • HSUPA Coverage gain*: ~ 2dB

*Preliminary gain figures from simulations, not commercially bounding

• Bursty data transmission not close to peak data rates: optimizing latency

• Continuous data transmission not close to peak data rates: optimizing radio coverage and cell capacity

OLPC in RNC enhanced, BLER target for HSUPA NRT traffic varies depending on UE scenarios:

HSUPA Non-Real Time traffic

*Example values. BLER target and the target number of Retransmissions for Block Error detection are configurable

2msTTI: 10% BLER on 2nd ReTx*


RAN2302 - Dynamic HSUPA BLER Parameters

Full name Parameter Object

HSUPA Dynamic BLER Enabled HSUPADynBLEREnabled RNFC

Peak rate threshold for bursty data of Dyn HSUPA BLER DynHSUPABLERMaxRateThrB RNAC

Peak rate thr for cont data of Dyn HSUPA BLER 2 ms TTI DynHSUPABLERMaxRateThrC2 RNAC

Peak rate thr for cont data of Dyn HSUPA BLER 10 ms TTI DynHSUPABLERMaxRateThrC10 RNAC

Bursty Data throughput threshold per TTI DynHSUPABLERThrBurstyTP RNAC

Bursty Period for Dyn HSUPA BLER DynHSUPABurstyPeriod RNAC

Window size for FP Frames Measurement DynHSUPABLERFrameWinSiz RNAC

Layer1 Peak Data Rate BLER target for E-DCH L1PeakRateBLERTrgtEDCH RNAC

Layer1 Bursty Data BLER target for E-DCH L1BurstDataBLERtrgtEDCH RNAC

Layer1 Continuous BLER target for E-DCH TTI 2 ms L1ContBLERTrgtEDCH2 RNAC

Layer1 Continuous BLER target for E-DCH TTI 10 ms L1ContBLERTrgtEDCH10 RNAC

Retransmissions in Dyn HSUPA BLER for Peak data DynHSUPABLERPeakRateRx RNAC

Retransmissions in Dyn HSUPA BLER for Bursty Data DynHSUPABLERBurstDataRx RNAC

Retransmissions in Dyn HSUPA BLER for Cont Data 2 ms TTI DynHSUPABLERContDataRx2 RNAC

Retransmissions in Dyn HSUPA BLER for Cont Data 10msTTI DynHSUPABLERContDataRx10 RNAC


RAN2302 - Dynamic HSUPA BLER Parameters, cont. HSUPADynBLEREnabled:

Range: Disabled (0), Enabled (1) ; Default = Disabled (0) ; This parameter Enables/Disables the Dynamic adjustment of HSUPA BLER

DynHSUPABLERMaxRateThrB: Range: 10..100, step 1; Default = 75 (75%) ; Defines peak rate threshold in relation to UE max data rate. Parameter is used by the dynamic HSUPA BLER algorithm. Outer loop power control of the RNC applies the parameter when UE is currently using bursty data. If current throughput exceeds value of the parameter then OLPC is configured to use the peak data rate configuration.

DynHSUPABLERMaxRateThrC2 : Range: 10..100, step 1; Default = 80 (80%) ; Defines peak rate threshold in relation to UE max data rate when E-DCH TTI = 2 ms. Parameter is used by the dynamic HSUPA BLER algorithm. Outer loop power control of the RNC applies the parameter when UE is currently using continuous data.

DynHSUPABLERMaxRateThrC10: Range: 10..100, step 1; Default = 80 (80%) ; Defines peak rate threshold in relation to UE max data rate when E-DCH TTI = 10 ms. Parameter is used by the dynamic HSUPA BLER algorithm. Outer loop power control of the RNC applies the parameter when UE is currently using continuous data.

DynHSUPABLERThrBurstyTP: Range: 10..100 frame, step 10 frame; Default = 10 frame ; Defines the throughput threshold in number of FP frames per TTI (10ms). It is used by the outer loop power control of the RNC to check the bursty data rate condition for Dynamic HSUPA BLER. In case of 2ms TTI, this same parameter is used with multiple of 5.


RAN2302 - Dynamic HSUPA BLER Parameters, cont. DynHSUPABurstyPeriod:

Range: 0..5 s, step 0.1 s; Default = 2 s ; Defines min period which the BLER state must be bursty before outer loop power control state can be changed from the bursty BLER state to continuous BLER state, or from peak or continuous BLER state to bursty BLER state. It is allowed to change BLER state from bursty or continuous BLER state to the peak BLER state without waiting for the expiration of the timer set by the parameter DynHSUPABurstyPeriod. Change from peak BLER state to bursty or continuous BLER state is performed if throughput falls below DynHSUPABLERMaxRateThrB or DynHSUPABLERMaxRateThrC10/ DynHSUPABLERMaxRateThrC2, correspondingly and condition has been valid time defined with the parameter DynHSUPABurstyPeriod.

DynHSUPABLERFrameWinSiz: Range: 0.1..5 s, step 0.1 s; Default = 1,5 s ; This parameter defines the size of the sliding averaging window for FP frames measurement of the E-DCH FP. The measurement measures the number of FP frames transmitted by the E-DCH FP during the sliding measurement window. The value 0 of the parameter means that the E-DCH FP frames measurement is not performed.

L1PeakRateBLERTrgtEDCH: Range: -2..0, step 0.1; Default = -1.3 (5% BLER) ; Defines L1 BLER target for the E-DCH MAC-d flow of PS NRT service. It is used by the OLPC of the RNC for peak data rate Value of the parameter equals to the log10 of the BLER value10^-1.3 = 0.05 i.e. BLER target is 5% (default setting).

L1BurstDataBLERtrgtEDCH: Range: -2..0, step 0.1; Default = -1 (10% BLER) ; Defines L1 BLER target for the E-DCH MAC-d flow of PS NRT service. It is used by the OLPC of the RNC for bursty data. Value of the parameter equals to the log10 of the BLER value. 10^-1 = 0.1 i.e. BLER target is 10%


RAN2302 - Dynamic HSUPA BLER Parameters, cont. L1ContBLERTrgtEDCH2:

Range: -2..0, step 0.1 ; Default = -1 (10% BLER) ; Defines L1 BLER target for the E-DCH MAC-d flow of PS NRT service when TTI = 2 ms. It is used by the OLPC of the RNC for continuous transmission that provides better throughput and coverage. Value of the parameter equals to the log10 of the BLER value.10^-1 = 0.1 i.e. BLER target is 10%. High BLER values increase latency due to HARQ retransmissions in L1. When E-DCH TTI = 2 ms is used latency increase is however small because HARQ period is 16 ms

L1ContBLERTrgtEDCH10: Range: -2..0, step 0.1; Default = -0.7 (20%BLER) ; Defines L1 BLER target for the E-DCH MAC-d flow of PS NRT service when TTI = 10 ms. It is used by the OLPC of the RNC for continuous transmission that provides better throughput and coverage. Value of the parameter equals to the log10 of the BLER value. 10^-0.7 = 0.199 i.e. BLER target is 20%. High BLER values increase latency due to HARQ retransmissions in L1, especially this is valid when E-DCH TTI = 10 ms is used.

DynHSUPABLERPeakRateRx: Range: 1..3, step 1; Default = 1; Defines the L1 HARQ retransmissions threshold for the OLPC entities dedicated to the E-DCH MAC-d flows of the PS NRT RABs. Its value is used by the OLPC of the RNC for the detection of the block error when the L1 BLER target is defined with the management parameter "Layer1 Peak Data Rate BLER target for E-DCH". Block error occurs if the number of the retransmissions equals to or is bigger than the value of the parameter or an E-HARQ failure has been observed. OLPC adjusts the UL DPCCH SIR target after block errors occurs.


RAN2302 - Dynamic HSUPA BLER Parameters, cont. DynHSUPABLERBurstDataRx:

Range: 1..3, step 1; Default = 1; Defines the L1 HARQ retransmissions threshold for the OLPC entities dedicated to the E-DCH MAC-d flows of the PS NRT RABs. Its value is used by the OLPC of the RNC for the detection of the block error when the L1 BLER target is defined with the management parameter "Layer1 Bursty Data BLER target for E-DCH".

DynHSUPABLERContDataRx2: Range: 1..3, step 1; Default = 2; Defines the L1 HARQ retransmissions threshold for the OLPC entities dedicated to the E-DCH 2 ms TTI MAC-d flows of the PS NRT RABs. Its value is used by the OLPC of the RNC for the detection of the block error when the L1 BLER target is defined with the management parameter "Layer1 Continuous BLER target for E-DCH".

DynHSUPABLERContDataRx10: Range: 1..3, step 1; Default = 1; Defines the L1 HARQ retransmissions threshold for the OLPC entities dedicated to the E-DCH 10 ms TTI MAC-d flows of the PS NRT RABs. Its value is used by the OLPC of the RNC for the detection of the block error when the L1 BLER target is defined with the management parameter "Layer1 Continuous BLER target for E-DCH".


RAN2302 - Dynamic HSUPA BLER Triggers

UE close to Peak rate (Bursty data or Continuous data).

BLER target to be used is L1PeakRateBLERTrgtEDCH after DynHSUPABLERPeakRateRx retransmissions

Yes No

No

Yes

EDCH Data Rate > Peak Rate threshold*

Number of frames per TTI < Bursty Data throughput threshold per TTI (10ms or 2ms)**

A

UE has Bursty data transmission (not close to peak rates)

BLER target to be used is L1BurstDataBLERTrgtEDCH after DynHSUPABLERBurstRateRx retransmissions

UE has Continues 2ms TTI data transmission (not close to peak rates)

BLER target to be used is L1ContBLERTrgtEDCH2 after DynHSUPABLERContDataRx2 retransmissions

E-DCH TTI

UE has Continues 10ms TTI data transmission (not close to peak rates)

BLER target to be used is L1ContBLERTrgtEDCH10 after DynHSUPABLERContDataRx10 retransmissions

2ms 10ms

B


RAN2302 - Dynamic HSUPA BLER Triggers, cont. A ⃰ Peak Rate threshold - depending on the current UE transmission constraints: • Bursty data tramsmission, or • Continuous 10ms TTI transmission, or • Continuous 2ms TTI transmission

one of the following data rate thresholds is used by the Dynamic HSUPA BLER algorithm to decide whether UE is close to Peak data rates, • Peak rate threshold for Bursty data rates (DynHSUPABLERMaxRateThrB), or • Peak rate threshold for Continuous 10ms TTI transmission

(DynHSUPABLERMaxRateThrC10), or • Peak rate threshold for Continuous 2ms TTI transmission (DynHSUPABLERMaxRateThrC2)

B ⃰ Bursty Data throughput threshold per TTI (10ms or 2ms) – it is the threshold parameter

(DynHSUPABLERThrBurstyTP) referred in Frame Protocol (FP) frames per TTI (10ms), used by the Dynamic HSUPA BLER algorithm to decide whether UE is having bursty data rates or continuous data rates


RAN2302 - Dynamic HSUPA BLER Triggers • Dynamic HSUPA BLER algorithm is started after the Averaging Sliding Window for Frame Measurement is full. Prior to that

Dynamic HSUPA BLER algorithm is not used and BLER target for OLPC is given with L1BurstDataBLERTrgtEDCH* parameter after DynHSUPABLERBurstRateRx retransmissions

• Size of Window for Frame Measurement is configurable via parameter DynHSUPABLERFrameWinSiz. Within Measurement Window, the Frame Protocol (FP) frames are counted and the measured average number of FP frames per TTI is compared to threshold parameter (DynHSUPABLERThrBurstyTP) to decide whether transmission is bursty

Sliding Window for Frame Measurement

* L1BurstDataBLERTrgtEDCH (Layer1 Bursty Data BLER target for E-DCH) is a BLER target used when Dynamic HSUPA BLER algorithm is in Bursty state (not close to Peak Rates)

• Continuous data transmission: average number of FP frames per TTI from Window for Frame Measurement is higher than threshold parameter DynHSUPABLERThrBurstyTP

• Bursty data transmission: average number of FP frames per TTI from Window for Frame Measurement is higher than threshold parameter DynHSUPABLERThrBurstyTP

Sliding Window for Frame Measurement

Single FP frame


RAN2302 - Dynamic HSUPA BLER Activation • Restart of the RNC and the BTS is not required after activation of this feature

• This procedure does not cause downtime and the feature can be activated at any time

1. Configure the following RNFC parameter

– Set the HSUPADynBLEREnabled to Enabled.

2. If necessary, configure the following RNAC parameters

a) Layer1 Peak Data Rate BLER target for E-DCH by setting the L1PeakRateBLERTrgtEDCH

b) Layer1 Bursty Data BLER target for E-DCH by setting the L1BurstDataBLERTrgtEDCH

c) Layer1 Continuous Data BLER target for E-DCH TTI=2 ms by setting the L1ContBLERTrgtEDCH2 parameter

d) Layer1 Continuous Data BLER target for E-DCH TTI 10 ms by setting the L1ContBLERTrgtEDCH10

e) L1 HARQ retransmissions threshold for the outer loop power control entities dedicated to the E-DCH MAC-d flows of the PS NRT RABs by setting the DynHSUPABLERPeakRateRx

f) L1 HARQ retransmissions threshold for the outer loop power control entities dedicated to the E-DCH MAC-d flows of the PS NRT RABs by setting the DynHSUPABLERBurstDataRx

g) L1 HARQ retransmissions threshold for the outer loop power control entities dedicated to the E-DCH 2 ms TTI MAC-d flows of the PS NRT RABs by setting the DynHSUPABLERContDataRx2


h) L1 HARQ retransmissions threshold for the outer loop power control entities dedicated to the E-DCH 10 ms TTI MAC-d flows of the PS NRT RABs by setting the DynHSUPABLERContDataRx10

i) peak rate threshold for bursty data of Dynamic HSUPA BLER by setting the DynHSUPABLERMaxRateThrB

j) peak rate threshold in relation to UE max data rate when E-DCH TTI=10 ms by setting the DynHSUPABLERMaxRateThrC10 parameter

k) peak rate threshold in relation to UE max data rate when E-DCH TTI=2 ms by setting the DynHSUPABLERMaxRateThrC2

l) minimum period which the BLER state must be bursty before outer loop power control state can be changed from the bursty BLER state to continuous BLER state, or from peak or continuous BLER state to bursty BLER state by setting the DynHSUPABurstyPeriod

m) size of the sliding averaging window for FP frames measurement of the E-DCH FP by setting the DynHSUPABLERFrameWinSiz

n) Time to trigger Dyn HSUPA BLER Algorithm by setting the DynHSUPABLERAlgTrgTime

RAN2302 - Dynamic HSUPA BLER Activation



WCDMA Release RU40 RNC Release RN7.0 mcRNC Release mcRNC3.0 BTS (Flexi) WBTS 8.0 NetAct OSS5.4 CD set 3 HW Requirements Flexi Rel2 or 3 UE Release 3GPP Rel8



RAN2494 Fast Cell_PCH Switching


RAN2494 - Fast Cell_PCH Switching

• This feature reduces the state transition times from cell_PCH and Cell_FACH states

• In transition to Cell_DCH only the new configuration parameters are delivered, otherwise previous configuration information is used

• Enhanced parallel process activation reduces state transition time

•RRC signaling is started in parallel with reservation of RNC L2 resources

Faster Cell_DCH state transitions - 350ms target

Signaling load is

lightened due to shorter signaling messages

Faster setup times Parallel signaling

processing reduces the state transition time

Improved end user experience

Cell-DCH

Cell-FACH

Cell-PCH

Optimized / compressed UE message support*

Optimized / compressed UE message support *

* UE message optimization can be applied mainly when newly allocated configuration is the same as previous


RAN2494 - Fast Cell_PCH Switching, cont. Benefits End-user benefits This feature benefits the end user by decreasing state transition time to Cell_DCH state and thus improving the end-user experience, for example, in case of web browsing. Operator benefits Network signaling load is lightened due to shorter signaling messages. With keep-alive messages faster setup time means lower number of UEs with signaling ongoing per RNC at a time




UE

All IEs are sent

BTS

RAN2494 Activated

UE

RRC messages can be smaller

BTS

Some IEs can be skipped

Messages can be send faster

RNC RNC resources optimization

RNC resources are utilized more efficient


RAN2494 - Fast Cell_PCH Switching, cont. Functional overview There are several enhancements that allow to decrease state transition time: • When state transition to Cell_DCH is triggered, RNC checks previous configuration used by

the UE and sends only new configuration parameters. With this approach some information elements (IEs) may be avoided in the RRC signaling (for example RB-Mapping-Info, RLC-Info or UL/DL Add Reconfigure Transport Channel Info List). It results in smaller message size and subsequently shorter overall state transition time.

• RNC internal signaling is improved and optimally implemented. RRC signaling is started in parallel with reservation of RNC L2 resources, which reduces state transition time.

• Optimization of UE message is applied mainly in cases where newly allocated configuration is the same as previous configuration already stored at the UE.

• Fast Cell_PCH Switching can be restricts to groups of users

• None UEs support RAN2494 • Only UEs Rel-5 and newer supports RAN2494

• Rel99 / HSDPA Cat. 1 and higher • Only UEs Rel-6 and newer support RAN2494

• HSUPA Cat 1 and higher / HSDPA Cat. 1 and higher • Only UEs Rel-7 and newer support RAN2494

• HSUPA Cat 7 and higher / HSDPA Cat. 13 and higher • Only UEs Rel-8 and newer support RAN2494

• HSUPA Cat 8 and higher / HSDPA Cat. 21 and higher

• All UEs support RAN2494


RAN2494 - Fast Cell_PCH Switching Cell_DCH to Cell_FACH Cell_PCH to Cell_FACH Following IE can be skipped

•RB-mapping-Info •UL/DL Transport Channel to Delete List

Messages affected •RRC Radio Bearer Reconfiguration Request •RRC Cell Update Confirm

IDLE_Mode

Cell_DCH

Cell_FACH

Cell_PCH

RRC: RadioBearerReconfiguration

RRC: RadioBearerReconfigurationComplete

NBAP: RadioLinkDeletionRequest

NBAP: RadioLinkDeletionResponse

UE NodeB RNC

UE

RRC: PagingType1

RRC: CellUpdate

RRC: CellUpdateConfirm

RRC: UtranMobilityInformationConfirm

NodeB RNC

Cell_PCH to Cell_FACH

Cell_DCH to Cell_FACH


RAN2494 - Fast Cell_PCH Switching Cell_PCH to Cell_DCH Cell_FACH to Cell_DCH RRC Connection Re-establishment

Following IE can be skipped •RB-mapping-Info •RLC-Info •UL/DL Transport Channel Add Reconfigure List

Messages affected •RRC Radio Bearer Reconfiguration Request •RRC Cell Update Confirm

IDLE_Mode

Cell_DCH

Cell_FACH

Cell_PCH

Cell_PCH to Cell_DCH

Cell_FACH to Cell_DCH

RRC: PagingType1

RRC: CellUpdate

RRC: CellUpdateConfirm

NBAP: RadioLinkSetupRequestFDD

NBAP: RadioLinkSetupResponseFDD

RRC: RadioBearerReconfigurationComplete

RRC: MeasurementControl

NBAP: RadioLinkRestoreIndication

UE NodeB RNC

RRC: MeasurementReport

NBAP: RadioLinkSetupRequestFDD

NBAP: RadioLinkSetupResponseFDD

RRC: RadioBearerReconfiguration RRC: RadioBearerReconfigurationComplete

RRC: MeasurementControl

NBAP: RadioLinkRestoreIndication

UE NodeB RNC



RLC parameters for new radio link are identical as previous one

•RLC configuration does not need to change

RLC parameters for new radio link are not identical as previous one

•RLC configuration is done in legacy way or •Existing RLC configuration is used during radio link setup and then in Cell_DCH RLC parameters are reconfigured

RLCConfOptionFPS parameter defines which option is used

IDLE_Mode

Cell_DCH

Cell_FACH

Cell_PCH

IDLE_Mode

Cell_DCH

Cell_FACH

Cell_PCH

RLC parameters reconfigured in Cell_DCH



No Fast Cell_PCH Switching

RRC Cell Update Confirm sent +

RNC resources reservation

RRC: Cell Update

RNC

RRC: Cell Update Confirm

RNC processing

RRC: Cell Update

RRC: Cell Update Confirm

RNC processing

Cell_FACH/Cell_DCH

Waiting for RNC resources reservation Cell_FACH/Cell_DCH

RRC Cell Update Confirm ready to send

RNC resources reservation

UE UE RNC Cell_PCH Cell_PCH

Fast Cell_PCH Switching




M1006C174 STATE TRANSITION TIME PCH TO DCH RRC signalling (RNC)

M1006C175 DENOMINATOR FOR STATE TRANSITION TIME PCH TO DCH RRC signalling (RNC)

Measurements and counters There are no new measurements and counters related to this feature, existing counters related to this feature:

Abbreviated name Full name Managed object RLCConfOptionFPS RLC Conf option switch for Fast Cell_PCH Switching RNRLC FastPCHSwitchEnabled Enabling Fast Cell_PCH Switching Service feature RNFC DCHtoPCHEnabled Enabling direct Cell_DCH to PCH state transition RNFC MACLogicalChPriority MAC logical channel priority definition RNC MACLogChPriSRB1 MAC logical channel priority for SRB1 RNC MACLogChPriSRB2 MAC logical channel priority for SRB2 RNC MACLogChPriSRB3 MAC logical channel priority for SRB3 RNC AMRLCSRB3n4PeriodMax AM RLC status period max for SRB3 and SRB4 RNRLC AMRLCSRB3n4RespTime AM RLC round trip time for SRB3 and SRB4 RNRLC

New parameters:


RAN2494 - Fast Cell_PCH Switching, cont. Key performance indicators:

There are no key performance indicators related to this feature. Existing counters related to this feature: M1006C174:

Sum of state transition times from Cell-PCH or URA-PCH state to Cell-DCH state, defined as the time between: RRC: Cell Update (cause: UL Data Transmission or Paging response) - RRC: Radio Bearer Reconfiguration Complete. When the RNC receives RRC: Radio Bearer Reconfiguration Complete.

M1006C175: Denominator for M1006C174 used for average calculation (average state transition time). Updated by value 1, then the measured time is updated to counter M1006C174.

New parameters: RLCConfOptionFPS:

Range: Legacy way (0), Optimized RLC reconfiguration (1); Default: Optimized RLC reconfiguration (1) RNC defines RLC parameters for new radio link based on the used service of the UE during RRC state transition from CELL_PCH to CELL_DCH. If the RLC parameters defined for the new radio link are identical with the previous RLC configuration, then RLC configuration does not need to change in UE or RNC RLC entity when Fast Cell_PCH Switching functionality is applied. If Fast Cell_PCH Switching functionality is applied and the RLC parameters defined for the new radio link are not identical with the previous RLC configuration, then there are two options. The first option is that RLC parameter configuration is done in the legacy way. The second option is that the existing RLC configuration is used during radio link setup and then RLC parameters are reconfigured when UE is in cell_dch state. This parameter is used to select the option. RLCConfOptionFPS parameter is used to select the

option.


RAN2494 - Fast Cell_PCH Switching, cont. FastPCHSwitchEnabled:

Range and step: 0 (Disabled), 1 (Functionality is enabled only for rel-5 and newer), 2 (Functionality is enabled only for rel-6 and newer), 3 (Functionality is enabled only for rel-7 and newer), 4 (Functionality is enabled only for rel-8 and newer), 15 (Functionality is enabled for all UEs)

Default value: 0 This parameter enables/disables the RAN2494 (Fast Cell_PCH Switching) feature. Fast Cell PCH Switching feature attempts to make faster transition from Cell/URA_PCH / Cell_FACH to Cell_DCH.

DCHtoPCHEnabled: Range and step: 0 (Disabled), 1 (Enabled); Default value: 1. This parameter defines whether direct transition from Cell_DCH to Cell_PCH is allowed or not.

MACLogicalChPriority: This parameter defines MAC logical channel priority for Signalling Radio Bearers SRB1, SRB2 and SRB3. The MAC logical channel priority for SRB1, SRB2 and SRB3 can be defined based on domain and Traffic Class (TC) . These priorities are values in the range of 1 - 3. (1 is the highest and 3 is the lowest priority). For example, see the following prioritization orders: Priority Default Config#1

1 SRBs (1-3) SRB 1 2 - SRB 2 3 - SRB 3


RAN2494 - Fast Cell_PCH Switching, cont. MACLogChPriSRB1:

Range and step: 1..3, step 1; Default value: 1: This parameter defines MAC logical channel priority for Signalling Radio Bearer1 (SRB1).

MACLogChPriSRB2: Range and step: 1..3, step 1; Default value: 1: This parameter defines MAC logical channel priority for SRB2

MACLogChPriSRB3: Range and step: 1..3, step 1; Default value: 1: This parameter defines MAC logical channel priority for SRB3

AMRLCSRB3n4PeriodMax : Range and step: 1..600 %, step 1 %; Default value: 112 %. This parameter defines the maximum status reporting period of the AM RLC in relation to the RLC round trip time for SRB3 and SRB4 for all kinds of variations of transport channel used or SRB bitrate .

AMRLCSRB3n4RespTime: Range and step: 0..1500 ms, step 10 ms; Default value: 100 ms; The parameter defines the AMRLC Round Trip Time (RTT) for the data transfer for SRB3 and SRB4 for all kinds of variations of transport channel used or SRB bitrate. It is used to estimate the average response time from the moment when the AM RLC entity sends an AMD PDU to its peer entity with the poll bit set to the receiving moment of the corresponding status PDU. The RTT depends on the L1/L2 processing delay of the UE and the RNC, type of the reverse transport channel - DCH, HS-DSCH or E-DCH, processing delay of the BTS, the Uu interface delay, and the Iub transfer delay. The parameter is used to define the AM RLC

status reporting and polling period lengths.



WCDMA Release RU40 RNC Release RN7.0 mcRNC Release mcRNC3.0 OMS RNO 2.0 (for IPA-RNC and mcRNC) IHO 5.0 (for Flexi Direct) NetAct OSS5.4 CD set 3



RAN2509 Application Aware RAN (AAR)


RAN2509 - Application Aware RAN

Dynamic service or application prioritization for HSPA scheduling leading to an enhanced user application experience

IP IP/UDP

GTP - U

Inspection and inner IP packet Marking

IP

DPI

FP MAC RLC

PDCP

GTPU

HSPDA scheduler

FP

SPI weight

MAC - d flows

NodeB RNC

0

7

8

Same Bearer Same Bearer SPI - mod in FP

Change scheduling

weights associated with the mac-d flow

Traffic type and/or activity triggers a

change of SPI

The target SPI value is sent with

the HSPA scheduler interval

DPI marks the inner IP packet DSCP value

according to the operators chosen

policies


RAN2509 - Application Aware RAN, cont. • Application differentiation provides an operator the quality of service tools

necessary to provide an enhanced user experience

• The 3GPP bearer-based QoS differentiation model is typically not widely supported by current terminals that connect using a single PDP context carrying all applications within one bearer i.e. not multi-rab

• Subscriber level QoS does not separate different applications within a single bearer although each application has different requirements when utilizing a bearer

• AAR optimizes the scheduler behavior according to policies defined by the customer for every class of traffic

• Using AAR an operator could allocate a bronze users web session a higher priority than a gold users FTP download

• A slower FTP download would not impact the user experience as much as a slow web session

• The action depends on the traffic carried by the RAB at the specific time and the action is not permanent but transient



HSPA Streaming

Optimal capacity sharing

Operator policy

HSPA NRT DCH

RT


RAN2509 - Application Aware RAN, cont.

• Decreasing the priority of peer-to-peer traffic to a lower class is particularly useful as the decreased traffic share frees up cell capacity for other traffic during peak hour.

• Using the same system capacity an operator can now provide end users a better application experience

• Capacity is shared between users in an optimal manner • Core-network-based Deep Packet Inspection (DPI) provides application detection

by marking the inner (user) IP packet with Differential Service Code Point (DSCP) values

• The SPI of the radio bearer is promoted/demoted at PDCP level according to the DPI marking

• The priority information is transferred from the RNC to the BTS scheduler via the user plane by using the Common Channel Priority Indication (CCPI) in the frame protocol (FP)

• The dynamic SPI priority change in the BTS comprises the following new functions: • dynamic change of HSDPA scheduling priority for each MAC-d priority queue • dynamic change of HSUPA scheduling priority together with DL priority

reflecting dynamically changed priority by modifying radio interface credit allocations for both congested or non-congested radio interfaces



This feature requires the following features: • RAN763 Basic HSDPA with QPSK and 5 Codes • FC085_001011 DSCP Marking for Services (Flexi NG)

Optional features: • RAN1231 HSPA over Iur (required if this feature needs to be supported over Iur) • RAN1110 HSDPA Congestion Control • RAN 1262 QoS Aware HSPA Scheduling

RAN2509

Application Aware Ran

RAN1231 HSPA over IUR

RAN1110 HSDPA Congestion

Control

RAN1262 QoS Aware HSDPA

Scheduling

RAN763 Basic HSDPA with QPSK

and 5 codes

FC085_001011 DSCP Marking for Services



Pictorial representation of the PDCP Protocol



• EF – Expedited forwarding – Strict priority e.g. CS Voice, Video and CS Streaming – Normally DSCP 46

• AF - Assured Forwarding – Each class is assigned a drop precedence • BE - Best Effort - DSCP 0

Assured Forwarding (AF) Behavior Group

Class 1 (lowest) Class 2 Class 3 Class 4 (highest)

Low Drop AF11 (DSCP 10) AF21 (DSCP 18) AF31 (DSCP 26) AF41 (DSCP 34)

Med Drop AF12 (DSCP 12) AF22 (DSCP 20) AF32 (DSCP 28) AF42 (DSCP 36)

High Drop AF13 (DSCP 14) AF23 (DSCP 22) AF33 (DSCP 30) AF43 (DSCP 38)



• Differentiated Services Code Point (DSCP) • Originally defined as the Type of Service field, this field is now defined by RFC 2474

for Differentiated services (DiffServ). • New technologies are emerging that require real-time data streaming and therefore

make use of the DSCP field. • An example is Voice over IP (VoIP), which is used for interactive data voice exchange

• IPV4 Header Structure



Byte -1 Contents

Bits Meaning

Bits 8-10 IP Precedence:

111 Network Control 110 Internetwork Control 101 Critic/ECP 100 Flash Override 011 Flash 010 Immediate 001 Priority 000 Routine

Bit 11 1 = Low Delay; 0 = Normal Delay

Bit 12 1 = High Throughput; 0 = Normal Throughput

Bit 13 1 = High Reliability; 0 = Normal Reliability

Bit 14 1 = Minimise monetary cost (RFC 1349)

Bit 15 Must be 0

DSCP Name

DS Field Value IP Precedence Binary Decimal

EF 101 110 46 5

AF11 001 010 10 1 AF12 001 100 12 1 AF13 001 110 14 1

AF21 010 010 18 2 AF22 010 100 20 2 AF23 010 110 22 2

AF31 011 010 26 3 AF32 011 100 28 3 AF33 011 110 30 3

AF41 100 010 34 4 AF42 100 100 36 4 AF43 100 110 38 4



Release Information RAS Release - RU40 RNC Release - RN7.0 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) mcRNC Release - mcRNC3.0 RNC Flexi Direct Release - ADA5.0 BTS Release (Flexi) - WBTS8.0 BTS release (Flexi Lite) - WBTS8.0 BTS Release (Flexi 10) - FSMr3 WBTS8.0 NetAct - OSS5.4 CD set 3



•Licence Feature Code = 3422 •Parameters: •Object = RNHSPA:

• InitialSPINRT • Defines the initial SPI to be used for a PS NRT HSPA or HSDPA RAB • The InitialSPINRT parameter is used when QoS Aware Scheduling is not used and

Application Aware RAN is enabled •AARConfig Table – Item List

• AppGrpId • Identifies the application group that the parameters will be applied to • All applications in the group receive the same treatment • Up to six application groups can be defined

• DSCPCode • Defines the DSCP value assigned within the specific application group • Up to five DSCP values can be assigned within each application group ID



• AARConfig Table – Item List continued • Precedence

• Defines the precedence assigned to the specific application group • Used to decide what SPI should be prioritized when packets belonging to multiple

application groups are detected by the RNC • Up to six precedence values are possible

• Precedence = 1 has highest priority and Precedence = 6 has lowest priority • TargetSPIforSPI0 to TargetSPIfor SPI11

• Defines the value of the target SPI chosen for a specific application group having an initial SPI value in the range 0 to 11

• Based on this value a new SPI is assigned to a specific application group after promotion or demotion.

• It the Target SPI is the same as the initial SPI then there will be no change to the SPI

• Object = WCEL • AppAwareRANEnabled

• Defines whether AAR is used in the cell or not



• AppAwareRANCapability • This parameter is set by the system and indicates the AAR capability of the cell • It is not modifiable

• Object = IUR • AppAwareRANEnabled

• Defines whether AAR is enabled in the DRNC or not • This value is checked when the serving HSDPA/HSPA cell is under a drift RNC • When enabled it is assumed that all BTSs under the drift RNC support AAR

(RAN2509)

• Object = RNC • DSCPStatisticsGroupA

• Defines what IU-PS GTP user data is mapped to counter M1022C227-IUPS DSCP CLASS A

• The values of DSCP that the operator chooses to monitor in a cell are set • DSCPStatisticsGroupB

• Defines what IU-PS GTP user data is mapped to counter M1022C228-IUPS DSCP CLASS B

• The values of DSCP that the operator chooses to monitor in a cell are set



• DSCPStatisticsGroupC • Defines what IU-PS GTP user data is mapped to counter M1022C229-IUPS DSCP

CLASS C • The values of DSCP that the operator chooses to monitor in a cell are set

• DSCPStatisticsGroupTCPack • Defines what IU-PS GTP user data is mapped to counter M1022C225-DL TCP

ACKS • The values of DSCP that the operator chooses to use for DL TCP ACKS for specific

UL data



Activating Application Aware RAN: • Ensure that HSPA/HSDPA is correctly enabled • Set WCEL parameter - AppAwareRANEnabled to Enabled



Activating Application Aware RAN: • If QoS Aware Scheduling will be used with AAR ensure set the WCEL parameter

HSPAQoSEnable parameter to QoS prioritization is used for HS NRT channels



• If QoS will not be used with AAR set the value of RNHSPA parameter InitialSPINRT to the desired value 5 or 6

• Configure the RNHSPA object – Application Aware RAN Configuration Table according to the CN values

• If AAR will be used over the IUR set the IUR parameter AppAwareRANEnabled to Enabled


RAN2179 Dual Band HSDPA 42Mbps


RAN2179 - Dual Band HSDPA 42Mbps

Dual Band HSDPA 42Mbps allows data scheduling in the downlink on two different frequency bands

2 x 5 MHz

f1 f2

DB-HSDPA DL transmission options

U2100 U900

2 x 5 MHz

U2100

f1 f2

2 x 5 MHz

U900

f1 f2

f1

U2100

5 MHz f1

U900

5 MHz

DC-HSDPA DL transmission options

SC-HSDPA DL transmission options


RAN2179 - Dual Band HSDPA 42Mbps, cont. • Dual Band HSDPA schedules data for capable UE on two different frequency

bands in the downlink • The maximum peak rate is 42 Mbps when 64QAM is enabled and 15 codes are

available on both frequencies • MIMO is not supported simultaneously with Dual Band HSDPA • The BTS uses proportional fair scheduling

• Sector coverage and capacity is optimized by favoring the low-frequency band for cell-edge UEs and the high-frequency band for UEs closer to the BTS allowing Dual Band HSDPA to combine the gain of normal Dual Cell HSDPA scheduling as well as the benefits of a low frequency band for cell border users

• The carrier selection is based both on UE distance and current load of both uplink carriers

• By using the RAN2172: Multi-Band Load Balancing feature for carrier selection it is possible to define what layer Dual Band HSDPA or Dual Cell HSDPA the UE is directed to if it capable of supporting both features





Allowed RAB Combinations: • DB-HSDPA supports the same RAB combinations as DC-HSDPA

• 1 to 3 NRT Interactive or Background RABs mapped to HSPA

• DB-HSDPA is not allocated to a standalone SRB

• Simultaneous RT PS RABs or CS RABs are not allowed

• establishment triggers the release of DB-HSDPA

• NRT RAB can be mapped to:

• DL HS-DSCH and UL E-DCH

• SRB can be mapped to:

• DL HS-DSCH and UL E-DCH, or

• DL DCH and UL E-DCH, or

• DL DCH and UL DCH



• Full DL throughput of 42Mbps is achieved with the allocation of all 15 SF16 codes and using 64QAM

Allowed frequency band combinations:

Dual Band – Dual Cell Configuration

Uplink Band Downlink Band

1 2100 OR 900 2100 AND 900

2 1700 OR 1900 1700 AND 1900

3 2100 OR 850 2100 AND 850



This feature requires the following features: • RAN1906 – Dual Cell - HSDPA (and all features required by RAN1906 DC-HSDPA) • RAN1016/RAN1848 - Flexi BTS Multimode System Module (FSMC/FSMD/FSME) • BTS RF Modules - Have to be Release 2 or newer • RAN1226 - HSPA Peak Rate Upgrade for RNC196 and RNC450 • RAN1643 - HSDPA 64 QAM – in order to achieve at maximum data rate of 42 Mbps

instead of 21 Mbps

RAN2179 Dual Band HSDPA

42Mbps

RAN1016/1848 Flexi BTS Multimode

System Module FSMC/FSMD/FSME

RAN1226 HSPA Peak Rate

Upgrade for RNC196 and RNC450

BTS RF module must be Release 2

or newer RAN1643

HSDPA 64 QAM



Release Information RAS Release - RU40 RNC Release - RN7.0 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) mcRNC Release - mcRNC3.0 Flexi Direct Release - ADA5.0 BTS Release (Flexi) - WBTS8.0 BTS Release (Flexi 10) - FSMr3 WBTS8.0 BTS HW Release - Flexi Rel2/Flexi Rel3.0 NetAct - OSS5.4 CD set 3 SGSN – SG7.0 UE Release - 3GPP Rel-9



Activating Dual Band HSDPA 42Mbps: •Licence Feature Code – 2118 •Install a relevant RF module to the WBTS, load the software and configure the cells etc •To set the feature state to ON, use the following command:

• for IPA-RNC: ZW7M:FEA=2118:ON; • for mcRNC and I-HSPA Adapter: set license feature-mgmt id 0000002118 feature-admin-state on

•Set the DBandHSDPAEnabled parameter to Enabled

•Repeat the steps for all the required cells.


RAN 1907 Dual Cell HSDPA with MiMo 84Mbps


RAN1907 - Dual Cell HSDPA with MiMo 84Mbps

Combines DC-HSDPA, MIMO and 64QAM to achieve 84 Mbps peak rate in the DL




RAN1907 - Dual Cell HSDPA with MiMo 84Mbps, cont. • DC-HSDPA and MIMO are used simultaneously • 64QAM modulation can be used when radio conditions allow • UE reports 4 CQI/2 PCI values and 4 ACK/NACK indicators • Two values are reported on each carrier due to MIMO, and both carriers have

independent reporting to allow joint Dual Cell scheduling to be performed • MIMO scheduling on each carrier is independent • MIMO can be on dual stream mode on one carrier and on single stream mode on

other carrier • MIMO with 64QAM and Dual Cell are both specified in 3GPP Rel8, and

combining the two for 84 Mbps is allowed in Rel9 • Dual Cell operation is restricted to adjacent carriers only in Rel9 • No RT services are supported on DC-HSDPA • NRT RABs including nominal bit rate case can be mapped on DC HSDPA with

MIMO bearer • Due to very high throughput in DL, a minimum of 3 Mbps will be needed in UL




RAN1907 - Dual Cell HSDPA with MiMo 84Mbps, cont. • HSDPA and MiMo can be used with 16QAM modulation for both HSDPA

and MiMo – Maximum throughput = 56Mbps • DC HSDPA throughput without 64QAM modulation is 14Mbps +

14Mbps = 28Mbps • MiMo 2x2 DL throughput using Dual steam is 14Mbps + 14Mbps =

28Mbps • If HSPA 64QAM and MiMo 64QAM are used then the total throughput

can be 84Mbps • The WBTS configuration needs to be changed to support DC-HSDPA

with MiMo • The MiMo configuration needs to be added to the antenna configuration

• When the WBTScells are reconfigured a maximum one cell pair supporting DC-HSDPA with MiMo can be configured plus another 2 cells • 2 Cells will use ant1 and ant3 for DC-HSDPA + MiMo and this will use

all the power and antenna ports for ant1 and ant3 • 2 Cells will use ant5 and this will then use all the ports/power available

for ant5





• This feature requires the following features: • RAN1016: Flexi BTS Multimode System Module - FSMD • RAN1848: Flexi BTS Multimode System Module - FSME • RAN1642: MIMO 28 Mbps • RAN1643: HSDPA 64QAM • RAN1906: DC-HSDPA 42 Mbps • RAN1912: MIMO 42 Mbps • RAN1201: Fractional DPCH • RAN2261: Flexible User Plane Capacity in RNC196 and RNC450

RAN1907 DC HSDPA with MIMO 84Mbps

RAN1906 DC HSDPA

42Mbps

RAN1642 MIMO

28Mbps

RAN1643 HSDPA 64

QAM


RAN2261 RNC196/450 Flexible User

Plane capacity

RAN1912 MIMO 42Mbps



• Signalling: • The UE signals its combined DC-HSDPA with MIMO capability by inserting the Dualcell

MIMO support IE into the RRC Connection Request message • For a DC-HSDPA with MIMO capable cell, the NBAP Audit Response/Radio Resource

Indication message provides the capability of the BTS concerning the support of DC-HSDPA in the Bitmap Cell Capability Container IE (one or each potential serving HS-DSCH cell)

Cell-Capability-Container: '01000000 00000000 00000000 00000000 00000000 00000000 00000 000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000'B

Information Element Impacted Message or Information Element Info

Cell Capability Container NBAP: AUDIT RESPONSE NBAP: RESOURCE STATUS INDICATION

The value 1 of a bit indicates that the corresponding functionality is supported in a cell and value 0 indicates that the corresponding functionality is not supported in a cell. The second bitinforms about Multi Cell and MIMO Capability.

HS-DSCH FDD Secondary Serving Information NBAP: RADIO LINK RECONFIGURATION PREPARE

This IE is used for initial addition of Secondary Serving HS-DSCH information to a Node B Communication Context and defines the cell specific parameters for the secondary serving HS-DSCH Radio Link

HS-DSCH FDD Secondary Serving Information Response NBAP: RADIO LINK RECONFIGURATION READY

This IE provides information for Secondary Serving HS-DSCH that have been established or modified. It also provides additional HS-DSCH information determined within the Node B.



Manangement Data: Counter ID Counter name Measurement

M5000C424 SUM OF ACTIVE DC HSDPA MIMO USERS WITH TWO CARRIERS M5000 HSPA in WBTS

M5000C425 SUM OF ACTIVE DC HSDPA MIMO USERS WITH ONE CARRIER M5000 HSPA in WBTS

M5000C426 SUM OF CAPABLE DC HSDPA MIMO USERS M5000 HSPA in WBTS

M5000C427 TTI SCHEDULED DC HSDPA MIMO USER FOR PRIMARY CARRIER WITH ONE CARRIER DUAL STREAM

M5000 HSPA in WBTS

M5000C428 TTI SCHEDULED DC HSDPA MIMO USER FOR PRIMARY CARRIER WITH ONE CARRIER SINGLE STREAM

M5000 HSPA in WBTS

M5000C429 TTI SCHEDULED DC HSDPA MIMO USER FOR SECONDARY CARRIER WITH ONE CARRIER DUAL STREAM

M5000 HSPA in WBTS

M5000C430 TTI SCHEDULED DC HSDPA MIMO USER FOR SECONDARY CARRIER WITH ONE CARRIER SINGLE STREAM

M5000 HSPA in WBTS

M5000C431 TTI SCHEDULED DC HSDPA MIMO USER WITH BOTH CARRIER DUAL STREAM M5000 HSPA in WBTS

M5000C432 TTI SCHEDULED DC HSDPA MIMO USER WITH BOTH CARRIER DUAL AND SINGLE STREAM M5000 HSPA in WBTS

M5000C433 TTI SCHEDULED DC HSDPA MIMO USER WITH BOTH CARRIER SINGLE AND DUAL STREAM M5000 HSPA in WBTS

M5000C434 TTI SCHEDULED DC HSDPA MIMO USER WITH BOTH CARRIER SINGLE STREAM M5000 HSPA in WBTS




M1001C709 ACCESS STRATUM RELEASE INDICATOR RELEASE 9

M1001 - Service Level (RNC)

M1001C707) UE SUPPORT FOR HSDSCH CLASS 25 OR 26

M1001 - Service Level (RNC

M1001C708 UE SUPPORT FOR HSDSCH CLASS 27 OR 28

M1001 - Service Level (RNC)

M1022C223 CHANNEL SWITCH FROM DC-HSDPA TO SC-HSDPA SUCCESSFUL

M1022 - Packet Call (RNC)

M1022C224 CHANNEL SWITCH FROM SC-HSDPA TO DC-HSDPA SUCCESSFUL

M1022 - Packet Call (RNC)

• Licencing:

• Combination of 3 licenses: • RAN1906 - DC-HSDPA • RAN1642 - MIMO • RAN1643 - HSDPA 64QAM • RAN1201 – Fractional DPCH



Release Information RAS Release - RU40 RNC Release - RN7.0 IPA Platform - A14 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) mcRNC Release - mcRNC3.0 RNC Flexi Direct Release - ADA5.0 BTS Release (Flexi) - WBTS8.0 BTS release (Flexi Lite) - WBTS8.0 BTS Release (Flexi 10) - FSMr3 WBTS8.0 BTS HW Release - Flexi Rel2/Flexi Rel3.0 NetAct - OSS5.4 CD set 3 SGSN - SG8.0 UE Release - 3GPP Rel-9 Category 25 – 28



RAN1907: DC-HSDPA with MIMO 84 Mbps feature needs the following features to be activated before it can be enabled:

• HSDPA (HSDPAenabled WCEL parameter) • HSUPA (HSUPAenabled WCEL parameter) • RAN828: HSDPA Serving Cell Change (HSDPAMobility RNC parameter) • RAN829: HSDPA Soft/softer Handover for Associated DPCH (HSDPAMobility RNC parameter) • RAN1201: Fractional DPCH (FDPCHEnabled WCEL parameter) • RAN1258: HSDPA 14 Mbps per User (HSDPA14MbpsPerUser WBTS parameter) • RAN1638: Flexible RLC (FRLCEnabled RNC parameter) • RAN852: HSDPA 15 Codes (HSPDSCHCodeSet WCEL parameter), additionally required by

RAN1906: Dual-Cell HSDPA 42 Mbps • RAN1470: HSUPA 2 ms TTI (HSUPA2MSTTIEnabled WCEL parameter), additionally required by

RAN1642: MIMO 28 Mbps • RAN1642: MIMO 28 Mbps (MIMOEnabled parameter) • RAN1906: Dual-Cell HSDPA 42 Mbps (DCellHSDPAEnabled WCEL parameter)

Activating DC-HSDPA with MIMO 84Mbps:



•This feature can be activated by searching for the DCellHSDPAEnabled parameter, selecting DC-HSDPA and MIMO w/o 64QAM enabled or DC-HSDPA and MIMO with 64QAM enabled from the drop down menu and then selecting Apply


RAN2435 SRVCC from LTE and CSFB with HO


RAN2435 - SRVCC from LTE and CSFB with HO

LTE coverage

WCDMA coverage

UE moving from LTE coverage into WCDMA cell coverage area

Single Radio Voice Call Continuity (SRVCC) functionality enables continuity of voice service (VoIP) to the CS domain when changing from an LTE cell to a WCDMA cell.


RAN2435 - SRVCC from LTE and CSFB with HO, cont. Introduction to the feature • Single radio voice call continuity (SRVCC) from LTE function allows for voice over IP (VoIP) call handover

from the LTE to the WCDMA as a normal CS voice call. Also CS Fallback from LTE function is supported. • This is handled by the UTRAN as an incoming inter-system relocation request from LTE to WCDMA in

the CS domain • CS fallback (CSFB) is initiated in the LTE layer when the UE is in connected mode with a PS connection

allocated and a CS call needs to be established but VoIP is not supported in LTE. • This is handled as a PS ISHO from LTE • CS voice is set up in the WCDMA layer after inter-system • CS fallback allows LTE deployment as a data-only network

• Multi-RAB handovers (CS + PS RABs) from LTE to WCDMA are also supported, and all non-voice services are handed over to the PS domain

• Both SRVCC and CSFB are based on relocation procedures • The RNC requires that the UE history information is included in the RANAP RELOCATION REQUEST

message and that it indicates LTE as the originating system • The UE UTRAN capabilities must be included in the RANAP: RELOCATION REQUEST message or the

relocation attempt from the LTE is rejected • The Specification mode IE is set to Complete specification in the RRC HANDOVER TO UTRAN command

in case of inter-system handover (ISHO) from LTE • Complete specification means that complete RB/RL configuration information is sent to the UE instead of

preconfigured default configuration • During the SRVCC the multi-RAB combinations and transport channels combinations are the same as

currently supported in the RNC during ISHO.



RAN2435 SRVCC from LTE and

CSFB with HO

RAN2382/1016/1848/2262 Flexi BTS Multimode System

Module FSMC/FSMD/FSME/FSMF

RAN2067 LTE

Interworking

RAN2176 LTE PS

Handover

LTE872 SR Voice Call

Continuity

LTE736 CSFB to 3G via PSHO

LTE56 Inter-RAT Handover

RAN2717 (RU40) Smart LTE Layering

RAN2264 (RU50) Smart LTE Handover

• This feature requires the following features: • RAN2067 - LTE Interworking (supports Idle Mode, Cell_PCH and URA_PCH mobility between WCDMA and LTE) • RAN2176 - LTE PS Handover (supports incoming PS HOs from LTE to 3G). • RAN1016/1848 - Flexi System Module Release 2 or 3 (FSMC, FSMD, FSME, FSMF) • LTE872 - SR Voice Call Continuity (seamless voice call handover from LTE to WCDMA) • LTE736 - CSFB to 3G via PSHO (HO of ongoing packet call when voice service is requested in E-UTRAN which does

not support VoLTE) • LTE56 - Inter-RAT Handover

• Beneficial features: • RAN2717 Smart LTE Layering (moves active UEs to the LTE layer using RRC Connection Release with Redirection

command to LTE) • RAN2264 Smart LTE Handover (RU50) - allows handing over of UEs back to the LTE network after finishing a voice

call in WCDMA



Counter ID Counter name Measurement M1009C286 LTE CS HHO IN PREP FAIL DUE TO RNL L3 Relocation signalling (RNC) M1009C288 LTE CS HHO IN PREP REQ L3 Relocation signalling (RNC) M1009C289 LTE CS HHO IN PREP SUCC L3 Relocation signalling (RNC) M1009C290 LTE CS HHO IN PREP FAIL DUE TO TRANS L3 Relocation signalling (RNC) M1009C291 LTE CS HHO IN PREP FAIL DUE TO NAS L3 Relocation signalling (RNC) M1009C292 LTE CS HHO IN PREP FAIL DUE TO PROT L3 Relocation signalling (RNC) M1009C293 LTE CS HHO IN PREP FAIL DUE TO MISC L3 Relocation signalling (RNC) M1009C294 LTE CS HHO IN PREP FAIL DUE TO NON STAN L3 Relocation signalling (RNC) M1009C295 LTE CS HHO IN DETECT L3 Relocation signalling (RNC) M1009C296 LTE CS HHO IN COMPLETE L3 Relocation signalling (RNC) M1009C297 LTE CS FALLBACK IN PREP REQ L3 Relocation signalling (RNC) M1009C298 LTE CS FALLBACK IN PREP SUCC L3 Relocation signalling (RNC) M1009C299 LTE CS FALLBACK IN PREP FAIL DUE TO RNL L3 Relocation signalling (RNC) M1009C300 LTE CS FALLBACK IN PREP FAIL DUE TO TRANS L3 Relocation signalling (RNC) M1009C301 LTE CS FALLBACK IN PREP FAIL DUE TO NAS L3 Relocation signalling (RNC) M1009C302 LTE CS FALLBACK IN PREP FAIL DUE TO PROT L3 Relocation signalling (RNC) M1009C303 LTE CS FALLBACK IN PREP FAIL DUE TO MISC L3 Relocation signalling (RNC) M1009C304 LTE CS FALLBACK IN PREP FAIL DUE TO NON STAN L3 Relocation signalling (RNC) M1009C305 LTE CS FALLBACK IN DETECT L3 Relocation signalling (RNC) M1009C306 LTE CS FALLBACK IN COMPLETE L3 Relocation signalling (RNC) M1009C307 LTE CS FALLBACK HIGH PRIO IN PREP REQ L3 Relocation signalling (RNC) M1009C308 LTE CS FALLBACK HIGH PRIO IN PREP FAIL L3 Relocation signalling (RNC)

New counters:



Release Information RAS Release - RU40 RNC Release - RN7.0 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) mcRNC Release - mcRNC3.0 Flexi Direct Release - ADA5.0 BTS HW Release - Flexi Rel2/Flexi Rel3.0 NetAct - OSS5.4 CD set 3 UE Release - 3GPP Rel-8


RAN2435 - SRVCC from LTE and CSFB with HO Activating SRVCC from LTE and CSFB with HO: Software requirements:

Network element Main release MSS -DX -ATCA

Md 16.1 EP1 (DX) / Ma 16.1 (ATCA)

HLR -NT-HLR -DX-HLR

NT 5.0 EP1 (NT-HLR) / NT 6.0 (with IP-SM-GW support) / M16.1 (DX-HLR) / M16.1 (with IP-SM-GW support)

IMS -CFX-5000 (Sun) -CMS-8200 (ATCA)

IMS 8.2 EP2 (Sun) / IMS 9.2 (ATCA) [IMS mandatory forSRVCC, not for CSFB]

SGSN -DX -ATCA

SG8.0 DX CD3.1 (DX) /

GGSN Flexi ISN FI40 CD2 supports HSPA+ data rate up to 42 Mbit/s DL and up to 11 Mbit/s UL Flexi ISN FI50 needed for HSPA+ data rate up to 84 Mbit/s DL and up to 23 Mbit/s UL

MGW -IPA -ATCA

U5.0 EP2 (IPA) / Ui5.0 EP1 (ATCA)

eNB RL40

PCRF -PCS-5000

PCS6.3

MME NS2.2 N2 3.10-0 (SRVCC trialing capability only, P7 in March)

S/P GW FlexiNG NG2.1.1.2 Released

LTE RL40



Activating SRVCC from LTE and CSFB with HO: • SRVCC and CSFB features are complex End-to-end functionalities that require support from both Target and Source

RANs (LTE and WCDMA). Support from the Core Network is essential as well. • For SRVCC:

• Mobile Switching Center (MSC) needs to be upgraded to support SRVCC: Sv interface with MME and functionalities to receive the HO-requests from the MME,

• MME upgrade to Flexi NS 3.0 providing SRVCC (Rel. 9)

• NetAct OSS5.4 CD2 supporting SRVCC features.

• For CS Fallback: • Evolved Packet Core (EPC) must support CS inter-working for mobility management and paging

• SGs interface between MME and MSC is needed

• Interworking between SGSN and MME and PDN-GW via S3/S4 interfaces (or via pre-Rel.8 Gn interface).

Uu

Um

LTE-Uu

Iu-ps

Gb

S1-MME

Gn

Iu-cs

Gn

A

S1-US5/S8

S11

GnSGs

UE

E-UTRAN

GERAN

UTRAN

MME

SGSN

MSC

GGSN

PDN-GW

S-GW

Sv S3 S

4



Activating SRVCC from LTE and CSFB with HO: •Do not forget feature parameters on the LTE network also need to be enabled

• Licence Feature Code cRNC/mcRNC – 1756 Check cRNC ZW7I:FEA,LIM:FEA=XXXX,FSTATE=ON; Check mcRNC [root@CFPU-0(RNC-8) /root] # fsclish -c "show license feature all" | grep 000000XXXX (licence code must

be 10 digits)

•Configure a HOPL •Configure an ADJL towards the target eNB object

Before you start Restart of the RNC or the BTS is not required after activation of this feature. Feature RAN2435: SRVCC from LTE and CSFB with HO does not have an own licence, but the ISHO from LTE licence of the RAN2176: LTE PS Handover feature is required. This is a long-term capacity license. Capacity license refers to the number of cells. For information on managing licenses,



Set Parameter WCEL – IncomingLTEISHO to Enabled Set Parameter RNFC – SRVCCEnabled to Enabled



• Set Parameter RNFC - CSFBEnabled to Enabled



Extra Info: SDF- Service Data Flow- An aggregate set of packet flows that matches a set of filters. QCI – QoS Class Identifier – A parameter that is typically associated to packet forwarding/scheduling etc treatments. MME – Mobility Management Entity QCI values can be from 1 to 9. Since QCI is an 8 bit field it can have 255 values. Values 10 to 255 are operator specific. A bearer is always associated with a QCI. A UE can have a max of 11 bearers but QCI are from 1 to 9. Which means the QCI can be repeated for the bearers. Each bearer is also associated with TFT. Yes, even the default bearer can be assigned a TFT after the recent spec changes. TFT can have multiple packet filters resulting in multiple SDFs. Now the confusion is with this statement - “Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier (QCI).” Since two dedicated bearers can have same QCI the above statement leads to confusion. Reading the statement again makes sense. A bearer is associated with QCI and set of packet filters that will lead to multiple SDF’s. This means multiple SDF’s can be treated with same type of service but one SDF cannot be given multiple treatments. This also means that you cannot assign same packet filter to two dedicated bearers. Hence the above statement!


RAN2717 Smart LTE Layering


RAN2717 - – Smart LTE Layering

Active UEs are redirected from WCDMA to LTE

UE moving from WCDMA cell coverage area into LTE cell coverage area


RAN2717 - – Smart LTE Layering, cont.

The RAN2717: Smart LTE Layering feature introduces support for the redirection of active LTE-capable UE from WCDMA to LTE. In the early LTE-supporting UE, redirection is well-supported and thus preferred. LTE cell reselection for the UE in idle mode, Cell_PCH state, or URA_PCH state in the WCDMA layer has been enabled by the RAN2067: LTE Interworking feature. Smart LTE Layering introduces support for the redirection of LTE-capable UEs that are in Cell_DCH state

from WCDMA to LTE • A RRC CONNECTION RELEASE message with the redirection to LTE command is used to move the

active UE to the LTE layer • With this feature RRC Connection Release with Redirection command to LTE can be used for moving

active UEs to LTE These use cases allow LTE measurements after RRC connection release

• Cell_DCH to Cell_FACH, Cell_PCH or URA_PCH selection • Typically UEs select the LTE layer using the absolute priorities provided in the system information.

These priorities are used for cell selection only in idle mode i.e. Cell_PCH or URA_PCH states. As an example use case, laptop dongle frequently changing state between Cell_FACH and Cell_DCH can be efficiently commanded to the LTE layer using redirection

• LTE layer selection is faster when triggered with using the redirection procedure as compared to using the system information provided mechanism. It also forces the UE to check the availability of the LTE layer, and confirm that LTE can be used. Frequently transmitting dongles can also be moved to the LTE layer



•The following triggers cause redirection of a UE in Cell_DCH state to the LTE layer: • RRC state change away from Cell_DCH The network moves the UE away from Cell_DCH because of user inactivity or call

release Redirection to LTE is not triggered, if the state change is caused by a RAB release for

an emergency call • Channel-type switch from HSDPA to DCH for a UE using only PS

services The network moves the UE with only PS services from HSDPA to DCH because of, for

example, lack of cell resources or fading WCDMA coverage • CS call release Possibility for redirection to LTE is checked when CS RAB is released and the UE would

stay in CELL_DCH state (the UE has at least one active PS RAB after CS RAB release) The redirection to LTE is not triggered, if the released RAB is used for an emergency

call



This feature requires the following features: • RAN2067 – LTE Interworking

RAN2717 Smart LTE Layering

RAN 2067 LTE Interworking



Counter ID Counter name Measurement M1006C262 RRC CONN RELEASE LTE REDIR DUE TO INACTIVITY M1006 RRC signalling (RNC)

M1006C263 RRC CONN RELEASE LTE REDIR DUE TO CH TYPE SWITCH M1006 RRC signalling (RNC)

M1006C264 LTE REDIRECTIONS PREVENTED BY TIMER M1006 RRC signalling (RNC)

M1006C291 RRC CONN RELEASE LTE REDIR DUE TO CS CALL RELEASE M1006 RRC signalling (RNC)

New Counters:

Full name Abbreviated name Managed object Smart LTE Layering Enabled SmartLTELayeringEnabled WCEL Smart LTE Layering RSCP threshold SmartLTELayeringRSCP WCEL Smart LTE Layering NRT user amount threshold SmartLTELayeringUA WCEL Smart LTE Layering Target System Selection SmartLTELayeringTSysSel WCEL Smart LTE Layering service control SmartLTELayeringServ RNMOBI Timer for Smart LTE Layering Prevention SmartLTELayeringPrevT RNMOBI

New parameters:



Release Information RAS Release - RU40 RNC Release - RN7.0 OMS for WCDMA - OMS2.0 (RU40) OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5) mcRNC Release - mcRNC3.0 Flexi Direct Release - ADA5.0 NetAct - OSS5.4 CD set 3 UE Release - 3GPP Rel-8



Activating Smart LTE Layering : •Do not forget to also enable the feature parameters on the LTE network •Licence Feature Code – 3903 (license name: Redirection to LTE) •Create an ADJL towards the target LTE eNB cell •Set the WCEL parameter - SmartLTELayeringEnabled to the desired value:

1. RRC state change away from CELL_DCH state triggers the LTE layering. 2. RRC state change away from CELL_DCH state, or channel-type switch from HSPA or

from HSDPA (E-DCH/HS-DSCH --> DCH/DCH or DCH/HS-DSCH --DCH/DCH) to DCH triggers the LTE layering.

3. RRC state change away from CELL_DCH, or CS call release triggers the LTE layering.<for values 2, 3 it means that only one condition must be fullfilled to trigger the LTE layering

4. Any trigger mentioned above triggers the LTE layering



•Set the WCEL parameter - SmartLTELayeringRSCP. This is used to define CPICH RSCP threshold that must be exceeded before smart LTE layering can be done

•Set the WCEL parameter - SmartLTELayeringUA. This is used to define NRT (interactive, background) user amount threshold at cell level that must be exceeded before smart LTE layering can be done



• Set the WCEL parameter - SmartLTELayeringTSysSel. This indicates if the redirection is allowed to FDD LTE, TDD LTE or to both



•Set the RNMOBI parameter - SmartLTELayeringServ. This is used to define what services are allowed to be moved to LTE by the RAN2717: Smart LTE Layering feature



•Set the RNMOBI parameter - SmartLTELayeringPrevT. This is used to define a minimum time that the UE must be in WCDMA system before redirection to LTE can be done by the RAN2717: Smart LTE Layering feature





• RAN1877 End-user experienced DL Throughput • RAN2526 - 1 Hour RNC Release Software Upgrade • RAN2539 - OMS RNC Connectivity Increase • RAN2446 - Emergency Symptom Data Collection for IPA-RNC

RAN1805 – Event Triggered Symptom Data Collection for IPA-RNC


RAN1877 End-user experienced DL Throughput



Benefits • Allow to analyze most attractive for mobile operator end-user KPIs and monitor subscribers

throughput, such as QoS related monitoring, thereby: • OPEX saving via simplified NW monitoring and optimization, thanks to more detailed

network throughput OSS statistics instead of more complicated field tests. • Impact on memory capacity due to new PM counters for OMS and NetAct has been seen

as uncritical.

Brief Introduction • Better view of the end-user experienced DL throughput, achieved for each separate SPI

(Scheduling Priority Indicator) class and scheduler buffer throughput. • 4 new counters groups introduced at WBTS level • New KPIs/Reports for experienced end-user and the scheduler buffer DL throughput are

provided by NetAct Report through Cell Throughput (actually volume per SPI) with WBTS (M5002) counters re-usage.


RAN1877 End-user experienced DL Throughput, cont. This feature introduces new counters for end-user statistics for each SPI (scheduling priority indicator) class for HSDPA traffic.

The counters introduced by this feature are based on sampling and summing up every 100 seconds for each SPI class:

• number of active HSDPA users • number of samples for number of active HSDPA users • number of allocated HSDPA users • number of samples for number of allocated HSDPA users

Every counter group consists of 17 counters: • 16 counters for each SPI class • one counter for total values

For the detailed counter list, see Measurements and counters. Along with the RAN1877: End-used Experienced DL Throughput feature, new KPIs are proposed by Nokia Siemens Networks:

• reporting the average number of active HSDPA users, per each SPI class • reporting the average number of allocated HSDPA users, per each SPI class • reporting the average end-user experience throughput of active HSDPA users, per each SPI class • reporting the average end-user experience throughput of allocated HSDPA users, per each SPI class

The new KPIs are based on the introduced counters as well as on M5002C5 - M5002C20 (TOTAL ACKNOWLEDGED DATA IN MAC-HS PDUS FOR SPI 0...15) existing counters.



• There is no possibility to measure throughput in the cell experienced by the end user

• existing counters M5002C5 …

M5002C20 provide only data volume during the measurement period for each SPI class

• there is a possibility to watch throughput on a cell level from user’s side

• proper denominators to convert the data volumes into throughput values are provided

• the end user throughput can be measured separately for each SPI class


RAN1877 Activated

Two different sets denominators are provided for two purposes: 1) to get real end user experienced throughput, counting also over TTIs where user is not scheduled

but has data in the NodeB buffer 2) to get average thoughput counting only over TTIs where the user has been scheduled.



UE1

UE2

UE5

UE4

UE3

UE1

UE2

UE5

UE4

UE3


RAN1877 Activated



Recommendation: • Using together with RAN1262 QoS Aware HSPA Scheduling. The reason of that is that counters for Cell

Throughput measurements in WBTS are working under that feature. Thereby, activation of this feature will allow to generate End-User Experienced Throughput KPI Reports.

. Interdependencies: • RAN1877 does not require any other features for activation.

RAN1877 End-user experiended

DL Throughput

RAN1262 QoS Aware HSPA

Scheduling



NUMBER OF ALLOCATED

HSDPA USERS

NUMBER OF ACTIVE HSDPA

USERS

Counters for "number of users" updated on every 100ms of

successfully transferred data, per SPI class

Counters for "number of samples" for active and allocated HSDPA users

NUMBER OF SAMPLES FOR

NUMBER OF ALLOCATED

HSDPA USERS

NUMBER OF SAMPLES FOR

NUMBER OF ACTIVE HSDPA

USERS

Two groups of counters

17 counter for each category (16 per SPI + 1 for total value)

• The allocated user is a user receiving or waiting for data whether or not it is scheduled for him.

• The active user means a user who has data in the BTS buffer and the data is sent to the user.



TOTAL ACKNOWLEDGED DATA IN MAC-HS PDUS FOR SPI 0 [M5002C5]

TOTAL ACKNOWLEDGED DATA IN MAC-HS PDUS FOR SPI 15 [M5002C20]

Existing set of counters (RAN1262 QoS Aware HSPA Scheduling)

New set of KPI’s (per SPI per Cell)

Reporting the average number of active HSDPA users

Reporting the average number of allocated HSDPA users

Reporting the average end-user experience throughput of allocated HSDPA users

Reporting the average end-user experience throughput of active HSDPA users




M5002C58-M5002C73, M5002C74 ACTIVE HSDPA USERS IN SPI 0-15/ALL ACTIVE HSDPA USERS Cell Throughput in WBTS

M5002C75-M5002C90, M5002C91 SAMPLES FOR ACTIVE HSDPA USERS IN SPI 0-15/ SAMPLES FOR ALL ACTIVE HSDPA USERS Cell Throughput in WBTS

M5002C92-M5002C107, M5002C108 ALLOCATED HSDPA USERS IN SPI 0-15/ALL ALLOCATED HSDPA USERS Cell Throughput in WBTS

M5002C109-M5002C124, M5002C125 SAMPLES FOR ALLOCATED HSDPA USERS IN SPI 0-15/ SAMPLES FOR ALL ALLOCATED HSDPA USERS Cell Throughput in WBTS

New counters:


RAN1877 End-user experienced DL Throughput, cont. New counters: M5002C58-M5002C73, M5002C74

17 counters – (ACTIVE_HSDPA_SPI_0 to 15 and ACTIVE_HSDPA_ALL) Number of active HSDPA users per SPI class 0-15/The sum of all active HSDPA users. The number of active HSDPA users in SPI class 0-15 or for all SPI classes is sampled each 100 ms and the value is cumulated to this counter. The active user means a user who has data in the BTS buffer and the data is sent to the user. Number of active HSDPA users is sampled each 100ms and value is cumulated to the counter.

M5002C75-M5002C90, M5002C91

17 counters (SAMPLE_ACTIVE_HSDPA_SPI_0 to 15 and SAMPLE_ACTIVE_HSDPA_ALL) The number of samples for monitoring average number of active HSDPA users in SPI class 0-15/ The number of samples for monitoring average number of all active HSDPA users. The counter is incremented by one on each 100ms if at least one HSDPA user is active. The active user means a user who has data in the BTS buffer and the data is sent to the user. Number of active HSDPA users is sampled each 100ms and value is cumulated to the counter.

M5002C92-M5002C107, M5002C108 17 counters (ALLOC_HSDPA_SPI_0 to 15 and ALLOC_HSDPA_ALL) Number of allocated HSDPA users per SPI class 0-15/The sum of all allocated HSDPA users. The number of allocated HSDPA users in SPI class 0-15 or for all SPI classes is sampled each 100 ms and the value is cumulated to this counter. The allocated user is a user receiving or waiting for data whether or not it is scheduled for him. Number of active HSDPA users is sampled each 100ms and value is cumulated to the counter.

M5002C109-M5002C124, M5002C125

17 counters (SAMPLE_ALLOC_HSDPA_SPI_0 to 15 and SAMPLE_ALLOC_HSDPA_ALL) The number of samples for monitoring average number of allocated HSDPA users in SPI class 0-15/ The number of samples for monitoring average number of all allocated HSDPA users. The counter is incremented by one on each 100ms if at least one HSDPA user is active. The allocated user is a user receiving or waiting for data whether or not it is scheduled for him. Number of active HSDPA users is sampled each 100ms and value is cumulated to the counter.


RAN1877 End-user experienced DL Throughput New KPIs

Average number of active HSDPA users per SPI class 0:

DPA_SPI_0)_ACTIVE_HSsum(SAMPLEDPA_SPI_0)(ACTIVE_HS0 cl SPIHSDPA act Avg SUM

=

0]) SPI IN SHSDPA USER ACTIVE FOR ESsum([SAMPL0]) SPI IN SHSDPA USER Esum([ACTIV0 class SPIper usersHSDPA active of nº Avg =

Average number of active HSDPA users per SPI class 1:

1]) SPI IN SHSDPA USER ACTIVE FOR ESsum([SAMPL1]) SPI IN SHSDPA USER Esum([ACTIV1 class SPIper usersHSDPA active of nº Avg =

Average number of active HSDPA users:

S])HSDPA USER ACTIVE ALL FOR ESsum([SAMPLS])HSDPA USER ACTIVE ssum([ALL usersHSDPA active of nº Avg =


RAN1877 End-user experienced DL Throughput, cont. New KPIs: Avg act HSDPA SPI cl 0: Average number of active HSDPA users per SPI class 0 MEASUREMENT(S): Cell Throughput in WBTS Avg act HSDPA SPI cl X:( with X= 1 to 15 for all SPI classes) Average number of active HSDPA users per SPI class 1 MEASUREMENT(S): Cell Throughput in WBTS Avg act HSDPA users: Average number of active HSDPA users MEASUREMENT(S): Cell Throughput in WBTS



AVERAGE NUMBER OF ALLOCATED HSDPA USERS PER SPI CLASS 0:

0]) SPI IN SHSDPA USER Esum([ACTIV 10)*8*0] SPI FOR PDUS HS-MAC INDATA EDACKNOWLEDG sum([TOTAL0 SPIHSDPA act thr Avg =

Average end-user experience throughput of active HSDPA users per SPI class 0

_0)_HSDPA_SPIsum(ACTIVE 10)*8*0A_ACK_SPI_sum(HS_DAT0 SPIHSDPA act thr Avg =

PA_SPI_0)_ALLOC_HSDsum(SAMPLE 0)HSDPA_SPI_sum(ALLOC_0 SPIper usersHSDPA allocated OF Nº Avg =


RAN1877 End-user experienced DL Throughput, cont. New KPIs: Avg nº of allocated HSDPA users per SPI class X: (with X = 0 to 15 for the SPI classes 0 to 15)

Average number of allocated HSDPA users. Allocated means that user is receiving data or user is waiting for data regardless of the data being scheduled for the user.

Avg thr act HSDPA SPI 0:

Average end-user experience throughput of active HSDPA users per SPI class 0 MEASUREMENT(S): Cell Throughput in WBTS

Avg thr act HSDPA SPI X: (with X = 1 to 15 for the SPI classes 1 to 15)

Average end-user experience throughput of active HSDPA users per SPI class X MEASUREMENT(S): Cell Throughput in WBTS



0]) SPI IN SHSDPA USER ATEDsum([ALLOC 10)*8*0] SPI FOR PDUS HS-MAC INDATA EDACKNOWLEDG sum([TOTAL 0 SPI DL alloc thr Avg =

Average end-user experience throughput of allocated HSDPA users per SPI class 0

0)HSDPA_SPI_sum(ALLOC_10)*8*0A_ACK_SPI_sum(HS_DAT 0 SPI DL alloc thr Avg =

Average end-user experience throughput of allocated HSDPA users

S])HSDPA USER ALLOCATED sum([ALL10)*8*DATA]HSDPA NALsum([ORIGI usrsHSDPA alloc thr Avg =


RAN1877 End-user experienced DL Throughput, cont. New KPIs: Avg thr alloc DL SPI 0:

Average end-user experience throughput of allocated HSDPA users per SPI class 0 Avg thr alloc DL SPI X: (with X = 1 to 15 for the SPI classes 1 to 15)

Average end-user experience throughput of allocated HSDPA users per SPI class X HS_DATA_ACK_SPI_0: (kbyte)

Number of octets of acknowledged MAC-hs PDUs for SPI 0. When a MAC-d PDU is positively acknowledged for this SPI class.

HS_DATA_ACK_SPI_X: (kbyte) (with X = 1 to 15 for the SPI classes 1 to 15) Number of octets of acknowledged MAC-hs PDUs for SPI X. When a MAC-d PDU is positively acknowledged for this SPI class.

ALLOC_HSDPA_SPI_X: (with X = 0 to 15 for the SPI classes 0 to 15) The sum of allocated HSDPA users in SPI X class. The allocated user is a user receiving or waiting for data whether or not it is scheduled for him. The number of allocated HSDPA users in SPI class X is sampled each 100ms and the value is cumulated to this counter. SAMPLING INTERVAL: 100ms

Avg thr alloc HSDPA usrs: (kbit/s) Average end-user experience throughput of allocated HSDPA users



• Restart of the RNC or the BTS is not required after the activation of this feature.

This procedure does not cause downtime and it can be activated at any time of the day.

Activation

• This feature belongs to application software (ASW) and is under license key management.

• The counters are optional and controlled by RNC license. • License key installed on RNC. OMS reads the RNC license and based on that

hides or shows the counters in the OMS EM GUI.

Licensing


RAN1877 End-user experienced DL Throughput, cont. HSDPA_ORIG_DATA: (kbyte)

Total amount of HSDPA original data (first transmissions) sent on MAC-hs/ehs PDUs. This counter includes legacy single carrier, Multi-Carrier and MIMO HSDPA data The counter is updated when the MAC-hs/ehs PDU is sent to the air (first transmission of the PDU only).

ALLOC_HSDPA_ALL: The sum of all allocated HSDPA users. The allocated user is a user receiving or waiting for data whether or not it is scheduled for him The number of all allocated HSDPA users is sampled each 100ms and the value is cumulated to this counter

These are MEASUREMENT(S): Cell Throughput in WBTS



WCDMA Release RU40 I-HSPA System I-HSPA Rel.5 BTS (Flexi) WTBS8.0 NetAct NetAct8 HW Requirements None License Control Long-term ON/OFF Licence Control in NE RNC LK


RAN1877 End-user experienced DL Throughput feature does not require any specific RNC or mcRNC HW and SW


RAN2526 1 Hour RNC Release Software Upgrade


RAN2526 - 1 Hour RNC Release Software Upgrade

IPA RNC Release upgrade time is reduced

cRNC

1 Hour Release Software Upgrade Time

Preparation

Aftermath

Upgrade



• The SW upgrade procedure is based on the Preparation, Upgrade, and Aftermath concept • The SW upgrade procedure consists of 3 phases: • SW Upgrade • Aftermath

Preparation • Not traffic and service affecting • Manual pre checks e.g. disk space,

locked files, stop command calendar jobs etc.

• Making a fallback of the running package

• Downloading the software • Preparing the new software • Checking licences and installing

licences • Creating the new package

Upgrade • Traffic and service affecting • Macro pre checks • Data conversion and unit preloading • Boot SW upgrade • New SW activation including reboot • Remove temp files • Change state of package from NW

to BU

Aftermath • Not traffic and service affecting • Manual post checks e.g. star

tcommand calendar jobs, start measurements etc.

• KPI monitoring • New feature activation





Release Information RAS Release - RU40 RNC Release - RN7.0 IPA Platform - A14 OMS for WCDMA - OMS2.0 (RU40) RNC Flexi Platform – FP-6 Cougar

Activating 1 Hour RNC Release Software Upgrade : • This is BSW (Basic Software) and requires no activation


RAN2539 OMS RNC Connectivity Increase


RAN2539 - OMS RNC Connectivity Increase

HP Proliant DL360 Gen.8

Simultaneously connected RNCs is increased from 10 to 20


RAN2539 - OMS RNC Connectivity Increase, cont.

• The number of RNCs that can be connected to a standalone OMS is increased for 10 to 20

• The OMS capacity is not increased • Topology browser 30 • NE Parameter Editor 30 • Radio Network Measurement Management 10 • Radio Network Measurement Presentation GUI 20 • NE threshold management 20 • Radio Network online-monitoring 20 • Fault Management 30 • Active sessions 30 • Secure MMI-window 30 • Parameter tool 30 • Putty 30 • Log viewer 30 • SW version viewer 30 • BTS Connection Resources UI 30

• New GOMS hardware HP Proliant DL360 Gen.8 is required • RAN2701 included in a later release will increase the number of users


RAN2539 - OMS RNC Connectivity Increase

Release Information RAS Release - RU40 OMS for WCDMA - OMS2.0 (RU40) NetAct – OSS5.4 CD set 3

Activating OMS RNC Connectivity Increase : • This is BSW (Basic Software) and requires no activation


RAN2446 - Emergency Symptom Data Collection for IPA-RNC RAN1805 – Event Triggered Symptom Data Collection for IPA-RNC



Operator is able to initiate emergency symptom data collection from an IPA RNC using an MML command or triggered from OMS

Flexi WBTS

RAN2199

IPA RNC

RAN2446 (RU40)

mcRNC RAN2601

OMS

RAN1873 (RU30)

RAN1805 (RU40)

Symptom data Manual trigger

Planned

RU40

Planned

NetAct

Alarm enrichment

OSS1071

RAN2229

Planned



• Troubleshooting logs (symptom data) collection from the IPA-RNC can be performed using one command

• The user Nemuadmin can trigger log collection from the OMS by default from the command line interface

• If the log collection needs to be triggered by the root user from the command line interface then the root user needs to be added to _nokNELogManager group in the OMS

• Emergency profile collection is supported and used when fast operator action is required to restore the service e.g. RNC reset

• Currently symptom data information is obtained with command-line-based tools such as the TN38 log collection macro

• This is tedious and time consuming and is usually omitted during troubleshooting

• When triggered by MML or from OMS the IPA RNC will perform the emergency symptom data collection automatically



• The troubleshooting report package consists of compressed file and includes:

• All relevant RNC system and process logs • RNC HW & SW configuration • Active alarms and relevant parts of alarm history

• The symptoms are collected into a file that can then be added to the trouble ticket to help problem solving

• There is an alarm to indicate the receipt of troubleshooting data. • System collection and upload failure is indicated by a defined alarm • When the log collection is triggered the logs are also forwarded to the

OMS • The log file is stored on the RNC hard disk at eclipse/var/symptom with a

file name SYMP<sequential_number>.ZIP e.g. SYMP0001.ZIPand automatically forwarded to the OMS



• The logs are stored in the OMS at /var/opt/OMSftproot/NE/ TroubleshootingData/. with a file name TSUPL_RNC_<RNC_ID>.<date-time>.zip e.g.TSUPL_RNC_00009.20110810103000.zip

• The EMERG profile configuration file RNCEMERG.XML can be found at SHADOWS/RUNNING/LFILES



This feature requires the following features: • OMS requires feature RAN1873

RAN2446 Emergency Symptom Data Collection for IPA-RNC

(BSW)

RAN 1873 OMS

Troubleshooting Data Collection

(BSW)



Release Information

RAS Release - RU40 RNC Release - RN7.0 IPA Platform – A14 OMS for WCDMA - OMS2.0 (RU40) mcRNC Release – planned for a later release Flexi Direct Release - planned for a later release



Activating Emergency Symptom Data Collection for IPA-RNC : • Create the SOKERI user account and attach it to the PROFILE profile

• ZIAH:SOKERI:PROFILE:; • Trigger the log collection using the Service Terminal LCKMAN Log

Collection Extension: • ZDDS:<active_OMU>, <omu_index>; • LP:<number>,LCK; e.g. LP:1,LCK; • 1 • S:E (trigger log collection) • PF (check the progress) • T:<value> sets the time for automatic transfer to the GOMS. Value = 0

disables automatic file transfer • The logs are stored in the RNC at eclipse/var/symptom with a name like

SYMP0001.ZIP



• The log collection can also be triggered from the OMS. • To do this you will first need to add root user to the _nokNELogManage

user group • fsgpasswd –a root _nokNELogManage

• Now the log collection can be triggered from the GOMS CLI using the command: • zcollectNELogs –n <ne_id> -p RNCEMERG (Ne-id is the NE-ID from

RUOSTEQX) • zcollectNELogs –n <ne_id> -f -p RNCEMERG (provides feedback on

CLI screen) • The logs are stored in the GOMS at

/var/opt/OMSftproot/NE/TroubleshootingData/. with a file name TSUPL_RNC_<RNC_ID>.<date-time>.zip e.g.TSUPL_RNC_00009.20110810103000.zip



• Event Triggered Symptom Data Collection is active by default but will only start to work when the SOKERI user has been configured in the RNC

• In this case the data collection is triggered by certain events • The feature and its main parameters are controlled by PRFILE class2

parameters 1814,1819 and 1818 • The following events triggers are configured by default 1001 UNIT RESTARTED 1014 PROCESSOR LOAD RATE ALARM LIMIT EXCEEDED 1078 PROCESS EXCEPTION 1143 AMOUNT OF FREE MEMORY REDUCED 1144 FREE BUFFER HEADERS EXHAUSTING 1147 MESSAGE QUEUE OVERFLOW 1239 DSP SUPERVISION FAILURE 1269 AAL5 FRAME CORRUPTED 1598 UNIT FOUND FAULTY BY ALARM SYSTEM 2693 ACTIVE UNIT FAULTY



• Alarm 0186 - New Log File Generated is raised Files stored in RNC at /ASWDIR/TRSLOG/

• Files are stored in GOMS at /var/opt/OMSftproot/NE/TroubleshootingData • The Event Triggered Log Collection profile configuration file RNCSTAND.XML can

be found at SHADOWS/RUNNING/LFILES



Activating Event Triggered Symptom Data Collection for IPA-RNC : • Create the SOKERI user account and attach it to the PROFILE profile

• ZIAH:SOKERI:PROFILE:; • Enable/Disable the feature with PRFILE parameter 1814

• ZWOI:2,1814 –0001 = Enabled / 0000 = Disabled • ZWOC:2,1814,1; - enables Event Triggered Symptom Data Collection • To prevent alarm 0186 from being raised use the PRFILE value 0002 ZWOC:2,1814,2;

• Check and increase the the folder space (ASWDIR/TRSLOG/) using commands ZWOI:2,1819; ZWOC:2,1819,<size (H)> • Check and configure the automatic transfer of the zip files to OMS using the

command ZWOI:2,1818; - Enabled = 0001 / 0000 = Disabled ZWOC:2,1818,1;





• RAN2296 Transport sub-Module "FTIF" Eth+E1/Ta/JT1 for Flexi Multiradio SM


RAN2296 Transport sub-Module "FTIF" Eth+E1/Ta/JT1 for Flexi Multiradio SM


RAN2296 FTIF Eth + E1/T1/JT1 for Flexi Multiradio SM

FTIF can only be used with FSMF, FSMG and FSML system modules

FTIF enhances the connectivity and transport mode options of Flexi Multiradio 10 BTS.

2 x Combo Ports, each operating as: -100/1000Base-T

-or -- optical SFP

4 x "RJ48C-style" ports, each provides 2 x E1/T1/JT1


RAN2296 FTIF Eth + E1/T1/JT1 for Flexi Multiradio SM, cont. Summary

FTIF Transport Sub-Module supports - Up to 8x E1/T1/JT1 interfaces and - 2x Combo Ports (2x optical via separate SFP, 2x electrical). Up to two ports can be used at the same time. Benefits for the Customer FTIF enhances the connectivity and transport mode options of Flexi Multiradio 10 BTS

Connectivity - Up to 8x E1/T1/JT1 interfaces to interconnect with TDM based transport networks or equipmenet on site - Up to 2 additional Ethernet ports via optical/electrical combo ports for chaining or collocation - True zero footprint support for FlexiPacket Radio via Power + Ethernet feature on both electrical Ethernet ports

Transport modes - ATM Iub, Dual Iub and IP Iub over ML-PPP - Media conversion for chained or collocated BTS (CESoPSN, ML-PPP)

Functional description Optional Outdoor Transport Sub-Module FTIF extends capabilities of Outdoor Flexi Multiradio 10 System Module FSMF by: • 2 x Combo Ports supporting following combinations:

– 2 x 100/1000Base-T or – 2 x optional optical SFP or – 1 x 100/1000Base-T and 1 x optional optical SFP

• Flexi Multiradio System Module with FTIF supports QoS aware Ethernet Switching across up to 3 interfaces

• 8 x E1/T1/JT1 (twisted pair) on 4 x “RJ48C-style” ports; coaxial connectivity can be provided via baluns


RAN2296 FTIF Eth + E1/T1/JT1 for Flexi Multiradio System Module

FTIF enhances the connectivity and transport mode options of Flexi Multiradio 10 BTS Connectivity:

• 8x E1/T1/JT1 interfaces to interconnect with TDM based transport networks or equipment on site

• 2 additional Ethernet ports via optical/electrical combo ports for chaining or collocation

• True zero footprint support for FlexiPacket Radio via Power + Ethernet feature on both electrical Ethernet ports

• Transport modes: • ATM Iub, Dual Iub and IP Iub over ML-PPP • Media conversion for chained or collocated BTS (CESoPSN, ML-PPP)


RAN2296 FTIF Eth + E1/T1/JT1 for Flexi Multiradio System Module, cont. FTIF is required

- for ATM Iub, Dual Iub and IP Iub over ML-PPP - if collocation (CESoPSN, ML-PPP) or synchronization shall include TDM - if more/other Ethernet interfaces are required than available on Multiradio System Module - if Synchronization Hub function based on Synchronous Ethernet input or output shall be used

Flexi Multiradio System Module integrated Transport and FTIF build a single logical Transport node Each "RJ48C-Style" port offers 2 E1/T1/JT1 interfaces which are both accessible via one Flexi Outdoor cable FTCY. Also the existing cables FTCB, FTCV, FTCX can be used but with the consequence that just 1 PDH interface per RJ48C port is accessible (interfaces 1,2,3 and 4). Current Implementation FTIF is an optional enhancement to Flexi Multiradio 10 System Module's integrated transport functionality. Interdependencies between Features Depends on feature "RAN2262 Flexi Multimode System Modules, FSMF and FSMG " Operational Aspects HW Requirements FTIF can only be installed to Flexi Multimode System Modules FSMF and FSMG. BTS Transport HW Flexi Multiradio System Module with FTIF Supplementary Internal Information Note that the PDH interface numbering is 1/5; 2/6; 3/7; 4/8. • CESoPSN = Circuit Emulated Services over Packet Switched Networks e.g. Pseudo Wire


RAN2296 FTIF Eth + E1/T1/JT1 for Flexi Multiradio System Module

BSW/ASW HW RAS RELEASE RU40 BTS RELEASE WN 8.0 BTS HARDWARE FLEXI REL.3 NETACT RELEASE OSS5.4 CD Set 3 RNC RELEASE N/A mcRNC RELEASE N/A SGSN RELEASE N/A IHSPA RELEASE N/A LICENCING N/A






• RAN2117 RNC2600 Co-Siting with Multicontroller RNC

• RAN2240 mcRNC Flexible Dimensioning up to 50Gbps HW Release 2

• RAN2262 Flexi Multiradio Sstem Modules, FSMF and FBBA extension module

• RAN2317 240W Multireadio remote RF



• RAN2157 Flexi Lite BTS 2100 ***

• RRH FHDB 60W+60W

• RAN2489 - Carrier Bandwidth 3.8MHz

• RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices

• RAN2591 – Selective BTS Resource Re-Balancing in mcRNC


RAN2117 RNC2600 Co-Siting with Multicontroller RNC


RAN2117 - RNC2600 Co-siting with mcRNC

• Capacity of the installed RNC2600 increases • Enables peak rates higher than 84 Mbps for the RNC2600 • Provides improved end-user experience due to higher HSPA peak

rate support from the network


RAN2117 - RNC2600 Co-siting with mcRNC, cont. • The idea of the feature is that cRNC can assign certain UEs to be processed by mcRNC.

The assignment is only when cRNC is the SRNC for the UE and static, i.e. UEs are not switched between RNCs in connected state. Assignment lasts until UE goes to idle state or is relocated from cRNC.There is no co-siting when cRNC is the drift RNC.

• This feature is only supported using Rel2 mcRNC HW • RNC2600 supports co-siting using all valid step configurations • This feature is currently only for use in networks where all the interfaces except the Iu-PS are

ATM/IP based • Full ATM RNC2600s are not supported • Cositing in RU40 is "inter-RNC UE processing within an RNC cluster” • The RNC2600 is connected to the mcRNC through a proprietary interface called the RNC-cl

interface and creates an RNC cluster • mcRNC S1 hardware configuration is used • RNC’s are geographically co-located and installed in the RNC site and inter connected by IP

interfaces • RNC co-siting is transparent to the core network elements. • Co-siting is not applied when the RNC2600 is the drift RNC • RNC2600 controls the BTSs common channel signaling and core network signalling



RNC2600

• BTS Control • Core signalling • EU processing

mcRNC

• EU processing


RAN2117 - RNC2600 Co-siting with mcRNC, cont.

• Only the RNC2600 has an RNS and is therefore the controlling RNC and controls the cells • The cRNC is visible to the CN, neighbouring RNC’s and the underlying node-

B’s as the CP physical termination end point • The mcRNC is visible only as an UP IP end point • This is possible by usage of site routers on the Iu side and the Iub side of the

RNC’s to which both the cRNC and mcRNC connect. • During the RRC connection setup phase, the RNC2600 assigns UEs to itself or to

the mcRNC • The assignment only happens when the RNC2600 is the SRNC for the UE • The UEs are not switched between RNCs • Assignments last until the UE goes to idle state or the UE is relocated from

RNC2600 • If a certain UE connected through ATM is being processed in mcRNC, all UP

traffic goes via RNC-cl interface





• UE-specific signaling and user plane resources are always allocated from the same HW platform

• UEs capable of HSPA peak rates higher than 84 Mbps are allocated to the mcRNC

• The load is shared between RNC2600 and mcRNC • The mcRNC has its own IP interfaces towards Iub, Iu-cs, Iur, and Iu-ps • If ATM is used in Iub, Iu-cs, or Iur then the RNC2600 acts as the ATM

gateway between the ATM based Iub, Iu-cs, or Iur interface and the mcRNC IP interfaces

• The Iu-ps interface is always IP based when the RNC co-sitting feature is used

• The operability of both RNCs in the cluster is kept independent for simplicity and to make it possible to use the existing O&M methods and tools in the respective RNCs

• Both RNCs connect to the same OMS using independent BTSOM interfaces



cRNC mcRNC

DMCU

CFPU USPU

0 1

NP2GE ATM/IP IFs Transport Network

ICSU

EIPU RNC-cl

OMU OMU

BTSOM UE CP

UE UP

CCH UP

UE UP

EIPU

No CSPUs - all cell-related CP and UP functions are handled in cRNC

Transport Network

RSMU Top CP

UE CP

TOP CP (mainly in ICSU) • cell-specific CP functionalities

UE CP (in ICSU) • UE-specific CP functionalities

UE UP (DMCU) • UE-specific UP functionalities

CCH UP (DMCU) • NodeB-specific UP functionalities • Common channels handling

UE CP (in USCP) • UE-specific CP functionalities

UE UP (in USUP) • UE-specific CP functionalities

OMS



• There is a BTSOM interface used between the RNCs • At system level the OMS hides most of the cosite details from NetAct • NetAct is aware of the of co-sited RNC topology • OMS provides the means to configure and activate/deactivate RNC co-siting • OMS does some processing, separation, and filtering of PM data from the independent RNCs to hide the

co-site details • The RNC-cl interface and the BTSOM interface between the RNC2600 and the mcRNC has no visibility to

the RAN • The RNC-cl interface is visible to the OMS • The OMS can be used to configure the RNC-cl interface.

cRNC has to act as ATM gateway to mcRNC when ATM transport is being used. • EIPUs are connected directly to NPGEs without any external devices • Four NP2GE cards configured in protected (NPGEP) should be used at the cRNC side • Eight 1GE ports (4 per each BCN) should be used at the mcRNC side • The theoretical maximum capacity is 3.2 Gbps (due to NPGE backplane capacity) • RAN2440 “IP Fast Rerouting” is required

• In case of failure a BFD triggered switchover for NPGEP from WO to SP occurs • VLANs are used also to provide a logical traffic separation through the RNC-cl interface • No encryption method is taken into consideration for the new interface in RU40



•When RAN1874: Automatic OMS resiliency is used • If the serving (primary) OMS fails or if the connection between network

elements (RNC/BTS) and the serving OMS fails, the network elements under the serving OMS automatically connect to the secondary OMS

• For RNC2600 co-siting with mcRNC both RNCs will attempt to move under the same OMS

•When RAN1913: HS Cell FACH is used • HSPA is used in Cell FACH state and therefore more users can be supported

in Cell FACH state and smooth data transmission is provided for users not requiring large data volumes

• For UEs cosited on the mcRNC side that are in HS Cell FACH state, the user data path uses L2-L2 transparent communication between the mac-d entities in the mcRNC and mac-c entities in the RNC2600



• Release Information:

– RAS Release - RU40 – RNC Release - RN7.0 – IPA Platform - A14 – OMS for WCDMA - OMS2.0 (RU40) – mcRNC Release - mcRNC3.0 RNC – NetAct - OSS5.4 CD set 3


RAN2240 mcRNC HW Release 2 Support2


RAN2240: mcRNC Rel2 HW Support

•Improving the capacity and connectivity by

• Introducing a new processor version add-in card

• 8x8 G memory per module • Approx 2 times more capacity

expected •Supprting up to 8 module configuration •10GE network interface supported



the mcRNC is able to support higher capacity due to processor evolution and software optimization


RAN2240: mcRNC Rel2 HW Support, cont.

BMPP2-B Octeon2 Unit • BMPP2-B BCN Multi-Processor Card gen. 2 is a general purpose

processing unit to be used in the BCN platform • The processor type is the Octeon II (CN6880) made by Cavium • The OCTEON II is a 64 bit processor providing 48GHz of computing

power on a single chip across 32-cores • It performs various data plane and control plane processing tasks in a

number of applications • BMPP2-B Add-in Card supports and utilizes the interfaces that the BCN

motherboard infrastructure provides • 2x XAUI, 2x PCI Express, UART, USB • Supports up to 4 x 8Gbyte DDR3 DIMM memories.

• In addition to a processor block the Add-in Card has an MMC (Module Management Controller) for HW management tasks and a power supply block for generating a variety of supply voltages required on board



Network interfaces /Inter-module interfaces7 x 1 GE/10 GE (SFP+)1 x 1 GE (SFP)

Network interfaces 2 x 10 GE (SFP+)10 x 1 GE (SFP)USB 2.0 (Type B, target)

SAS cross-connect

LMP serial port(RS-232)

NE management interface2 x 1GE (SFP)

Module management interface1 x 10/100M/1GE (RJ45)

Alarm input interface8 x voltage input (RJ45)

Synchronization interface2 x in/out (RJ45)

Indicator LEDs

Reset2 x AMC bay

eSW/FW update interface2 x USB 2.0 (Type A, host)


RAN2240: mcRNC Rel2 HW Support, cont.

The BCN-B module front panel contains the following interfaces: • 7 x 10 GigE (SFP+) interfaces for external cabling and inter-module cabling • 2 x 10 GigE (SFP+) and ten 1 GigE (SFP) interfaces for external cabling • 2 x additional 1 GigE (SFP) interfaces provide access to add-in card slots 1 and 8

for network element management purposes (SSH connection) • 1 x 1 GigE (1000Base-T) interface for local hardware management and

debugging purposes (MGMT port) • 2 x USB 2.0 interfaces for software downloading (typically during commissioning) • A direct RS232 interface to the local management processor (LMP) for debugging

purposes • A USB 2.0 slave port for software debugging purposes • A SAS connector for hard disk cross-connecting between two BCN modules • 2 x RJ 45 connectors for eight external voltage-sensitive alarm inputs with 1 mA

pull-up load • 2 x external synchronization interfaces (E1, T1, JT1, 1.544 MHz, 2.048 MHz)



• Due to the fast evolution of processor chips it is now possible to greatly enhance the operation of the mcRNC by introducing a new HW release to the market

• This new hardware is known as mcRNC Release 2 hardware. • A new hardware platform is introduced – BCN-B • New processor units are introduced BCMPP-B also known as Octeon2

Processor units • These units are greatly improved from the first Octeon+ units

Cavium Octeon+ CN5650 64 bit 12 cores 800MHz 4 x 2MB DDR DIMS

Cavium Octeon+ CN6680 64 bit 32 cores 48GHz 4 x 8MB DDR DIMS

VS



• A special 1 GE interface, the “trace port”, is used for providing a connection to an external traffic tracing server

• The trace port is used for port mirroring and allows the mirroring of any port connected to the HiGig virtual backplane to the trace port

7 x 10Gb SFP+ Ports for interbox connectivity.

1 x 1Gb SFP Port for tracing/port mirroring

2 x 10 Gb SFP+ Ports for external connections to NEs

10 x 1Gb SFP Ports for external connections to NEs



•External Connectivity: • Maximum connectivity is 20Gbps • 1 GE and 10GE can be used simultaneously • 10 x 1 GE + 1 x 10GE • 2 x 10GE

• Supported transmission types are: • Copper • Single mode optic fiber • Multimode optic fiber

S3-B2

S1-B2

Module #4

Backbone Network

DCN

NetAct

OMS

Module #1 Module #2

Module #3



• Release2 HW in RU40 supports S1 and S3 configurations



mcRNC capacity targets with BCN-A1 HW in RU40 (mcRNC HW Rel1)

Configuration ID S1-A1 S5-A1 NE level performance Number of subscribers per RNC coverage area 340000 1380000 AMR Busy Hour Call Attempts 340000 1380000 PS BHCA (HSPA) 428000 1712000 NAS Busy hour call attempts on top of maximum call capacity 1265650 5137050 AMR Erlangs 8500 34500 AMR Erlangs (including soft handover) 11900 48300 NE level capacity Iub max total UP throughput (CS+PS, FP, UL+DL)/ Mbps 1290 5190 Iub max total HSDPA UP throughput (CS+PS, FP, DL) 910 3660 Iub max total HSDPA UP throughput (CS+PS, FP, UL) 380 1530 Connectivity Max number of cells 1410 3110 Max number of BTS sites 470 1037 Max number of RRC connected UE's 195000 780000



mcRNC capacity targets with BCN-B2 HW in RU40 ( mcRNC HW Rel2)

Configuration ID S1-B2 S3-B2 NE level performance Number of subscribers per RNC coverage area 760000 2140000 AMR Busy Hour Call Attempts 760000 2140000 PS BHCA (HSPA) 555000 1573000 NAS Busy hour call attempts on top of maximum call capacity 2829100 7966150 AMR Erlangs 19000 53500 AMR Erlangs (including soft handover) 26600 74900 NE level capacity Iub max total UP throughput (CS+PS, FP, UL+DL)/ Mbps 2640 7520 Iub max total HSDPA UP throughput (CS+PS, FP, DL) 1850 5260 Iub max total HSDPA UP throughput (CS+PS, FP, UL) 790 2260 Connectivity

Max number of cells 2600 6600 Max number of BTS sites 520 1320 Max number of RRC connected UE's 352000 1000000



• Release Information: – RAS Release - RU40 – mcRNC Release - mcRNC3.0 – RNC FlexiPlatform - FP6-Cougar


RAN2262 Flexi Multiradio System Modules



Rel3 Flexi Multiradio System modules for Flexi WBTS’s

FTxx, optional transport sub-module

3U Casing with Flexi Rel3 modules

FSMF / FSMG comes with casing and fan sub-assembly

FPFD, optional PDU in 3U casing

FBBA/FBBB, optional

FPFC, optional stand alone PDU


RAN2262 Flexi Multiradio System Modules, cont. Summary New Flexi Multiradio System Module (FSM) platform is introduced. It has a variable capacity and can be also used as a capacity expansion for the existing System Modules. New architecture enables flexible and on demand capacity upgrade path for Flexi site solution. New System Module platform consists of two base module variants (FSMF and FSMG) and two optional capacity extension sub-modules (FBBA and FBBB). Furthermore, the new 3U casing can also accommodate optional Power Distribution Sub-module as well as optional Transport Sub-module. New System Module supports WCDMA and LTE. HW is ready to support also GSM/EDGE. Benefits for the Customer – Secure BTS investments with flexible migration from one radio access technology to

another – Flexible capacity upgrade based on pay as you grow concept – Enables higher site capacities and new configurations – New Flexi System Module is well optimized for data services Functional Description New Flexi Multiradio System module consists of 3U high casing, which can accommodate a base module, optional capacity extension sub-modules (up to 2), an optional power distribution sub-module and an optional transport sub-module. All modules are IP65 class outdoor capable. There are two System Module (base) capacity variants, FSMF and FSMG: FSMF: Optimized for 2+2+2 WCDMA and LTE 1+1+1 support. Performance equals or exceeds FSMD capacity and features in terms of channel elements (CE) and HSPA throughput (Mbit/s) as well as LTE bandwidth (20MHz) and throughput. FSMG: Optimized for 1+1+1 WCDMA support. Performance equals to half of FSMD capacity in terms of channel elements (CE) and HSPA throughput (Mbit/s). Adequate LTE support and performance can be gained with an extension sub-module, FBBA or FBBB.



• New Flexi Multiradio System Module (FSM) platform is introduced • It has a variable capacity • can be used as a capacity expansion for the existing System Modules • New architecture enables flexible and on demand capacity upgrade path

for Flexi site solutions • New System Module platform consists of two base module variants

• FSMF and FSMG • Two optional capacity extension sub-modules

• FBBA and FBBB • New 3U casing can also accommodate

• Optional Power Distribution Sub-module • Optional Transport Sub-module

• New System Module supports WCDMA and LTE • HW is also ready to support GSM/EDGE


RAN2262 Flexi Multiradio System Modules, cont. New System Module consists of integrated ethernet transport, clock and control functions, baseband processing, casing and fans. It can be used as a stand alone System Module or it can be extended with optional items. There are four optical links for RF Modules in the base System Module configuration, FSMF or FSMG alone. Inside the casing, new System Module can be extended with up to two capacity extension sub-modules, FBBA/FBBB. Capacity is increased by adding capability to support more users and performance by increasing the total throughput of the base station. New System Module can be used as a extension to existing System Modules (Rel1 and Rel2). Capacity Extension sub-module FBBA & FBBB (Optional) FBBA: High capacity extension sub-module to add control and baseband processing and one optical connection for high capacity sites. FBBA has a equal performance as FSMF in terms of capacity and throughput. FBBB: Moderate capacity extension sub-module to add cost efficient control and baseband processing capacity and one optical connection for high capacity sites. FBBB has a equal performance as FSMG in terms of capacity and throughput. It is used e.g. to upgrade FSMG to support 2+2+2 WCDMA BTS. In LTE case FBBB with FSMF can be used for high capacity LTE BTS. Transport interface sub-modules, several variants (Optional). Support for transport modules, which can be fit in to 3U System Module casing



• FSMF • Optimized for 2+2+2 WCDMA and LTE 1+1+1 support • Performance equals or exceeds FSMD capacity and features in terms of

– channel elements (CE) – HSPA throughput (Mbit/s) – LTE bandwidth (20MHz) and throughput

• FSMG • Optimized for 1+1+1 WCDMA support • Performance equals to half of FSMD capacity in terms of • channel elements (CE) • HSPA throughput (Mbit/s) • Adequate LTE support and performance can be gained with an extension

sub-module, FBBA or FBBB


RAN2262 Flexi Multiradio System Modules, cont.

Current Implementation The current FSM-r2 variants will be replaced by r3. FSM-r3 support will be in RU40 and RL30 and deliveries. Interdependencies between Features The current FSM-r2 outdoor variants will be replaced by this HW feature. FSM-r3 will inherit r2 outdoor functionalities and features. Indoor variant for FSM-r3 will be proposed also. Operational Aspects R3 will inherit R2 outdoor operability, functionality and features. Possible new characteristics enable by the new, advanced HW will be proposed separately. HW Requirements FSM-r3 will have new, improved HW architecture and it will consist of new HW items. R3 will also inherit r2 outdoor operability, functionality and features in terms of environmental and usability requirements. Possible new characteristics enable by the new, advanced HW will be proposed separately




RAN2262 Flexi Multiradio System Modules, cont.

• New System Module consists of • integrated ethernet transport, clock and control functions • baseband processing • casing and fans

• It can be used as a stand alone System Module or it can be extended with optional items

• There are four optical links for RF Modules in the base System Module configuration FSMF or FSMG

• Inside the casing, new System Module can be extended with up to two capacity extension sub-modules, FBBA/FBBB • Capacity is increased by adding capability of supporting more users • Performance is increased by increasing the total throughput of the

base station

• New System Module can be used as a extension to existing Rel1 and Rel2 System Modules



• Optional capacity extension sub-module FBBA & FBBB • FBBA

• High capacity extension sub-module to add: • Control and baseband processing • One optical connection for high capacity sites

• FBBA has equal performance toFSMF in terms of capacity and throughput • FBBB

• Moderate capacity extension sub-module to add: • Cost efficient control and baseband processing capacity • One optical connection for high capacity sites • FBBB has equal performance toFSMG in terms of capacity and throughput • It is used e.g. to upgrade FSMG to support 2+2+2 WCDMA BTS • In LTE cases the FBBB with FSMF can be used as a high capacity LTE BTS

• Several optional variants of Transport sub modules that can fit into the 3U System Module casing



Alarms There are no alarms related to this feature. Measurements and counters There are no measurements and counters related to this feature. Key performance indicators There are no key performance indicators related to this feature.

Abbreviated name Full name Managed object numberOfR99ChannelElements Number of R99 channel elements BTSSCW hspaConfigurationList List of HSPA configurations LCELGW

New parameters



BSW/ASW NOT DEFINED RAS RELEASE RU40 RNC RELEASE RN7.0 BTS Flexi 10 FSM Rel 3 WN 8.0 BTS HARDWARE FLEXI REL.3 mcRNC RELEASE mcRNC3.0



RAN2317 240W Multiradio remote RF


RAN2317 240 W Multiradio Remote RF

Brief description: • This feature enables usage of up to 180 W output power per sector with one Flexi

RF module • Enables possibility to build high capacity and coverage sector for GSM and

WCDMA/LTE

Motivation and benefits: • 180 W output power within one Flexi RF module • Flexible configuration and free power allocation to different radio technologies • GSM capacity in the network can be maintained or expanded as needed and

gradually sifted to WCDMA and LTE technologies • Attractive for MORAN operators


RAN2317 240 W Multiradio Remote RF, cont. Introduction to the feature The RAN2317: 240 W Multiradio Remote RF feature is a superior future-proof BTS site solution for all existing and new mobile operators. With this feature it is possible to have up to 180 W output power per sector configurations with only one physical Flexi Multiradio BTS RF Module. With this feature it is possible to build high capacity and coverage sector for GSM and WCDMA/LTE by allocating the power flexibly from one power amplifier (MCPA) to different radio technologies. Operator benefits The RAN2317: 240 W Multiradio Remote RF feature offers excellent evolution path and expansion possibilities for operators with high GSM traffic. The GSM capacity in the network can be maintained or expanded as needed and gradually shifted to WCDMA and LTE technologies. Full 3GPP RF band support in TX and RX makes this feature superior in terms of capacity and coverage and makes it also attractive for MORAN operators. Up to 20 MHz sub-band is available for WCDMA/LTE with 160 W output power allocation and simultaneously 20MHz sub-band can be used for GSM with 80 W output power allocation. Performance can be further improved by separate optimal Antenna Tilt for GSM, WCDMA, and LTE



Supported RF Modules: - FXFA Flexi RF Module 1900 Triple - FXCA Flexi RF Module 850 Triple - FXDA Flexi RF Module 900 Triple - FXEA Flexi RF Module 1800 Triple

Operates in following concurrent modes: - GSM + WCDMA - GSM + LTE

Configuration examples: - WCDMA/LTE 1+1+1 MIMO with 120 W per carrier and GSM 1+1+1 with 60W per carrier. - WCDMA/LTE 1+1+1 MIMO with 120 W per carrier and GSM 2+2+2 with 30W per carrier. - WCDMA/LTE 1+1+1 MIMO with 120 W per carrier and GSM 6+6+6 with 10W per carrier.


RAN2317 240 W Multiradio Remote RF, cont. Functional overview 240 W Multiradio Remote RF feature supports flexible configurations and free power allocation to different radio technologies. The following BTS site configuration examples are possible:

• WCDMA/LTE 1+1+1 MIMO with 80+80 W and GSM 1+1+1 with 80W per TRX with 3 RF Modules



With four antenna feeders per sector one 4-port antenna or two X-pol antennas can be used. The number of needed antenna lines can be minimized by using the Flexi Multiradio Combiners (MRC). Also 4 way RX diversity configurations and up to 2+2+2 WCDMA configurations are supported with or without MIMO.



This feature requires: RAN1770/BSS21403: RF Sharing WCDMA – GSM or RAN2126: RF Sharing WCDMA - LTE

RAN2317

RAN1770 Alarms There are no alarms related to this feature.

Measurements and counters There are no measurements or counters related to this feature.

Key performance indicators There are no key performance indicators related to this feature.

Parameters There are no parameters related to this feature.



Release Information

WCDMA Release RU40 BTS (Flexi) WN8.0 HW Requirements Flexi SM Rel2 BSW/ASW BSW RAS SW Component RAN


RAN2429 Flexi 3-sector RF Module 2100 80W FRGT


RAN2429 - Flexi 3-sector RF Module 2100 80W FRGT

• Bandwidth TX 60MHz RX 60MHz

• Support up to: – 6 carriers for WCDMA – 2x20 MHz carrier for

LTE

• The following three-sector WCDMA BTS configurations are supported:

– Up to 1+1+1 – Up to 2+2+2 – Up to 3+3+3 – Up to 4+4+4 – Up to 5+5+5 – Up to 6+6+6

3-sector RF module for 2100 MHz frequency band: UL: 1920 - 1980 MHz DL: 2110 - 2170 MHz Usage: WCDMA, LTE in dedicated or concurrent mode

Flexi Multiradio RF Module 2100MHz (FRGT) is able to support up to three sectors with maximum 3 x 80 W output power at the BTS antenna connectors

80W

BAND 2100


RAN2429 - Flexi 3-sector RF Module 2100 80W FRGT, cont. Feature ID: RAN2429 This is a new feature which describes Flexi Multiradio RF Module (FRGT) for 2100 MHz. WCDMA and LTE operations are SW defined. Benefits for the operator: 3-sector Flexi Multiradio RF Module introduces industry leading RF integration level and smallest power consumption combined with flexible WCDMA-LTE site evolution. Functional description: Flexi Multiradio RF Module HW supports WCDMA and LTE in dedicated or concurrent mode. Flexi Multiradio RF Module provides 3 x 80W output power at the antenna connector. Maximum capacity of one Flexi Multiradio RF Module for WCDMA 2100 MHz is up to 6 carriers and up to 2 x 20 MHZ LTE carrier. Both Tx and RX chains support 60MHz instantaneous band. Power consumption is optimised by 3-way Doherty PAs. In 2100MHz band one Flexi Multiradio RF Module supports the following WCDMA configurations:

– Up to 1+1+1, - Up to 2+2+2, – Up to 3+3+3, - Up to 4+4+4, – Up to 5+5+5, - Up to 6+6+6,

Existing power levels are available. Other functionalities: – Integrated class II OVP protection level in DC connector – RET connector – 6Gbit OBSAI With this feature the WCDMA dedicated operation is activated. HW Requirements: RAN1016/ RAN1848 Flexi BTS Multimode System Module (FSMC, FSMD, FSME).



Technical details of FRGT • Full name: Flexi Multiradio RF Module 2100 80W • RF Module variant: FRGT • Product code: 472810A • Hardware release: 2.3 • Supported technologies: WCDMA, LTE • Supported bands: 2100 (3GPP band I) • Tx bandwidth: 40 MHz • Rx bandwidth: 60 MHz • Output power at antenna connectors: 3x80W • Number of pipes: 3 • Available power levels: 8, 15, 20, 30, 40, 60, 80* W • Number of optical interfaces: 3 • Optical link throughput: up to 6 Gbit/s

* - from RU40

EAC – External Alarm Connector RET – Remote Electrical Tilt



Release Information

WCDMA Release RU30 EP2 BTS (Flexi) WN7.0 2.0 HW Requirements Flexi SM Rel2


RAN2573 Flexi 3-sector RF Module 900 80W FXDB


RAN2573 - Flexi 3-sector RF Module 900 80W FXDB

• Bandwidth TX 35MHz RX 35MHz

• Support up to: – 4 carriers for WCDMA – 6 TRXs for GSM/EDGE – 20 MHz carrier for LTE

• The following three-sector

WCDMA BTS configurations are supported:

– Up to 1+1+1 – Up to 2+2+2 – Up to 3+3+3 – Up to 4+4+4

.

3-sector RF module for 900 MHz frequency band: UL: 880 - 915 MHz DL: 925 - 960 MHz Usage: WCDMA, GSM/EDGE, LTE in dedicated or concurrent mode

Flexi Multiradio RF Module 900MHz (FXDB) is able to support up to three sectors with maximum 3 x 80 W output power at the BTS antenna connectors

80W

BAND 900


RAN2573 - Flexi 3-sector RF Module 900 80W FXDB, cont. Feature ID: RAN2573 This is a new feature which describes Flexi Multiradio RF Module (FXDB) for 900 MHz. FXDB is able to support one, two or three sectors with maximum 3 x 80 W output power at the BTS antenna connectors. It has wide 35MHz transmitter and receiver bandwidth. It can be used in a one sector configuration with maximum 80 W + 80 W 2TX MIMO. The environmental protection class is IP65. Benefits for the operator: FXDB provides the following benefits: – the most cost, size, and weight optimized three-sector BTS site, easier installation,less visual

impact – industry-leading RF integration level – SW configurable radio: the same RF Module for LTE, HSPA+ and WCDMA and GSM/EDGE – the widest ambient temperature range: -35... +55 C – the smallest power consumption and OPEX – 3 sector RF Module in one outdoor IP65 protected box – less wind load – can be used as feederless site as well with one DC and one or two optical cables – TX diversity and MIMO 2TX can be build using two 3-sector RF Modules



. Technical details of FXDB • Full name: Flexi Multiradio RF Module 900 80W • RF Module variant: FXDB • Product code: 472573A • Hardware release: 2.3 • Supported technologies: GSM, WCDMA, LTE • Supported bands: 900 (3GPP band VIII) • Tx bandwidth: 35 MHz • Rx bandwidth: 35 MHz • Output power at antenna connectors: 3x80W • Number of pipes: 3 • Available power levels: 8, 15, 20, 30, 40, 60, 80* W • Number of optical interfaces: 3 • Optical link throughput: up to 6 Gbit/s

* - from RU40


RAN2573 - Flexi 3-sector RF Module 900 80W FXDB, cont. – RF redundancy option comes as additional advantage – in feederless installations one 3-sector RF Module is more cost effective than three Remote

Radio Heads (RRHs) – typically only one third of DC and optical cabling required compared to the Remote Radio

Heads – can be used as powerfull one sector RRH : 40 + 40 W 2TX MIMO with HW prepared for 4RX. Functional description: Flexi 3-sector RF Module 900 80 W (FXDB) supports 3GPP band 8. TX and RX bandwidths equal 35 MHz for efficient GSM, WCDMA and LTE Multiradio configurations. FXDB provides:

– configurations up to 4+4+4 – 8, 20, 40, 60 or 80 W mode per sector cotrolled by SW licenses – 1 sector configuration with maximum 80 + 80 W 2TX/2RX MIMO – HW prepared for 1 sector max 80 + 80 W 2TX/4RX MIMO in feederless site (optical and

DC cable up to 200 m) HW Requirements: RAN1016/ RAN1848 Flexi BTS Multimode System Module (FSMC, FSMD, FSME).



. Release Information

WCDMA Release RU30 EP2 BTS (Flexi) WN7.0 2.0 HW Requirements Flexi SM Rel2


RAN2573 (FXDB) and RAN2429 (FRGT)

. • RAN2429, RAN2573 require Flexi System Module hardware release 2 or 3:

‒ RAN2382 Flexi Multimode System Module – FSMC

‒ RAN1016 Flexi Multimode System Module – FSMD

‒ RAN1848 Flexi Multimode System Module – FSME

‒ RAN2262 Flexi Multiradio System Module – FSMF

or or or

RAN2382 Flexi System

Module FSMC

RAN2262 Flexi Multiradio System

Modules (FSMF)


Module FSMD


Module FSME

RAN2429 Flexi 3-sector RF module 2100 80W

FRGT

RAN2573 Flexi 3-sector RF module 900 80W

FXDB

or



RAN2429 RAN2573

Not utilized

• 60W output power pipes allow to allocate 4+4+4 configuration with up to 15W power per carrier

• 3Gbit optical interface allows to transmit in single optical link up to 16Tx/16Rx

• Narrower Tx and Rx bandwidths limit carriers allocation

Sector 1 f1: Rx f2: Rx f3: Rx f4: Rx

Sector 1 f1: Tx&Rx f2: Tx&Rx f3: Tx&Rx f4: Tx&Rx





Older RF Modules (HW 2.0, 2.1, 2.2)

2 optical links required to carry 12 cells 4+4+4(@15W)

Example of 4+4+4 (1Tx/2Rx) configuration



RAN2429 RAN2573 RAN2741 RAN2742 Utilized

• 80W output power pipes allow to allocate 4+4+4 configuration with up to 20W power per carrier

• 6Gbit optical interface allows to transmit in single optical link up to 32Tx/32Rx (available with FSMF)

• Wider Tx and Rx bandwidths allow to better carriers allocation







New RF Modules (HW 2.3)

1 optical links sufficient to carry 12 cells 4+4+4(@20W)

Example of 4+4+4 (1Tx/2Rx) configuration

RU40 perspective


RAN2157 Flexi Lite BTS 2100


RAN2157 - Flexi Lite BTS 2100

• Flexi Lite BTS is extremely compact BTS that consists of HW rel.3 BB unit (responsible for signal processing) + RF unit + integrated antenna (optional) + Ethernet ports

• Supports WCDMA technology

• The Flexi Lite BTS supports WCDMA/HSPA+ technology.

• Due to a small size Flexi Lite BTS it is even more easier to install BTS in dense urban/urban environment (Flexi Lite BTS offers extremely flexible deployments e.g. walls, lamp posts, billboards or other street furniture)


RAN2157 - Flexi Lite BTS 2100, cont.

Introduction to the feature Flexi Lite BTS is a small all-in-one base station optimized for outdoor micro-cell environment. The product design, hardware and software is based on the award-winning Flexi Multiradio BTS platform. End-user benefits This feature does not affect the end-user experience. Operator benefits This feature benefits operator as follows:

• The product can be used in pico and microcellular applications and also as a coverage fill-in solution. The main use case is in capacity limited networks where the operator needs to start using smaller cells to be able to deliver the required system capacity.

• Output power is high enough to support indoor coverage building from outdoor sites.

It is also high enough to drive distributed antenna system for indoor coverage. It also supports 2TX MIMO.

• Supports WCDMA/HSPA services.


RAN2157 - Flexi Lite BTS 2100 RF details

• The product supports UMTS band I * (other bands supports available in the future, based on customer need)

• Up to 2 sectors (2 sectors without Rx diversity) and 2 WCDMA carriers per sector are supported

• Flexi Lite BTS supports 2 way Rx diversity (1 or 2 omni carrier configuration case)

• 10 W + 10 W output power for micro (250 mW + 250 mW output power for pico layer)**

• MIMO support (up to 2 MIMO cells)

• Receiver sensitivity -121 dBm (tuneable up to -107dBm)

• Active cooling for highest reliability performance

• HSPA peak rates the same as with Flexi Multiradio BTS

• up to 84Mbps peak rate with DC-HSPA + MIMO + 64QAM

• maximum 140 HSPA users

• 180 CE for Rel99 only * Band I: UL: 1920 – 1980 MHz; DL: 2110 – 2170 MHz

** Output power can be set between 250mW and 10W

Indoor/ Outdoor


RAN2157 - Flexi Lite BTS 2100, cont. Functional description Flexi Lite BTS is integrated, small in size, lightweight base station which can be installed on walls or poles (IP65). The output power level is adjustable from 250mW + 250mW for pico cells up to 10W+10W for micro cells. Flexi Lite BTS offers flexible deployments options at walls, lamp posts, utility poles, billboards or other street furniture. Typical micro-cell outdoor antenna deployments are below roof-top in heights of about 5 to 15 meters above the ground level. Typical indoor deployments include exhibition halls, shopping malls, large office spaces, airports etc. Antenna height in indoor installations is typically from 2 to 5 meters above ground level. In indoors Flexi Lite BTS is to be mounted either on the wall or the ceiling or connected to an external distributed antenna system. Flexi Lite BTS consists of the following elements:

• core base station module • optional integrated antenna • optional visual cover • optional pole and wall installation kits

Flexi Lite BTS can be mounted on a wall or on a pole with the supplied hardware. Silent active cooling enables minimum installation clearance, so Flexi Lite BTS can be installed in locations that are not much larger than BTS itself (~10l), for example in utility rooms, inside cabinets (any position possible). All cabling is accessible without dismounting the unit.



Exemplary configurations

• 1-Omni / 10W (1TX/2RX) • 2-Omni / 10W (1TX/2RX)

TX / RX

Antenna filter

RX

TX

TX / RX

Antenna filter

RX

TX

f1 10W

2-Omni, (1TX/2RX) in both cells

f2 10W

f2

f1

BTS dimensions:

• Size: 380 x 325 x 86 mm (h x w x d), 10L

• Outdoor: -35 to +55 ºC, IP65

• Power consumption <200W (100% load)*

• Weight: 11 kg

• Any position installation possible

• Inside cabinet installation possible


RAN2157 - Flexi Lite BTS 2100, cont.

Air interface configuration Flexi Lite BTS has two transceivers: two 10W transmitters and two -121dBm (3G wide area sensitivity) receivers. Flexi Lite BTS operates at:

• UL: 1920 – 1980 MHz • DL: 2110 – 2170 MHz

Capacity WCDMA/HSPA capacity:

• HSPA peak rates the same as with Flexi Multiradio BTS • up to 84Mbps peak rate with DC-HSPA + MIMO + 64QAM

Baseband capacity: • maximum 140 HSPA users • 180 CE for Rel99 only

Transport Flexi Lite BTS uses IP as a standard transport protocol. Ethernet, both wireline and fiber, is the standard interface in the Flexi Lite BTS.



Exemplary configurations

TX / RX

Antenna filter

RX

TX

TX / RX

Antenna filter

RX

TX

2+2, (1TX/1RX) in both sectors f1 5W

f2 5W

f1 5W

f2 5W

• 1+1 / 10W (1TX/1RX) • 2+2 / 5W (1TX/1RX)

TX / RX

Antenna filter

RX

TX

TX / RX

Antenna filter

RX

TX

f1 10W

f1 10W

(2TX / 2RX), 10W + 10W MIMO

• 1-Omni / 10W + 10W MIMO (2TX/2RX) – in above figure • 2-Omni / 5W + 5W MIMO (2TX/2RX)



Connectors

• EAC = External Alarms and Control

• LMP = Local Management Port

• SYNC_IN = Synchronization Input

• SFP = Optical Ethernet

• TX/RX = Transmitter output/Receiver input

• AC power supply input

EAC HDMI

SFP Sync In HDMI

LMP RJ45

GE RJ45

Status LED

Power (AC) Tx/Rx1 Tx/Rx2

GND

Power options:

• Nominal voltage 100- 240VAC, 50/60Hz

• Permits 88 – 276 VAC, 45 – 66Hz

• Tolerates 276 – 300 VAC maximum 3 minutes

• Survives 20ms loss of AC power supply


RAN2157 - Flexi Lite BTS 2100, cont. Local management (LMP) • Ethernet RJ45 (same as with the Flexi Multiradio BTS) • All three speeds; FE (100 Mbit/s), GE (1000 Mbit/s) and 10 Base-T • Common management tool with Flexi Multiradio BTS

External alarms and controls (EAC) • 6 external alarms • 2 control outputs • HDMI connector Status LEDs • There’s 2 LEDs indicating the status of the BTS • RF Power status LED • BTS status LED

System Module rel.3 might be commissioned to one out of the three configurations:

• Rel99 only (up to 4 cells)

• Support of UMTS Rel.99 services, no support for HSPA

• Small HSPA configuration (up to 4 cells)

• Providing HSPA processing up to 4 HSPA cells (one HSDPA and HSUPA scheduler)

• Only one Local Cell Group (LCG) per Flexi Lite BTS is allowed

• Note that LCG commissioning is optional.

• By default Small HSPA configuration is assumed



Flexi Lite BTS capacity

Number of cells Rel99 Only Small HSPA

1-4 cells 2,5 Su

(240 Rel.99 CE) 1,875 Su

(180Rel.99 CE)

Table assumes 10km cell range / 2way Rx Div / 1 LCG

One subunit provides 96 Rel.99 CE

R99 bearers have the same Rel.99 CE consumptions as in RU30/RU40 with System Module rel.2/rel.3



Flexi Lite BTS capacity – Interference Cancelation

1 PIC pool activated Small HSPA

Flexi Lite BTS traffic capacity after PIC pool

activation 0,875 Su

Table assumes 10km cell range

1 PIC pool can be activated with Flexi Lite BTS



Flexi Lite BTS – Small HSPA configuration

Number of cells Flexi Lite BTS

(no PIC) Flexi Lite BTS

(1 PIC activated)

Flexi Lite BTS traffic capacity 1,875 Su 0,875 Su

Subunits available for HSUPA scheduler 1,75 Su* 0,75 Su*

Max amount HSDPA users (UL:R99 bearer, DL:HSDPA bearer) 180** 84**

Max amount of HSUPA users (UL:HSUPA bearer, DL:HSDPA bearer)

120*** 72***

* - Total BTS capacity cannot be allocated for HSUPA scheduler (0,125 subunit must remain for DCH users)

** - PS 16kbps assumed in UL

*** - 10ms TTI FDPCH users assumed

One HSDPA scheduler supports:

• up to 4 HSPA cells

• Up to 240 active users

• Up to 168 Mbps

One HSUPA scheduler supports:

• up to 4 HSPA cells

• Up to 160 active users

However baseband capacity restricts max amount of HSPA users possible with Flexi Lite BTS

Table assumes Small HSPA configuration,10km cell range. Max amount of HSDPA and HSUPA users presented in the table cannot be met at the same time.


RAN2157 - Flexi Lite BTS 2100 Flexi Lite BTS – Small HSPA configuration

To allocate the next HSUPA resource step, an additional free capacity of six Rel99 CE is needed. The required 6 Rel99 CE free on top of the HSUPA resource step is to avoid a “ping-pong” effect in reserving and freeing HSUPA resource steps. This is needed so that the HSUPA resource step is not requested back immediately after its allocation.

Therefore HSUPA scheduler can allocate whole available BTS capacity except one HSUPA resource step (0,125 subunit) which must remain available for R99 traffic.

R99 use r s

HSDPA scheduler

HSUPA or

R99 users

HSUPA or

R99 users

Max baseband capacity available for HSUPA (1,75 subunit)

Max baseband capacity available for R99 (1,875 subunit)

HSDPA scheduler 0,625 subunit

• HSUPA allocation is done dynamically in steps – so called HSUPA resource steps (0,125 subunit)

• In case if Rel99 CE licensed baseband resources are overlapping HSUPA licensed baseband resources – overlapped resources can be dynamically exchanged between R99 and HSUPA users

R99 use r s

HSUPA or

R99 users



WCDMA Release RU40 I-HSPA System No supported RNC Release RN7.0 mcRNC Release mcRNC3.0 BTS (Flexi Lite) WL7.0.2.0 NetAct OSS 5.4 CD Set3 PP2 HW Requirements Flexi Lite BTS RAS SW Component RAN



Flexi RRH 2TX 60W+60W


Flexi Multiradio RRH 2TX 60W+60W

The Flexi Multiradio Radio Remote Radio Head (FHxx) or RRH, consists of two independent branches, capable of transmitting and receiving signals of multiple radio technologies concurrently It is intended for outdoor mounting and optimized for feederless applications

• Up to 6 GSM carriers with 400 KHz minimum carrier separation

• 2x60 W TX capability (Note that FHxA variants have 2x40 W TX capability)

• EGPRS2 and VAMOS support

• Up to 4 WCDMA carriers with 4.6 MHz minimum carrier separation

• Multi-carrier LTE signal with 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz, and 20 MHz carrier bandwidth

• Multi RAT operation with a combination of GSM, WCDMA, and LTE

• Input voltage range 36 - 57 V DC; minimum startup voltage is 40.5 V DC


Flexi Multiradio RRH 2TX 60W+60W, cont.

Benefits End-user benefits

This feature does not affect the end-user experience. Operator benefits

One sector Flexi Remote Radio Head supports 2 TX MIMO with high output power (2 x 60W) for hot spot dense urban capacity sites. It enables easy outdoor installation close to antennas by maximizing BTS site capacity and coverage for one sector. FHDB supports 35 MHz TX/RX bandwidth.

FHDB Flexi RRH 2TX 2RX 900 MHz provides the following features:

• 2x60 W output power with two power amplifiers • optimization for single sector deployment with 2TX MIMO • optical chaining support by HW (two optical connectors with 6 Gbit/s interfaces) • IP65 with -40°C to +50°C with convection cooling • external alarms and outputs • AISG2.0 Antenna tilt support with external connector (RS485)


Flexi Multiradio RRH 2TX 60W+60W

• The supported functions are: • Chaining up to three RF Modules with OBSAI

RP3-01 • Integrated antenna line supervision • MHA and RET support • Digital and control circuitry, optical interface, DC

power input, and other necessary functionalities • Integrated DC line OVP, Class II rated to 5kA

pulse • Input DC voltage monitoring

FHDB 900 MHz FHEB 1800 MHz TX filter frequency range 925-960 MHz 1805-1880 MHz RX filter frequency range 880-915 MHz 1710-1785 MHz TX instantaneous bandwidth 35 MHz 35 MHz RX instantaneous bandwidth 35 MHz 60 MHz TX filter bandwidth 35 MHz 75 MHz RX filter bandband 35 MHz 75 MHz Duplex spacing 45 MHz 95 MHz



Colour Indication Red, blinking Operation degraded: Major alarm on the RF Module Red, stable Faulty: Critical alarm on the RF Module

Yellow, blinking Software download in progress or Configuration in progress: RF resources are being setup, but not yet activated

Yellow, stable Until software download begins or The carriers are blocked from BTS or There is no connection to any System Module

Green, blinking Software downloading and updating

Green, stable Software configuration is complete or Supervisory: RF resources activated and transmission is possible or Working normally, no alarm on the RF Module

Stable Red for less than 5 seconds and changes to Stable Yellow Switched ON, but the next conditions are not reached yet

Stable Red for less than 5 seconds The module is in the process of resetting Periodic Red and Green Antenna line device faulty/degraded (RF Module only) Cylcling Colors (Red, Yellow, and Green), each color stable for 500 ms Module Highlighting

LED indications:

2x60 W RRH does not have a TX status LED and the BTS Manager reports its status LED state only



BW and configurations for different Bands

Frequency/Bandwidth TX/RX 900MHz 35/35 MHz (FHDB) 1800MHz 35/60MHz (FHEB)

GSM TRX´s 6 + 6 6 + 6

WCDMA Carriers 4 + 4 carriers 4 + 4 carriers

LTE BW 1.4/3/5/10/15/20 MIMO 1.4/3/5/10/15/20 MIMO

2 RAT mode for RRH unit (Dedicated or Concurrent mode for MCPA)

GSM and/or WCDMA and/or LTE GSM and/or WCDMA and/or LTE

Output power Up to 60W+60W Up to 60W+60W

MCPA Concurrent mode(s)** Max supported by HW: GSM/LTE, GSM/WCDMA GSM/WCDMA/LTE WCDMA/LTE (The capacities shown here are per MCPA or per branch. RRH has 2 MCPA branches. So the total RRH HW capacity is twice the MCPA Concurrent Mode as shown here)

- 5G+1U/1L(5MHz) - 2G+3U - 4G+1L(10MHz) - 2G+1U+1L(10MHz) -2U+1L(10MHz) -2G+1L(15MHz) -1U+1L(15MHz) - 4G+2x2L(15MHz) MIMO with 2 MCPAs

- 5G+1U/1L(5MHz) - 2G+3U - 4G+2U/1L(10MHz) - 2G+1U+1L(10MHz) -2U+1L(10MHz) -2G+1L(15MHz) -1U+1L(15MHz) - 4G+2x2L(15MHz) MIMO with 2 MCPAs



MCPA1 MCPA2 RRH unit

GSM Dedicated

Mode

1TRX@60W/TRX 2TRX@30W/TRX 3TRX@20W/TRX 4TRX@15W/TRX 5TRX@12W/TRX [email protected]/TRX

1TRX@60W/TRX 2TRX@30W/TRX 3TRX@20W/TRX 4TRX@15W/TRX 5TRX@12W/TRX 6TRX@ 8.5W/TRX

2TRX@60W/TRX 4TRX@30W/TRX 6TRX@20W/TRX 8TRX@15W/TRX 10TRX@12W/TRX [email protected]/TRX

Flexi RRH 2TX 900 and 1800

Flexible RRH configurations • Dual Duplexer to enable MIMO and 2-way diversity

schemes for 1 sector (2 antenna ports / module) Up to 6+6 MIMO or 12 with 1 RRH • Capacity extensions with chaining 12+12+12 with 3 RRH • Cost optimized for 1 sector MIMO

configurations Configurations: • Minimum: up to 6+6 MIMO (1 module) • Maximum: up to 12+12+12 (3 RRH) • With these power steps:

• 1 TRX * 60W (2 ant/sect) • 2 TRX * 30W (2 ant/sect) • 3 TRX * 20W (2 ant/sect) • 4 TRX * 15W (2 ant/sect) • 5 TRX * 12W (2 ant/sect) • 6 TRX * 8.5 W (2 ant/sect)

X Duplexer

MCPA TX

RX main

Duplexer

MCPA TX

RX main

RRH (FHxB)

Optical RP3 LNA

LNA

mailto:[email protected]/TRX


Flexi RRH 2TX 60W+60W Example of carriers allocation in 3 sector site for sector configuration type I: • Utilized RF module

– FRGP (20 MHz Tx, 20 MHz Rx, 60 W output power)

• Possible carriers combination – up to 1+1+1 WCDMA and up to 15 MHz LTE

– up to 2+2+2 WCDMA and up to 10 MHz LTE

– up to 3+3+3 WCDMA and up to 5 MHz LTE

Sector 1 LCR1: Tx & Rx












WCDMA: 1+1+1 MIMO, 30W power per carrier LTE: 1+1+1 MIMO, 30W power per carrier, 15 MHz channel BW



WCDMA LK logic is same as for any other WCDMA BTS except for single carrier, 20W O/P power for each branch is included in the 3 sector RF Module pricing • No additional branch activation licenses are required • If maximum RF power per branch exceeds 20W, the existing 40W or 60W power licenses

need to be ordered accordingly • 8W license needs to be ordered separately, if required • Existing 2nd carrier activation licenses need to be ordered in case no. of carriers in each

branch is more than one

License Key:



WCDMA Release RU40 RNC Release RN7.0 mcRNC Release mcRNC3.0 BTS Flexi WN8.0



RAN2489 Carrier Bandwidth 3.8MHz


RAN2489 - Carrier Bandwidth 3.8MHz

Improves GSMWCDMA re-farming spectrum efficiency

WCDMA 4.2MHz BCCH GSM 0.2MHz

2.6 MHz

f[MHz]

2.2 MHz

PC TCH GSM 0.2MHz

WCDMA 3.8MHz

BCCH GSM 0.2MHz

2.6 MHz

f[MHz]

2.0 MHz

PC TCH GSM 0.2MHz


RAN2489 - Carrier Bandwidth 3.8MHz, cont. WCDMA can be deployed with different carrier bandwidth requirements using Flexi WCDMA BTS filtering technology It is possible to select 3.8 MHz carrier bandwidth in uplink for WCDMA operation Especially useful when operator's frequency spectrum where UMTS is to be deployed is limited. Decreased carrier bandwidth need will ease refarming deployment compared to standard Flexi WCDMA BTS solution. The basic assumption is that GSM and UMTS base stations will be co-sited when using 3.8 MHz deployment. Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature benefits operator as follows:

• improved refarming solution with more efficient UMTS introduction • CAPEX savings thanks to better spectrum efficiency (maximum Multiradio HW

utilization) • Two additional GSM channels are obtained with 3.8 MHz compared to 4.2 MHz

bandwidth solution.


Transceiver Hardware supporting 3.8Mhz bandwidth (TX and RX filters) • FXCA / FXDA / FHDA HW version A.203 or later:

• RAN2046 - Flexi 3-sector RF Module 850 (FXCA), RU20 • RAN1768 - Flexi 3-sector RF Module 900 (FXDA), RU20 • RAN1895 - Flexi RRH 2TX 900 (FHDA), RU30 EP1 • RAN2573 Flexi 3-sector RF module 900 80W (FXDB), RU30 EP2 • RAN2558 Flexi RF Module 1800 Triple 80W (FXEB), RU50 • RAN2747Flexi RF Module 900J Triple 80W (FXJB), RU50

RAN2489 - Carrier Bandwidth 3.8MHz


RAN2046 Flexi 3-sector RF Module

850 FXCA

RAN1768 Flexi 3-sector RF Module

900 FXDA

RAN1895 Flexi RRH 2TX 900

FHDA

RAN2573 Flexi 3-sector RF Module 900 80W FXDB

Earlier HW versions of FXCA/FXDA/FHDA are not known to support 3.8MHz BW. HW versions earlier than A.203 need to be upgraded in order to support 3.8 MHz BW


RAN2489 - Carrier Bandwidth 3.8MHz Transceiver Hardware partially supporting 3.8Mhz bandwidth (RX filters)

• RAN2741 Flexi 3-sector RF Module 850 90W (FXCB), RU30 EP2 • RAN2615 Flexi RF Module 900-J Triple 70W (FXDJ), RU30 EP1 • RAN2692 Flexi RRH 2TX 900 (FHDB), RU40 • RAN2158 Flexi RF Module 1800 Triple 70W (FXEA), RU40 • RAN1575 Flexi RF Module 1900 Triple 70W (FXFA), RU20


RAN2741 Flexi 3-sector RF Module 850 90W FXCB

RAN2615 Flexi RF Module 900-J

Triple 70W (FXDJ),

RAN2692 Flexi RRH 2TX 900

(FHDB)

RAN2158 Flexi RF Module 1800

Triple 70W (FXEA

RAN1575 Flexi RF Module 1900

Triple 70W (FXFA


RAN2489 - Carrier Bandwidth 3.8MHz Release Information

RAS Release - RU40 BTS Release (Flexi) - WBTS8.0 BTS Release (Flexi 10) - WBTS8.0 BTS HW Release - RFM Rel2.2/RFM Rel2.3/RFM Rel3.0/SM

Rel1/SM Rel2/SM Rel3 NetAct - OSS5.4 CD set 3


RAN2489 - Carrier Bandwidth 3.8MHz Activating Carrier Bandwidth 3.8MHz : Licence Feature Code – 3857 and 4437 (BTS licences) • RAN2489 is activated from BTS SM via BPF parameter: rxBandwidth in

commissioning phase • BTSSM checks whether selected RFM/RRH supports configurable RX BW level

or not • Check is done by BPF property Support.Of.Rx.Bandwidth.List • If property exists, then RFM/RRH supports configurable RX BW level • if property does not exist, then RFM/RRH does not support configurable RX

BW level • Supported BW: 4.2, 4.0, 3.8 (RAN2489 + CN5088) • When the operator does not change RX BW level then rxBandwidth shall be left

empty • All digital filters, uplink and downlink, have to be set-up correctly before the

corresponding carrier is enabled • Carriers must be disabled before any filter configuration is changed

• Each change of filter BW requires a WBTS reset


RAN2111 Flexi WCDMA Software Download Capability for Antenna Line Devices


RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices

Software download capability introduced for Antenna Line Devices minimizing service interruption, eliminating the need for site visits and tower crew visits for ALD software upgrades


RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices, cont. • The aim of this feature is to enable Antenna Line Device

software upgrades using the BTS Site Manager or NetAct to initiate the download

• Supported devices are MHA (Mast Head Amplifiers), RET (Remote Electical Tilt), Smart Diplexers

• Currently SW downloads requires service interruption in order to communicate to the ALD - normally a site visit with approximately 30min service break / antenna line

• This feature eliminates site visits • Causes about a 1 minute long degradation to RX levels when

the device restarts


RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices Release Information

RAS Release - RU40 Flexi Direct Release - ADA5.0 BTS Release - Flexi WBTS8.0 BTS Release (Flexi 10) - FSMr3 WBTS8.0 BTS HW Release - RFM Rel1, RFM Rel2, RFM Rel2.1, RFM Rel2.2,

RFM Rel2.3, RFM Rel3.0, SM Rel1, SM Rel2, SM Rel3.

NetAct - OSS5.4 CD set 3


RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices Activating Flexi WCDMA Software Download Capability for Antenna Line Devices :

• Requires BTS licence – Licence feature code – 1604 • Connect to the BTS with BTS Manager • Check that the licence is installed



• Open the recommissioning dialogue, navigate to pg14 and tick the checkbox SW update for antenna line devices in use



• From the Antenna menu bar select Create/Modify TargetBD_EXD.xml • The following window will open:


RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices • This window allows for the creating and modifying of files where the user can

define the software to be downloaded to external devices like MHA and RET using the normal SW update function

• If a TargetBD_EXD.xml file is present, select the Create file from existing TargetBD_EXD.xml check box and select the desired file from the file selector • If no file is present select Import BTS HW Info to import manufacturer, product

code and HW version information to the table • Import BTS HW Info is shown only in online mode.


RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices •Enter missing values in Manufacturer, Product code, HW version and SW version columns •Browse for the software files


RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices •Select the software update option

•Select the Save As button to save the TargetBD_EXD.xml file and provide a name for the file

Normal – SW version is checked. Upgrade is possible only if SW is different than the SW installed on ALD device (ALD SW version is compared to string typed in SW version column). Forced – SW update is forced, regardless on ALD’s current SW version and SW version field. Restricted – SW is not updated to particular ALD.


RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices •Select the Update SW button to open the Update SW to BTS Site dialog box with selected theTargetBD_EXD.xml •Select theActivate SW after update check box and click Update.


RAN2591 Selective BTS Resource Re-Balancing in mcRNC


RAN2591 – Selective BTS Resource Re-Balancing in mcRNC

• Load sharing of CSPU resources is optimized

BTS-1 BTS-2

BTS-3

BTS-6

BTS-5

BTS-4

BTS-7

Alarm threshold

Load

#CSCP

BTS-1

BTS-2

BTS-3 BTS-4

BTS-5

BTS-6

BTS-7

CSCP-0 CSCP-1 CSCP-2 CSCP-3

Alarm threshold

Load

#CSCP

BTS-1

BTS-2

BTS-3 BTS-4

BTS-5 BTS-6

BTS-7

CSCP-0 CSCP-1 CSCP-2 CSCP-3

BTS-2



• Reallocation of BTS’s to a less loaded CSPU is performed in a controlled manner • Common channel resources are statically allocated to CSPUs in a round robin

sequence during the NBAP link configuration phase • Although the CSCP algorithm considers the weight of the WBTS in the selection

algorithm the CSCP load could easily become unstable due to some mass events • Load peaks for CSCPs is generated due to a large number of RRC connections

causing unnecessary RRC connection request rejections • Common Channel reallocation between CSCPs is introduced to rebalance the

CSCP loads • Moderately loaded WBTS are re-allocated from overloaded CSPUs to less loaded

CSPUs based on their load capabilities • Configurable load thresholds and BTS Weights are used to evaluate the load

balance of the CSPUs • The mcRNC profiles the load and the “weight” trend of the WBTSs • When the set threshold for CSPU is reached or exceeded an alarm is triggered • The rebalancing can be manually triggered when required



• The load for each CSCP is calculated by the mcRNC and BTS re-allocation is started between the CSPUs to keep the CSCP loads balanced

• BTSs can be excluded from the rebalancing process by adding the BTS to the RebalanceBlockBtslist

• There is no service break during the re-allocation • A small number of calls may be terminated • The re-allocation will not take place if there are emergency calls ongoing • The BTS cells have CPICH and BCCH transmitting all the time, but the CCH

traffic will have a break of a few seconds • DCHs and Mac-d flows are handed over to the neighboring cells • The feature introduces a new RNC object RNCERM • RAN2591 cannot be used with RAN2117 - RNC2600 Co-siting with mcRNC




object RNCERMId RNCERM Identifier RNCERM RNCERMChangeOrigin Change origin for RNCERM object RNCERM RebalanceBlockBtslist Blocked BTSs for BTS resource re-balancing RNCERM DonateCscpLoadThrHi CPU load high threshold for donating CSCP selection RNCERM RecvCscpLoadThr CPU load threshold for receiving CSCP selection RNCERM NumOfDaysForLM Number of days for load measurement period RNCERM MaxBtsForRebalance Max number of BTSs selected for resource re-balancing RNCERM CscpOverloadRatioThr Ratio threshold for overloaded CSCP RNCERM BTSRebalanceEnabled BTS Resource Re-balancing Enabled RNCERM NbrAMRCallsAllwdToDrop Maximum number of AMR calls allowed to drop RNCERM

New parameters:

Alarm ID Alarm name 7786 WBTS OUT OF USE 3773 CSCP OVERLOAD

Existing alarms:



Activating Selective BTS Resource Re-Balancing in mcRNC : • Licence Feature Code = 3897 • Create the RNCERM object with OMS Element manager or with NetAct

Configurator.

• The parameters below will be created with default value during the RNCERM object creation. These parameters can be modified with the OMS Element manager or using NetAct Configurator after the RNCERM object is created

• RNCERM-RebalanceBlockBtslist • RNCERM-DonateCscpLoadThrHi • RNCERM-RecvCscpLoadThr • RNCERM-NumOfDaysForLM • RNCERM–MaxBtsForRebalance • RNCERM–CscpOverloadRatioThr • RNCERM-NbrAMRCallsAllwdToDrop

• Set the RNFC-BTSRebalanceEnabled parameter value to ‘Enabled’ using the OMS Element manager or with NetAct Configurator



Release Information

RAS Release - RU40 mcRNC Release - mcRNC3.0 RNC RNC FlexiPlatform – FP6-Cougar IPA Light – IL5 NetAct - OSS5.4 CD set 3

Documents

01_RN33211EN40GLA1_RU40 Release Hands-On Workshop