Aircel 3g Features Document

RAN Feature Description Document for Aircel
Abstract: The document contains the brief description of the RAN features of NSN.
The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of nokia siemens networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if necessary, explain issues which may not be covered by the document. Nokia Siemens Networks' liability for any errors in the document is limited to the documentary correction of errors. Nokia Siemens Networks will not be responsible in any event for errors in this document or for any damages, incidental or consequential (including monetary losses), that might arise from the use of this document or the information in it. This document and the product it describes are considered protected by copyright according to the applicable laws. Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only.
Copyright 2009 Nokia Siemens Networks. All rights reserved.
3G Features Description - Aircel
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48.
RAN Procedures for the Idle UEs..................................................................................6 RAN - UE Connection Establishment ...........................................................................7 Management of the Connected Mode UE......................................................................8 Radio Access Bearer Establishment and Release ..........................................................9 Radio Link Allocation for Real-Time Radio Access Bearer Services.........................10 UE Location Management with Handover Procedures................................................11 SRNS Relocation .........................................................................................................12 Packet Data Transfer States .........................................................................................14 Encryption and Integrity Protection.............................................................................16 Packet Data Handling on Iu .........................................................................................17 Multi-RAB: AMR + 3 PS data.....................................................................................18 Multi-RAB: CS data + PS data ....................................................................................19 Admission Control Algorithm .....................................................................................20 Resource Manager Algorithm......................................................................................21 Power Control Algorithm.............................................................................................22 Load Control Algorithm...............................................................................................24 Soft Handovers.............................................................................................................25 Inter-Frequency Handover ...........................................................................................26 WCDMA - GSM Inter-System Handover ...................................................................29 GSM - WCDMA Inter-System Handover ...................................................................32 Inter-RNC Intra-Frequency Hard Handover ................................................................33 IMSI Based Handover..................................................................................................34 Dynamic Link Optimization for NRT Traffic Coverage .............................................35 Paging Channel State (Cell_PCH) ...............................................................................36 Power Balancing ..........................................................................................................37 AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75)..........................................38 Wideband AMR Codec Set (12.65, 8.85, 6.6) .............................................................40 Bsic HSDPA with QPSK and 5 Codes ........................................................................41 HSDPA BTS Packet Scheduler....................................................................................42 HSDPA Proportional Fair Resource Packet Scheduler................................................43 HSDPA Flow Control ..................................................................................................44 HSDPA Resource Allocation.......................................................................................45 HSDPA Channel Switching .........................................................................................46 HSDPA Shared Control Channel Power Control ........................................................47 HSDPA Associated Uplink DPCH Scheduling ...........................................................48 HSDPA 16QAM Support.............................................................................................49 HSDPA Cell Reselection .............................................................................................50 HSDPA 15 Codes.........................................................................................................51 HSDPA Code Multiplexing .........................................................................................52 HSDPA Mobility Handling with DCH Switching.......................................................53 HSDPA Serving Cell Change ......................................................................................54 HSDPA Dynamic Resource Allocation .......................................................................55 Basic HSUPA...............................................................................................................57 HSUPA BTS Packet Scheduler....................................................................................59 HSUPA Handovers ......................................................................................................60 HSUPA Congestion Control ........................................................................................61 Flexible Iu ....................................................................................................................63 Nokia Multi-Operator RAN .........................................................................................64
3G Features Description - Aircel 3
49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97.
HSDPA Transport with Best Effort AAL2 QoS ..........................................................66 Collection of Key Counters..........................................................................................67 Antenna Line Supervision............................................................................................69 Flexi WCDMA BTS 3GPP Antenna Tilt Support .......................................................70 Flexi WCDMA BTS AISG MHA Support ..................................................................71 Inter-system Handover Cancellation............................................................................72 RRC Re-establishment for Real Time Services ...........................................................73 QoS Aware HSPA Scheduling.....................................................................................74 Streaming QoS for HSPA ............................................................................................75 PS RAB Reconfiguration .............................................................................................76 PS UE States: URA_PCH ............................................................................................77 Spectral Efficient Link Adaptation for HSDPA ..........................................................78 Dual Iub for Flexi WCDMA BTS................................................................................79 CS Voice Over HSPA ..................................................................................................80 HSDPA 64QAM ..........................................................................................................82 HSUPA 5.8 Mbps ........................................................................................................83 Continuous Packet Connectivity ..................................................................................84 Multi-Operator Core Network .....................................................................................86 HSUPA Interference Cancellation Receiver................................................................87 Frequency Domain Equalizer.......................................................................................88 LCS - Cell Coverage Based (RTT) with Geographical Coordinates ...........................89 UE Based A-GPS Using External Reference Network................................................90 Network Based A-GPS Using External Reference Network .......................................91 IP Based Iu-PS .............................................................................................................92 KPI Calculations in RNC Element Manager ...............................................................94 Load and Service Based IS/IF Handover .....................................................................96 HSPA Inter-RNC Cell Change ....................................................................................98 HSUPA 2.0 Mbps ........................................................................................................99 IMA (Flexi WCDMA BTS) .......................................................................................100 IP Based Iu-CS...........................................................................................................101 IP Based Iur................................................................................................................102 IP Based Iub for UltraSite WCDMA BTS.................................................................104 IP Based Iub for Flexi WCDMA BTS .......................................................................105 HSPA 72 Users Per Cell ............................................................................................107 HSPA over Iur............................................................................................................108 HSUPA 2 ms TTI.......................................................................................................109 Extension of SIB11 (SIB11bis)..................................................................................110 Directed Retry ............................................................................................................111 24 kbps Paging Channel.............................................................................................112 BTS Auto Connection................................................................................................113 Flexible Upgrade of NRT DCH Data Rate ................................................................115 HSDPA 14 Mbps per User.........................................................................................116 HSDPA Dynamic Power Allocation..........................................................................117 HSDPA Service Indicator ..........................................................................................118 HSDPA Soft/softer Handover for Associated DPCH ................................................119 BTS Synchronous Ethernet ........................................................................................120 Dynamic Access Class Restriction ............................................................................121 Efficient ATM Capacity Sharing Using Circuit Emulation.......................................123 Enhanced Priority Based Scheduling and Overload Control for NRT Traffic ........124
3G Features Description - Aircel 4
98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143.
HSDPA Inter-frequency Handover ............................................................................125 HSPA Multi NRT RABs............................................................................................127 High Speed Cell_FACH.............................................................................................128 Ethernet link aggregation for RNC ............................................................................130 Ethernet OAM............................................................................................................131 Intelligent BTS Shutdown with BBU Unit ................................................................132 Iub Transport QoS......................................................................................................133 Support for Tandem/Transcoder Free Operation .......................................................135 Route Selection ..........................................................................................................136 Satellite Iub ................................................................................................................138 Radio Network Configuration Management..............................................................139 Radio Network Online Monitoring ............................................................................140 RNC Management Tool for Fault Localisation .........................................................141 RNW Configuration Event Management...................................................................142 Service Area Broadcast ..............................................................................................143 Subscriber Trace ........................................................................................................144 Transport Bearer Tuning ............................................................................................146 Automatic Definition of Neighbouring Cells.............................................................147 OSPF for Iu-PS Redundancy .....................................................................................149 OSPF for Redundancy ...............................................................................................150 Packet Scheduler Algorithm ......................................................................................151 Path Selection.............................................................................................................152 Extended Cell (180km) ..............................................................................................154 HSDPA Congestion Control ......................................................................................155 Dual-Cell HSDPA 42Mbps........................................................................................156 LTE Interworking ......................................................................................................157 BTS backhaul over multiple IP interfaces .................................................................158 4-Way RX Diversity ..................................................................................................159 UBR+ for Iub User Plane...........................................................................................160 HSDPA Upgrade from 5 Codes to 10 Codes.............................................................161 Robust Header Compression: Not Compliant............................................................162 IP Header Compression: Not Compliant ...................................................................163 AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75) (For Conversational AMR 12.2 kbps (voice service)) ..........................................................................................164 Iu Link Break Protection............................................................................................165 RAN - UE Connection Establishment (For Conversational CS 64 kbps (video call) and NRT PS data 32 to 384 kbps UL & DL) .............................................................166 Dynamic Scheduling for HSDPA with Path Selection ..............................................167 IP over ML-PPP on E1/T1/JT1 Interfaces .................................................................168 HSUPA channel type selection: .................................................................................169 OCNS (Orthogonal Channel Noise Simulator): Not Compliant................................170 NodeB Control Port (NCP) ........................................................................................171 Timing over Packet for BTS ......................................................................................172 HSUPA Pre-emption Light ........................................................................................173 BTS Power Saving .....................................................................................................174 Directed RRC Connection Setup ...............................................................................175 Macro Diversity Combining and Splitting.................................................................176 Dynamic Routing for the Iub .....................................................................................177
1.
RAN Procedures for the Idle UEs
Functional description: When the UE does not have any resources reserved from the network, it is in idle state. In the idle state the UE has no Radio Resource Control (RRC) connection to the RAN. The RAN provides system information broadcast for UEs in idle state; these recurrent broadcasts allow the UE to receive core network (CN), RAN and cell-specific information and perform cell reselection, if necessary. The BTS broadcasts system information on a regular basis. The system information is broadcast on the Broadcast Channel (BCH) on the radio path. Based on that information, the UE is able to decide whether and how it may gain access to the system via the current cell. The RNC uses an Iub L3 procedure to control the information to be broadcast on the BCH. * In idle state the UE has no dedicated connections to RAN. * The RAN sends cell-specific information to UE by Broadcast Channel Messages. * RNC controls the System Information broadcast to be sent on BCH. Based on the System Information, the UE is able to gain access to the appropriate cell. Figure:
2.
RAN - UE Connection Establishment
Functional description: An initiation of the Radio Resource Control (RRC) connection establishment can be triggered by a paging request from the core network or by a request from the CM layer in the UE. After the RRC connection establishment has been completed, the UE is in RRC connected mode. The CN initiates the establishment of the RRC connection with the Iu interface paging procedure. The RNC controls the paging of the UE in the cells belonging to the relevant area. The RNC builds and schedules the paging message to be sent on the radio path. When receiving the paging message, the UE addressed initiates the RRC connection setup procedure. It sends an RRC connection setup request to the RAN, which can admit the access and activate radio link(s) for the UE. The RRC connection establishment is completed when the lower layers of the radio interface and the appropriate Iub user plane connections are established. Operational aspects: RRC Signaling Measurements include the measurements that can be used to check the number of CN and RNC initiated pagings.
3.
Management of the Connected Mode UE
Functional description: The Radio Resource Control (RRC) connection allows a dialogue of signaling messages between the UE and RNC and also a dialogue between the UE and CN, including the support of the SMS. The RRC connection is needed for example for radio access bearer establishment, reconfiguration and release, SMS and Location Updating. The RRC signaling entities on the network side are located in the serving RNC. For the BTS the actual information on the RRC connection is transparent, with the exception of cell broadcast that can also be received by the packet data users. If a UE has a connection to two core networks (CS and PS), upper layer signaling entities from the different CNs can use the same RRC connection and signaling link. Two signaling links are implicitly part of the RRC connection: one is used solely for RAN originated control messages and the other one for CN originated messages. The CN messages on the radio path are conveyed to the UE using a radio interface RRC layer procedure. The RNC does not analyse the contents of the CN messages.
If the RNC receives a paging request from the CN for a UE that already has an RRC connection, the RNC forwards the paging message to the UE via the existing signaling link. This can happen when a connection to one CN exists and another CN starts a connection setup by paging the UE.
4.
Radio Access Bearer Establishment and Release
Functional description: Radio Access Bearer Establishment The CN service is negotiated with Call Control (CC) signaling, which uses the existing signaling link between the UE and RAN, and the signaling connection between the RAN and CN. When the CN and UE have completed the service negotiation, the CN requests the radio access bearer from the RAN. If the radio access bearer parameters are admitted, the radio access bearer is set up. The radio access bearer parameters can be different in the uplink and downlink directions, and the radio access bearer can be set uni-directionally. The RNC starts the activation procedures for the required resources at the radio interface and establishes the user plane connections at the Iub and Iur interfaces. For NRT (non-real-time) services, the radio access bearer can be established without immediate reservation of radio resources. The radio resources will be allocated when requested using the signaling link between the UE and the RNC.
5.
Radio Link Allocation for Real-Time Radio Access Bearer Services
Functional description: An UE to which RT radio bearers have been allocated always has a radio link connection to the RAN. The RNC determines the radio link parameters and requests a radio link activation at the BTS. During the first radio link setup, the BTS selects the traffic termination point for the UE and sends an identification of an associated Node B Application Protocol (NBAP) signaling link to the RNC. Once the traffic termination point has been selected, it will provide baseband processing and Iub user plane termination for that specific UE as long as the UE has radio links to the BTS. At the BTS the radio link allocation is valid until the RNC requests deallocation. If the physical channel parameters are to be changed for an active channel, the RNC sends a modification request to the BTS. A soft handover via a drift RNC requires Iur procedures for managing the radio links controlled by the drift RNC. Because the RRC protocol entity for the UE is located in the serving RNC, it is responsible for the signaling to the UE. However, all Iub radio link allocation procedures on the network side are initiated from the RNC controlling the BTS, that is, the BTS has no knowledge of the controlling RNCs role in respect to the UE. Operational aspects: L3 Signaling at Iub Measurement allows the operator to follow the number of radio link handling procedures.
10
6.
UE Location Management with Handover Procedures
Functional description: When the UE has real-time (RT) radio bearer(s), the UE location is known on the cell level. When the UE is moving, the radio connection is maintained using measurement reporting and handover procedures. The information from the UE and BTS measurements is used to make the decision controlling the handover execution, as well as for determining what kind of a handover is needed. The handover procedures are also needed to change radio link allocations due to radio link quality and radio resource management. Handover procedures are divided into three categories: soft handovers, hard handovers and serving RNC relocation. In the first release the following handover scenarios are supported: * Softer handover (between cells at the same BTS) * Soft handover * Inter-RNC soft handover (over the Iur) * Inter-RNC hard handover (in case no Iur user plane between RNCs) * Serving RNC relocation Soft handovers are divided into soft and softer handover. In the soft handover the new radio link is added to the so-called active set, and the macro diversity combining is done in the RNC. A new Iub user plane connection(s) has to be established, possibly also an Iur user plane connection(s) in case of an inter-RNC soft handover. In the softer handover the macro diversity combining is done at the BTS. Thus, the Iub user plane allocation remains the same. The UE handles both the soft and softer handover as updates to the active set. The Inter-RNC hard handover is used to relocate the serving RNC functionality from one RNC to another, and to change the radio resources assigned for the UE by a hard change. This procedure is used if the Iur interface cannot be used for active set management. The serving RNC relocation is used for moving the SRNC functionality from one RNC to another RNC, for example, closer to where the UE has moved during the communication. This is useful from the transmission usage point of view, but also in order to avoid unnecessary communication between several RNCs. In the figure below, steps (i) and (ii) show the situation before and after SRNC relocation.
11
7.
SRNS Relocation
Summary: The Nokia radio network controller (RNC) supports the Serving Radio Network Subsystem (SRNS) Relocation procedure. In the procedure, the user equipment's (UE's) Iu connection and the UE's call control are relocated from the old serving RNC to a new serving RNC as the mobile terminal moves to a new RNC area. In this case, the old serving RNC transport and call control resources are set free. This results in an optimised capacity usage and avoids the RNC hot-spot formation at sites where many calls are initiated. Benefits for the operator: Nokia has selected the 3GPP-standardised mobility SRNS Relocation method which is a long-term solution for transmission and processing capacity, because it offers many advantages (described below) and is the only viable system for WCDMA networks which are upgraded with High Speed Packet Access (HSPA) technology. The procedure can be executed over Iur or Iu interfaces, which ensures robustness against Iur congestion or an Iur failure. Further, the benefits in the Iur transmission are more than 60 to 85 % compared to a situation where the Iu is not relocated and the Iur not freed (known as SRNC anchoring). SRNS relocation is the best solution from day one, offering the most efficient use of RNC capacity. Relocation frees the RNC's processing capacity to handle new calls. Based on field measurements, this solution is estimated to save at least 10% in the RNC costs because fewer RNCs are needed in the network. Relocation cuts the transmission demand on the Iur, which offers further CAPEX savings. Other major benefits with SRNS Relocation include: * Radio resource optimisation and handovers are performed in the RNC that has the best inputs for the algorithms (for example handover decision). * The transmission route is always optimised configured as a neighbouring RNC for other RNCs). (every RNC does not have to be
* No overloaded RNCs in hot spots (congestion due to lack of RNC hardware resources), for example in railway stations, airports and subway stations. * The Iur interface is optional for SRNS Relocation, that is, the Iur interface is not critical. * Iur congestion and temporary or failure situations have no impact on SRNS Relocation (these situations do not affect the UE mobility since handovers can be done without the Iur interface). * Inter-RNC hard handovers are executed with relocation procedures. * Dimensioning the Iur interface is easier. * Relocation is a future-proof solution to handle the UE mobility in a radio network, as the relocation solution enables HSPA mobility. In conclusion, SRNS Relocation ensures mobility without wasting transmission capacity for high data volume calls. It offers CAPEX saving and is a sustainable endto-end mobility solution for high-volume data services today and in the future. Functional description: The SRNC relocation (also called Serving RNS relocation in 3GPP specifications) is used for moving the SRNC functionality from one RNC to another RNC, that is, closer to the location where the UE has moved during the session. Both the radio access network and the core network are involved. The relocation procedure is illustrated below. When a mobile terminal moves from a base station under the control of one RNC to another base station under a different RNC, the call is seamlessly re-routed through the radio network subsystem.
Copyright 2009 Nokia Siemens Networks. All rights reserved. 3G Features Description - Aircel 12
Operational aspects: The 3GPP standards (TS 25.401 V5.10.0) give two different options for handling inter-RNC mobility in the radio network: * SRNS Relocation, which is a standardised mobility method, * "SRNC Anchoring" which is not as such a standardised mobility method, but can be implemented by applying an undefined set of standardised features. Nokia has opted for the SRNS Relocation option, as it offers the best capacity efficiency and a future-proof solution to handle UE mobility in the radio network. SRNS relocation changes the macro diversity combining point when the UE moves under another RNC. With SRNC anchoring, the control remains in the same RNC during the whole connection. A further advantage is that the low Iur traffic involved with the SRNS Relocation achieves the highest RNC capacity and transmission capacity, while the SRNC Anchoring consumes a considerable amount of transmission and processing resources. SRNS Relocation is a basic procedure in the RAN since it is always used for intersystem handovers and for hard handovers when Iur is not used.
13
8.
Packet Data Transfer States
Functional description: In order to provide efficient radio resource usage, a full set of packet data transfer states are needed for the management of NRT radio access bearer users. The location of the UE to which the RT radio access bearers have been allocated is always known on the cell level. The location of the UE that has only NRT radio access bearers, however, is either known on the cell level or the URA level, depending on which RRC state the UE is in. The UE is then in UTRA RRC Connected Mode. There are four different RRC states in the UTRA RRC Connected Mode; three states where the UE location is known on the cell level and one state where the UE location is known on the URA level. These states are 'Cell_DCH', 'Cell_FACH', 'Cell_PCH' and 'URA_PCH' (see notes below). The different RRC states can be characterized by the following main aspects: * In Cell_DCH state the UE has dedicated channel resources (a dedicated physical channel). The dedicated resources are also reserved between the RNC and BTS (in Iub interface) for this UTRAN-UE connection. The location of the UE is known on the cell level based on the existing radio link(s) between the UE and the BTS(s). When inactivity of the NRT radio bearer(s) (RBs) and signaling radio bearers (SRBs) is detected, there is no need to keep dedicated resources reserved for the UE. Thus, the UE is transferred to the Cell_FACH state. * In Cell_FACH state the UE uses UTRAN common channel resources. There are no dedicated resources reserved in the Iub for the UE. The UE can send uplink data and signaling messages via the RACH after a random access procedure between UE and the BTS. The RNC sends downlink data and signaling messages on the FACH, which is continuously monitored by all the UEs in the Cell_FACH state. When the amount of user data to be sent via the RACH exceeds a predefined limit, the UE requests dedicated channel resources by sending a capacity request to the RNC. After this a dedicated physical channel is allocated and the UE is transferred to the Cell_DCH state. The location of the UE is known on the cell level based on the indications (cell update) sent by the UE when a cell reselection occurs. When inactivity of the NRT RB(s) and SRB(s) is detected in Cell_FACH state, the UE is ordered to transfer to the Cell_PCH state. This is done in order to conserve the battery of the UE; keeping the UE continuously receiving on FACH would unnecessarily consume its battery. Note, that if a UE in Cell_PCH or URA_PCH state (see note below) wishes to initiate any uplink activity for user plane data or signaling messages, it must always execute a random access procedure, perform a transition to the Cell_FACH state and initiate a Cell Update procedure. * In Cell_PCH state (see note1 below), the UE can use discontinuous reception (DRX) and must only monitor paging indications (and paging messages) sent by the RNC. If the RNC wishes to initiate any downlink activity (for user plane data or signaling messages), it must first perform a paging procedure to transfer the UE to the Cell_FACH state. The location of the UE is known on the cell level based on the Cell Update messages sent by the UE when it enters a new cell. The inactivity detection in Cell_PCH state is based on Cell Update messages sent by the UE. When a predefined maximum time allowed for user inactivity is exceeded, the RRC connection for this UE is released and the UE transfers to the idle mode. * In URA_PCH state (see note 2 below), the UE can use DRX and must only monitor paging
indications and paging messages sent by the RNC. If the RNC wishes to initiate any downlink activity for user plane data or signaling messages, it must first perform a paging procedure to transfer UE to the Cell_FACH state. The location of the UE is known on the URA level based on the URA Update messages sent by the UE when a URA change occurs. The inactivity detection in URA_PCH state is based on the URA Update messages sent by the UE. When a predefined maximum time allowed for user inactivity is exceeded, the RRC connection for this UE is released and the UE transfers to the idle mode.
15
9.
Encryption and Integrity Protection
Functional description: In RAN two security mechanisms can be applied: ciphering and integrity protection. Ciphering is a sufficient countermeasure against eavesdropping and it plays a significant role in protecting connections against attackers with more advanced capabilities, but it is not sufficient alone. In addition to the mutual authentication performed between the UE and CN, integrity protection of signalling is needed in order to have sufficient security against active attackers. The type of ciphering provided by RAN is based on XOR combing with a mask obtained as an output of the ciphering algorithm. The input parameters for the algorithm are a cipher key, time dependent input, the radio access bearer identity, the direction of the transmission and the length of the required key stream. Because of the separate mobility management for CS and PS services, the UE establishes cipher keys separately to CS and PS core networks. As regards to signaling links, the most recently established key (between the UE and either of the CNs) is used. The UMTS Integrity Algorithm (UIA) is used to authenticate the data integrity of signalling messages. Input parameters for the algorithm are an integrity key, time dependent input, a random value, a direction bit and signaling message data. Based on these input parameters the message authentication code for data integrity (MAC-I) is generated and appended to the signaling messages sent over the signaling link. Also the receiver computes the MAC-I and verifies the data integrity of the message by comparing it to the received MAC-I. The integrity key is transferred to the RAN in conjunction to the cipher key. In RAN both ciphering and integrity protection are always performed in the serving RNC.
16
10. Packet Data Handling on Iu

Functional description: Iu-PS interface to the PS core network is an open interface between the RNC and SGSN. It is mandatory in order to provide the UEs service from the packet data networks (PDN). The protocol architecture for the user plane of the Iu-PS interface towards the IP domain is based on the same principles as the evolved Gn interface (SGSN-GGSN interface). The evolved GPRS tunneling protocol (GTP) defines a tunnel between the RNC and SGSN. The tunnel is used for carrying user data packets related to a Packet Data Protocol (PDP) context of the GPRS. The GTP tunneling enables multiplexing of the user data traffic into a single IP connection, that is the same IP address, over the Iu-PS. The tunneling enables also transparent transferring of multiprotocol user data packets across the Iu-PS, so that the Iu-PS does not have to support several network layer protocols. The IP is enough at the Iu-PS, nevertheless the users can use various network layer protocols. The UDP/IP carrying GTP connections is used on top of AAL5/ATM. One or several AAL5/ATM Permanent Virtual Connections (PVCs) can be used as the common layer 2 resources between the RNC and SGSN. The reasons for the use of several AAL5/ATM PVCs are for example load sharing and redundancy. The figure below shows the user plane protocol stacks towards the PS core network. Buffering of the PDCP PDUs is performed in the PDCP layer of the RNC and UE.
17
11. Multi-RAB: AMR + 3 PS data

Functional description: This feature increases the number of simultaneous NRT PS RAB allocations to three. The following new multi-RAB combinations are supported for one UE: * 2 NRT PS RABs * 3 NRT PS RABs * AMR + 2 NRT PS RABs * AMR + 3 NRT PS RABs The bit rates of the DCHs allocated for the RABs are selected so that the total bit rate does not exceed 384 kbit/s. Operational aspects: The operator can monitor the used multi-RAB configurations through multi-RAB specific counters.
18
12. Multi-RAB: CS data + PS data

Functional description: One 64 kbit/s DCH for a Transparent CS data RAB and one 8 kbit/s DCH for a NRT PS data RAB can be allocated simultaneously for one UE. Up to three simultaneous NRT PS RABs are supported. If more than one NRT PS RABs are configured, the 8 kbit/s DCH is allocated for one RAB at a time, while the others are mapped to a 0 kbit/s DCH. Operational aspects: The operator can monitor the used multi-RAB configurations through multi-RAB specific counters.
19
13. Admission Control Algorithm

Functional description: Admission Control (AC) decides whether a request to establish a Radio Access Bearer (RAB) is admitted in the RAN. Admission control is used to maintain stability and to achieve high traffic capacity of the RAN. The AC algorithm is executed when the radio access bearer is set up or the bearer is modified. AC measures also take place with all types of handovers. The AC algorithm estimates the load increase that the establishment of a prospective bearer would cause in the radio interface. The effects in the uplink and downlink directions are estimated separately. The inter-cell interference effect is also estimated. If the predicted load exceeds particular thresholds either in the uplink or downlink, the bearer is not admitted. In the decision procedure, the AC will use thresholds produced by radio network planning and the uplink interference and downlink transmission power information received from the wideband channel. The AC algorithm also determines all the configuration parameters for L1 an L2 layers. The main inputs for the algorithm are RNP and RAB attributes received over Iu interface in the RAB setup. Operational aspects: The Cell Resource Measurement can be used to follow the measured and estimated power levels of the cell.
20
14. Resource Manager Algorithm

Functional description: The Resource Manager (RM) is responsible for the management of the logical radio resources of the RNC in co-operation with Admission Control (AC) and Packet Scheduler (PS). The RM manages the logical radio resources of the BTS and performs channel (code) allocations when requested. The RM maintains in its tables information concerning the use of the logical channels in the BTS and uses this information when making decisions concerning channel allocation. The RM manages the code tree and all functions related to it with a specific code allocation algorithm. Operational aspects: The Cell Resource Measurement allows the operator to follow the average code tree occupancy and code allocation failures due to the lack of free codes.
21
15. Power Control Algorithm

Functional description: Since the WCDMA system is interference limited, it is beneficial to use as low transmission power at the transmitting entities as possible. Thus, the target of power control (PC) is to achieve the minimum signal-to-interference (SIR) ratio that is required for the sufficient quality of the connection. The PC works on a connection basis. The power control provides protection against large changes in shadowing and immediate response for fast changes in signal levels and interference levels. The power control is also needed because of the near-far problem. The PC entity fulfills the radio link power related adjustment with the following procedures: * Open loop PC (PRACH, SCCPCH for FACH) * Fast closed loop PC (DPCH) * Outer loop PC (DPCH) The location of the fast closed loop and outer loop power control algorithms in the UMTS system is illustrated in the figure below. Open loop PC The open loop PC is used to control the transmitted power of the PRACH (uplink) and SCCPCH (downlink). The UE is responsible for taking care of the open loop PC in the uplink adjusting the transmit power of the PRACH. The UE estimates the path loss from the BTS to the UE. The transmitted power of the PRACH can be determined from the path loss estimate and the information of the uplink interference level and the required received Ec/Io. The uplink interference level and the required received Ec/Io are broadcast on the BCCH. The RAN takes care of the open loop PC in the downlink adjusting the transmission power of the SCCPCH that includes the FACH and PCH transport channels. The RAN sets the power of the SCCPCH channel on a cell basis. Fast closed loop PC As soon as the frame synchronisation in the uplink and downlink DPCHs has been established, the PC starts to control the transmitter power level of the channels in the fast closed loop power control mode. The basic operation of the uplink fast closed loop power control is the following: 1. The BTS measures the received SIR of the uplink DPCH every transmitter power control cycle (1 slot). 2. When the measured value is higher than the reference SIR target value, the transmitter power control (TPC) bit is "0" and when the measured value is lower than the SIR target, the TPC bit is "1". 3. The BTS inserts the TPC bits to the next slot of the DPCCH. 4. The UE either decreases or increases the transmission power of the DPCH based on the received TPC bits. The basic operation of the downlink fast closed loop power control is the following: 1. The UE measures the received SIR of the downlink DPCH every transmitter power control cycle (1 slot). The measured SIR value is compared to the SIR target in each slot time. 2. When the measured SIR value is higher than the reference SIR target, the transmitter power control (TPC) bit is "0" and when the measured SIR value is lower than the SIR target, the
TPC bit is "1". 3. The UE inserts the TPC bits to the next slot of the DPCH. 4. The BTS either decreases or increases the transmission power of the DPCH based on the received TPC bits. The adjustment is done for every slot. Outer loop PC Outer loop PC (also called "quality loop PC") adjusts the SIR target used by the closed loop PC. The SIR target is independently adjusted for each connection based on the estimated quality of the connection. The RNC provides the initial value. The SIR target value is to be set so that the usage of radio resources is most effective (the power is set to as low as possible), still ensuring that the quality of the connection is acceptable. In uplink outer loop PC the RNC monitors the link quality and adjusts the new SIR target for the fast closed loop PC accordingly. The UE takes care of the downlink outer loop PC. The downlink outer loop PC sets the SIR target for the uplink fast closed loop PC according to the quality estimates of the received channel. Downlink outer loop PC functions are mainly located in the UE, but some control parameters are set by the RAN.
23
16. Load Control Algorithm

Functional description: One task of the RRM is to guard the radio resources so that the radio interface is not overloaded and remains stable. The load control can be divided into two different parts: * Preventive load control * Overload control The preventive load control is performed by admission control and the packet scheduler. They make sure that the load does not increase beyond the predefined thresholds. Overload control takes place when the load has already exceeded the predefined thresholds, and aims at reducing the load back to the nominal level in a controlled way. The packet scheduler also brings the overload back to the nominal level as it performs scheduling. In exceptional situations, such as when all traffic in the cell is RT traffic, the packet scheduler cannot affect the load. Since the main criteria in the WCDMA system for the radio resource management is the interference, the load control functionality is done through measuring both uplink and downlink interference (in case of the downlink the transmission power of the BTS) periodically under one RNC. These measurements are performed on a cell basis. The RRM performs actions to adjust the load of the cell according to these interference measurements and the parameters (predefined thresholds) set by radio network planning. Cell load, controllable load and non-controllable load The further the users are from the BTS and the more users are connected to the cell, the more transmission power is needed to achieve a required reception quality to decode the data in the receiver end. Some of the capacity needs to be reserved for the real time (RT) traffic for mobility purposes all the time. Thus, the proportion of the power budget for RT bearers increases the further the users are from the base station. The proportion between RT and non-real time (NRT) traffic varies constantly. It is characteristic to the RT traffic that the load caused by it cannot be controlled in an efficient way, mainly because RT users normally request constant bit rates. Thus, the RT users have to be served first and any surplus capacity must be reserved for the best effort NRT traffic. In order to achieve the maximum capacity, the functionality responsible for allocating the NRT traffic needs to be fast. The best effort NRT traffic provides good tools to make this possible, due to the effective method to control the allocated capacity in kbit/s with transport formats on a short time interval basis. In practice, the division between the RT and NRT traffic is not enough for the functionality, since the interference from the surrounding cells needs to be taken into account as well. Combined RT traffic and surrounding cell interference is called noncontrollable traffic. The capacity which is left over is called controllable traffic and is the same as the best effort NRT traffic. Radio network planning defines the thresholds for the RRM functionality (planned total load and planned load for non-controllable traffic). These thresholds are set to guarantee a stable functionality within a cell and with surrounding cells. The load control is performed for the uplink and downlink separately, because the 3rd generation networks support almost 100 % asymmetric traffic and the load may vary a great deal between the uplink and the downlink. In addition, the uplink and the downlink use different frequencies. Operational aspects: Cell Resource Measurement can be used to follow the cell overload occasions.
24
17. Soft Handovers

Functional description: Soft handover means that a mobile station is simultaneously connected to several BTSs during an intra-frequency handover procedure. Soft handover is a mobile evaluated handover (MEHO). When in active mode, the mobile station continuously measures serving and neighbouring BTSs (cells indicated by the RNC) on the current carrier frequency. The UE compares the measurement results with handover thresholds, which have been provided by the RNC, and sends a measurement report to the RNC when the handover thresholds are fulfilled. The main decision algorithm of the soft handover is located in the RNC. Based on the measurement report received from the UE, the RNC orders the MS to add or remove cells from its active set, that is, the set of cells participating in the soft handover. The Handover Control of the RAN consists of the following types of soft (intrafrequency) handovers for both real-time (RT) and non-real-time (NRT) radio access bearers: * Softer handover between cells (with different coverage areas) within one BTS * Soft handover between BTSs within one RNC (intra-RNC soft handover) * Soft handover between BTSs controlled by separate RNCs (inter-RNC soft handover) In the WCDMA system the vast majority of handovers are intra-frequency handovers. Different types of intra-frequency handovers can take place simultaneously. For example, RAN is able to perform soft (intra-RNC as well as inter-RNC) and softer handovers at the same time. The main objectives of the soft/softer handover are the following: * Optimum fast closed loop power control (the UE is always linked with the strongest cells) * Seamless handover without any disconnection of the radio access bearer Soft/softer handover also enables a sufficient reception level for maintaining communication by combining reception signals (macro diversity) from multiple cells in cases where the UE moves to the cell boundary areas and cannot obtain a sufficient reception level from a single cell. Furthermore, the macro diversity gain improves the uplink signal quality and thus decreases the required transmission power of the UE. The macro diversity gain is achieved by combining the reception signal in the BTS (softer handover) and in the RNC (soft handover).
25
18. Inter-Frequency Handover

Summary: Inter-frequency handover is a hard handover between the WCDMA cells which are on different carrier frequencies. Functional description: The inter-frequency hard handover is always networkevaluated and it presumes periodical reporting of the neighbouring cells from the UE. If the UE cannot measure two different frequencies at the same time, the compressed mode must be used on the radio interface. The compressed mode makes gaps on transmission. During the gaps the UE makes the required measurements from the target frequency. After the handover decision, radio links on the network side are set up and the UE is commanded to change to radio links on the target frequency. It is possible to perform the inter-frequency handover for RT and NRT radio bearers in Cell_DCH state. The inter-frequency handover is prevented the Cell_FACH state in order to save the FACH capacity. In case of an inactive NRT radio bearer(s) only, the UE evaluated inter-frequency cell reselection may happen in Cell_PCH state. There are four main reasons to trigger the handover measurements: uplink coverage, uplink quality, downlink coverage and downlink quality. The operator can select which reasons to use on a cell basis. Handover measurements based on coverage reasons for UL and DL DL coverage: DL transmission power approaches the maximum DL power or CPICH Ec/Io goes below the threshold The RNC can order the UE to start inter-frequency handover measurements if there are neighbouring cells on a different frequency configured for any of the cells in the Active Set and at least one of the following reasons is fulfilled. * If the downlink transmission power of the radio link reaches the maximum downlink power set for the radio link, the downlink outer loop power control in the UE cannot maintain the required quality target (BLER target defined according to the QoS parameters). * The UE measures the serving cell CPICH Ec/Io and reports it to the RAN if it goes below a predetermined operator adjustable threshold. The operator can decide which one (both or neither)of the reasons is used on a cell basis. It is also possible to adjust the UE reporting interval and period. The interval determines the time between the reports sent and the period defines the maximum time the measurements are performed and thus the maximum time the UE is allowed to stay in Compressed Mode if a handover is not performed. The measurement procedure is applied to both RT and NRT radio bearers. However, to maintain the planned handover area it is possible for the operator to set a maximum user bit rate before the compressed mode and measurements are initiated. The radio link is dynamically reconfigured in the uplink and downlink so that the user bit rate is reduced along with the need for increasing the transmission power to guarantee the coverage. Thus, this parameter (separate for uplink and downlink) defines the point where the user bit rate is no longer reduced but the compressed mode and measurements are activated. UL coverage: UE tx power reaches the maximum value or CPICH RSCP goes below the threshold The RNC can order the UE to start inter frequency handover measurements if there are neighbouring cells on different frequency configured for any of the cells in the Active Set and at least one of the following reasons is fulfilled. * The UE is commanded to make UE internal measurements 6A (UE Tx power becomes larger than an absolute value) and 6D (UE Tx power reaches its maximum power) and to
report the results to the RNC for evaluation. The operator can define the absolute value for 6A. The service can also affect to the value, in other words it is possible to define different values for different services. * The UE measures the serving cell CPICH RSCP and reports it to the RAN if it goes below a predetermined operator adjustable threshold. The same rules as for DL coverage apply for selecting handover reasons, controlling reporting and checking the user bit rate. Handover measurements based on quality reasons for UL and DL The quality reason usually triggers the handover when there is something unexpected happening on the radio link. This can be, for example, external interference from the adjacent cells. DL quality: CPICH Ec/Io goes below the threshold The RNC can order the UE to start inter-frequency handover measurements if there are neighbouring cells on a different frequency configured for any of the cells in the Active Set and the following reason is fulfilled: * The UE measures the serving cell CPICH Ec/Io and reports it to the RAN if it goes below a predetermined operator adjustable threshold. The same rules as for downlink coverage apply for controlling reporting and checking the user bit rate. UL quality: Quality deterioration report from uplink outer loop power control of the RNC The RNC can order the UE to start inter-frequency handover measurements if there are neighbouring cells on a different frequency configured for any of the cells in the Active Set and the following reason is fulfilled: * Quality deterioration report from the uplink outer loop power control in the RNC is generated, if the outer loop power control in the RNC cannot maintain the required quality target anymore (BLER target defined according to the QoS parameters). The same rules as for DL coverage apply for controlling reporting and checking the user bit rate. Handover decision algorithm for the DL handover reasons The handover decision made by the RNC is based on the downlink CPICH Ec/Io of the serving cell, the downlink CPICH Ec/Io of the neighbouring cells (on another carrier frequency) and a handover margin which is used as a threshold to prevent repetitive interfrequency handovers between cells. The neighbouring cell having the highest CPICH Ec/Io value is always selected as the target cell for the handover. It should also be checked that the CPICH RSCP exceeds the predefined minimum threshold. This is to guarantee that there is at least a minimum coverage available in the target cell required for uplink transmission. Handover decision algorithm for the UL handover reason The handover decision made by the RNC is based on the propagation loss between the UE and the BTSs (serving and neighbouring cells) and a handover margin which is used as a threshold to prevent repetitive inter-frequency handovers between cells. The neighbouring cell offering the lowest path loss is always selected as the target cell for the handover. It should also be checked that the CPICH Ec/Io exceeds the predefined minimum threshold. This is to guarantee that there is at least the minimum coverage available required for DL transmission in the target cell.
27
Operational aspects: Intra-system HHO Measurement counters can be used to follow the total number of the triggered inter-frequency handovers and their success ratio.
28
19. WCDMA - GSM Inter-System Handover

Functional description: The WCDMA-GSM inter-system handover procedure is very similar to the serving RNC relocation procedure performed without Iur involvement, though some differences in message parameters and required measurements exist. Also, GSM restrictions with respect to the missing multicall capability require some actions from the CN to make the bearer matching. The inter-system handover is always network-evaluated and preceded by periodical reporting of neighbouring cells. Like the inter-frequency handover, inter-system handover requires the use of compressed mode on L1 for measurements, unless the UE supports dual receiver functionality. It is possible to perform the inter-system handover for RT radio bearers in Cell_DCH state. Inter-system handover of Packet Switched (PS) services between WCDMA and GPRS is based on the cell reselection procedure. The Handover Control of the RAN supports network initiated cell reselection from WCDMA to GPRS in Cell_DCH state of connected mode. In Cell_PCH state of connected mode, the cell reselection from WCDMA to GPRS is initiated by the mobile station. The cell reselection from WCDMA to GPRS is not possible in Cell_FACH state of connected mode. There can be four different main reasons to trigger the handover measurements: Uplink coverage, Uplink quality, Downlink coverage and Downlink quality. The operator can decide which reasons to use on a cell basis. Handover measurements based on coverage reasons for UL and DL Coverage reason handovers are typically triggered when the UE is moving on the cell edge. This can take place when the radio network planning is done and handover areas are defined. DL coverage: DL transmission power approaches the maximum DL power or CPICH Ec/Io goes below the threshold The RNC can order the UE to start inter-system handover measurements if there are neighbouring cells on a different system configured for any of the cells in the Active Set and at least one of the following reasons is fulfilled: * If the downlink transmission power of the radio link reaches the maximum downlink power set for the radio link, the downlink outer loop power control in the UE cannot maintain the required quality target anymore (BLER target defined according to the QoS parameters). * The UE measures the serving cell CPICH Ec/Io and reports it to the RAN if it goes below a predetermined operator adjustable threshold. The operator can decide which one (both or neither) of the reasons is used on a cell basis. It is also possible the adjust the UE reporting, especially reporting the interval and reporting period. The interval determines the time between reports sent and the period defines the maximum time the measurements are performed and thus the maximum time the UE is allowed to stay in the Compressed Mode if a handover is not performed. The measurement procedure is applied to both RT and NRT radio bearers. However, to maintain the planned handover area it is possible for the operator to set a maximum allowed user bit rate before the compressed mode and thus initiate the measurements. The functionality reconfigures the radio link dynamically in uplink and downlink so that the user bit rate is reduced along with the need for increasing tx power to guarantee the coverage. Thus, this parameter (separate for uplink and downlink) defines the point at which it is no longer sufficient to reduce the user bit rate and, consequently, the compressed mode is activated. UL coverage: UE tx power reaches the maximum value possible or CPICH RSCP goes below the
Copyright 2009 Nokia Siemens Networks. All rights reserved. 3G Features Description - Aircel
29
threshold The RNC can order the UE to start inter-system handover measurements if there are neighbouring cells on a different system configured for any of the cells in the Active Set and at least one of the following reasons is fulfilled: * The UE is commanded to make UE-internal measurements 6A (UE Tx power becomes larger than an absolute value) and 6D (UE Tx power reaches its maximum power) and report the results to the RNC for evaluation. The operator can define the absolute value for 6A. The service can also affect to the value,in other words, it is possible to define different values for different services. * The UE measures the serving cell CPICH RSCP and reports it to the RAN if it goes below a predetermined operator adjustable threshold. The same rules as for downlink coverage apply for selecting handover reasons, controlling reporting and checking the user bit rate. Handover measurements based on quality reasons for UL and DL The quality reason typically triggers the handover when there is something unexpected happening on the radio link. This can be for example external interference from adjacent cells. DL quality: CPICH Ec/Io goes below the threshold The RNC can order the UE to start inter-system handover measurements if there are neighbouring cells on a different system configured for any of the cells in the Active Set and the following reason is fulfilled: * The UE measures the serving cell CPICH Ec/Io and reports it to the RAN if it goes below a predetermined operator adjustable threshold. The same rules as for downlink coverage apply for controlling reporting and checking the user bit rate. UL quality: Quality deterioration report from uplink outer loop power control of the RNC The RNC can order the UE to start intersystem handover measurements if there are neighbouring cells on different system configured for any of the cells in the Active Set and the following reason is fulfilled: * Quality deterioration report from the uplink outer loop power control in the RNC is generated, if the outer loop power control in the RNC cannot maintain the required quality target anymore (BLER target defined according to the QoS parameters). The same rules as for downlink coverage apply for controlling reporting and checking the user bit rate. Handover decision algorithm for the DL handover reasons The handover decision made by the RNC is based on the downlink CPICH Ec/Io of the serving cell, the downlink CPICH Ec/Io of the neighbouring cells (in another carrier frequency) and a handover margin which is used as a threshold to prevent repetitive inter-frequency handovers between cells. The neighbouring cell having the highest CPICH Ec/Io value is always selected as the target cell for the handover. It should also be checked that the CPICH RSCP exceeds the predefined minimum threshold. This is to guarantee that there is at least a minimum coverage available in the neighbouring cell required for uplink transmission. The handover decision made by the RNC is based on the threshold level that the downlink signal level of the neighbouring GSM cells must exceed before the handover is possible. The neighbouring cell having the highest signal level value is always selected as the target cell for the handover. Handover decision algorithm for the UL handover reason
30
The functionality is similar to the downlink coverage reason. Operational aspects: The Inter-system HHO Measurement shows the triggering of RT and NRT hard handover per triggering reason. There are separate counters for intersystem handover attempt, success, failure and drop cases.
31
20. GSM - WCDMA Inter-System Handover

Functional description: The handover from GSM system to WCDMA system is handled like a new radio access bearer establishment. However, due to restrictions in the GSM system capability to transfer all the parameters needed for radio bearers in the WCDMA system, the RNC makes the mapping of the accessing RAB to the preconfigured radio bearer attributes. This preconfiguration information is then delivered to the UE through the GSM system. Operational aspects: The Service Level Measurement can be used to follow the success rate of GSM-WCDMA handovers.
32
21. Inter-RNC Intra-Frequency Hard Handover

Functional description: Intra-frequency hard handover is required to ensure the handover between cells controlled by separate RNCs in situations where the interRNC soft handover is not possible. Such a situation is for example missing the Iur interface. Intra-frequency hard handover decisions made by the RNC are based on the intrafrequency measurement results, which are usually applied to the soft handover procedure. There are no losses for the NRT radio bearer with intra-frequency hard handover but it causes a short disconnection of the RT radio bearer. Operational aspects: The operator can use the counters to follow the number of started and successful inter-RNC intra-frequency hard handovers. The counters belong to Intra-system HHO Measurement.
33
22. IMSI Based Handover

Functional description: The purpose of the IMSI-based handover feature is that a mobile subscriber visiting another network can be commanded to make handover measurements only to cells which belong to specified PLMNs. Accordingly, in such a scenario the mobile subscriber can only be handed over to those specified (home or authorised) PLMNs. The input for the selective measurement control is the PLMN id that is included in the IMSI of the subscriber. IMSI based-handover benefits the geographical sharing and common shared RAN concepts by enabling directed handovers from the shared WCDMA network to either the subscriber's home network or to another authorised WCDMA or GSM network when coverage becomes available. The functionality in these RAN-sharing concepts without IMSI-based handover is that same handover paths are allowed for all users and mobiles have to find the correct network outside the active call state. Nokia Multi-operator RAN concept does not require IMSI-based handover for RAN-sharing because different operators in the Nokia multi-operator RAN concept have their own cells with cell-specific neighbouring cell lists. IMSI based handover can be used in different cases: * Geographical sharing * Common shared RAN with gateway core * Virtual network operator The figure below shows the functionality of IMSI-based handover in the geographical sharing concept. In geographical sharing, operators cover separate areas and share networks via national roaming. However, there will be areas where both operators provide coverage (for example big city areas). IMSI-based handover directs the subscriber to its own or other authorised WCDMA network when coverage becomes available. A list of authorised PLMNs must contain maximum of six PLMN identifiers (MCC + MNC). The radio network database must have ten separate authorised PLMN lists. The RNC links the PLMN id of the subscriber with the desired list of authorised PLMNs by means of an index table, which may contain up to 128 IMSI ranges. Operational aspects: The operator can use the counters to follow the number of started and successful IMSI based handovers.
34
23. Dynamic Link Optimization for NRT Traffic Coverage

Summary: Dynamic link optimisation by decreasing the downlink bit rate ensures sufficient transmission quality of the radio link at the boundary area of the cell. Benefits for the operator: This feature increases the coverage area of the UE, ensuring sufficient transmission quality of the radio link until the handover is triggered. Functional description: The downlink power allocation algorithm, which defines the UE-specific maximum transmission power for NRT traffic, is based on the radio network planning (RNP) parameters: PtxDLabsmax and PtxDPCHmax. They are the planned maximum transmission power of a radio link including NRT RAB and the maximum allowed DPCH transmission power, respectively. However, the usage of a maximum bit rate possible may not be feasible in the whole range of a cell because the power constraints limit the bit rate allocation at the border area of a cell. In other words, when the highest possible transmission power is used, the UE-specific downlink transmission power cannot be increased anymore and this hinders the UE from receiving transmission with sufficient quality. With this feature the radio link is reconfigured to use a lower bitrate for the NRT radio bearer when the RNC detects the BTS transmitting the radio link with maximum power. Operational aspects: The Dynamic link optimisation for NRT traffic coverage (DyLO) is a part of RNC Packet Scheduler basic functionality and is always applied to the NRT PS data services. L3 Signalling at Iub measurement shows the number of radio link reconfigurations due to dynamic link optimisation.
35
24. Paging Channel State (Cell_PCH)

Summary: This feature enables the use of Cell_PCH state in addition to the Cell FACH and Cell_DCH states. Functional description: While the UE is in Cell_PCH state, the cell knows the location of the UE. The UE state transition to Cell_FACH state can be triggered from the network side by paging the UE in that particular cell. The UE is moved to the Cell_PCH state if there has not been any radio bearer activity during a predefined time period in Cell_FACH state. In Cell_PCH state the power consumption of the UE is significantly lower than in Cell_FACH state. When the UE is kept in the Cell_PCH state instead of moving it to the idle state, the radio resources can be allocated for the service fast. Thus, the end-user experience for example in browsing is better. Operational aspects: RRC Signalling Measurement can be used to monitor the state transitions from Cell_FACH to Cell_PCH.
36
25. Power Balancing

Summary: The feature prevents power drifting and therefore power drifting capacity losses during soft handovers (SHOs). Benefits for the operator: Power Balancing feature improves the radio capacity and quality in DL, and also end user experience in the case of indoor <-> outdoor transitions. The feature decreases Dynamic Link optimizations for PS traffic particurarly at cell edge areas. Power Balancing provides also OPEX savings on optimization of tuning SHO areas using common pilot channel (CPICH) individual offsets. Functional description: The power-balancing algorithm for preventing the power drifting is based on the Reference Transmission Power (Pref) calculated in the RNC. The Pref corresponds to the average DL transmission power of the radio links needed in SHO. The RNC periodically updates the Pref based on the transmitted code power measurements received from the BTSs. If a new Pref value differs from the previous value, the RNC sends the updated Pref to the BTSs. The power-drifting prevention algorithm in the BTS operates with the DL fast closed loop power control during a SHO. The algorithm calculates the required power correction based on the Pref and the current transmission power. The closed loop power control adjusts the transmission power according to the required power correction during a predefined adjustment period. Operational aspects: The BTS supporting this feature must be rolled out in the network before activating this feature. The operator will see the executed node B application part (NBAP) and radio network subsystem application part (RNSAP) procedures related to this feature through new and already existing counters. The counters are found in the L3 Signaling at Iub and Iur Measurements.
37
26. AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75)
Summary: AMR Codec sets feature adds the number of codecs that can be used to increase the air interface and Iub capacity or to enable the use of TFO/TrFO in 2G/3G calls. Benefits for the operator: CAPEX and OPEX savings are gained in core networks and transport. Savings are achieved with AMR Codec Sets because these allow the operator to utilize the Tandem Free Operation/Transcoder Free Operation (TFO/TrFO) functionality in 3G-2G calls. Increased number of speech users with lower codecs in RAN result increased revenue. Capacity gains are seen in the air interface and in Iub/Iur transmission. Functional description: The AMR lower codec modes 7.95, 5.90 and 4.75 kbit/s will be added to the supported codec modes from the CS CN. This feature allows three separately configured AMR mode sets: {12.2}, {12.2, 7.95, 5.90, 4.75} and {5.90, 4.75}. A new management parameter is introduced to enable the operator to configure the different AMR mode sets on cell basis. When an AMR call is established, the RNC will make an attempt to set up a radio bearer configuration using the maximum size of the configured AMR mode sets that is the subset of the assigned AMR modes and conforms to the maximum rate control principle required for TFO/TrFO support. Iu Support Mode 2, which is used with TFO/TrFO by standard, enables only the maximum rate control. If any of the configured AMR mode sets does not conform to the assigned AMR mode set maximum and the maximum rate control principle simultaneously, the maximum rate control principle is discarded and a new allocation attempt of the configured AMR mode set is made assuming that Iu UP support mode version 1 is used. If the AMR mode set of the assignment still does not conform to any of the configured AMR mode sets, the resource request is rejected. The configured AMR mode sets are applied in the resource allocation for the RAB assignment request and for the serving RNS (SRNS) relocation with involving UE in the target RNC. The same method is applied also for the SRNS relocation without involving UE. If the attempt fails, the AMR mode set of the relocation request is used for establishing the AMR RAB. If the resource request is received in the DRNC, the AMR mode set of the resource request is used as such. The addition of lower codec modes increases the number of transport format combinations and the UE capability limitation of the transport format combination set (TFCS) size can be met with the multi-RAB configurations. In case there is a UE restriction in the size of the TFCS and it is not possible to reduce the transport formats of a simultaneous interactive or background PS service, the allocated configured AMR mode set is reduced so that the UE continues to use the lowest AMR codec mode of the set. For example, the three highest AMR codec modes are removed, that is, the UE continues using the AMR codec mode 4.75, when the configured set {12.2, 7.95, 5.90, 4.75} has been allocated. The RNC will use Transport Channel Reconfiguration, Radio Bearer Reconfiguration or Radio Bearer Setup messages for restricting the TFCS towards the UE. In addition, the DL codec modes towards the Iu interface are restricted with the Iu UP rate control procedure. The TFCS restriction could also be achieved by removing the three lowest codec modes, but this method does not conform to the maximum rate control principle. Furthermore, the codec modes are not removed one by one since that would not be compliant with the test cases defined in 3GPP TS 34.108. The new codec modes can be used with TFO/TrFO with the restrictions described above. In the
UL direction, the rate control will be done using the Transport Format Combination Control (TFCC) procedure based on the maximum rate control received from the Iu interface. In the DL direction, the RNC will select the transport format based on the AMR RAB sub-flow combination received from Iu UP. When the {5.90, 4.75} mode is allocated for the AMR connection, the spreading factor of the DL code channel will be 256 by default. The SRB bit rate is 3.4 kbit/s. This feature can be switched on and off on RNC basis. If the feature is off, only AMR 12.2 will be used as currently. In that case, the TFO/TrFO can be used for capacity enhancement in the CN but not, for example, for 2G link adaptation purposes. The RNC needs to match the support of the selected AMR codec modes with the AMR codec modes and the Iu UP support mode version alternatives offered by the CN. The selection is made in the following way: - If the core network supports both Iu Support Mode versions 1 and 2, the RNC may use version 2 only if TFO/TrFO is enabled in the RNC. - If the core network supports mode 2, the RNC selects version 2 for the first allocation attempt: the AMR modes of the assignment must include the set of {12.2, 7.95, 5.90, 4.75}, {12.2} or {5.90, 4.75} (based on the feature switch) as a subset, which enables the maximum rate control. - If the core network supports version 1, the RNC can select between the sets {12.2, 7.95, 5.9, 4.75}, {12.2} and {5.9, 4.75} if it is a subset of the assigned AMR mode set. Operational aspects: The operator can monitor the allocation of the different AMR codec sets and downgrades of AMR bit rates through the already existing counters. The counters are found in the Traffic Measurement. The BTS supporting this feature must be rolled out in the NW before activating this feature.
39
27. Wideband AMR Codec Set (12.65, 8.85, 6.6)

Summary: Wideband AMR speech codec enhances audio bandwidth from 300Hz - 3.4 KHz to 50Hz - 7kHz, which improves the transparency of calls. Enhanced lower frequency response makes voice warmer whilst enhanced higher frequency response improves intimacy of voice. Benefits for the operator: Wideband AMR provides step-like improvement on voice quality over current telephony solutions without RAN capacity trade-offs since the bit rates are similar to AMR. The TrFO/TFO needed due to wideband AMR (WB-AMR) will reduce the need of CN investments. Functional description: This feature supports a set of WB-AMR codec modes 12.65, 8.85 and 6.6 kbps. WB-AMR provides better speech quality than narrowband AMR (NB-AMR) and fixed lines (G.711 PCM) between WB AMR capable UEs. To avoid down sampling from 16kHz to 8kHz, yielding to quality degradation, either TFO or TrFO is needed. The RNC handles the WB-AMR modes as well as Multi RABs similarly to NB-AMR. The codec modes 12.65, 8.85 and 6.6 kbps form a set of bit rates (TFS) that is assigned to every WB-AMR call. The limited TFCS in multi-RAB cases, the functionality of TFO/TrFO and managing the Iu Support Mode are similar to the feature AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75). Operational aspects: This feature can be switched on and off with an operatorcontrollable parameter. If the feature is off, the RNC rejects all WB-AMR calls. In addition, WB-AMR must be enabled at the same time in all RNCs in the operators NW. The mobility between the RNS is not otherwise possible for WB-AMR calls (the radio link setup over Iur interface fails as well as SRNC relocation fail). The BTS supporting this feature must be rolled out in the network before activating this feature. The operator can follow up through new counter the setups and durations for each available WBR AMR codec.
40
28. Bsic HSDPA with QPSK and 5 Codes

Summary: This feature provides the basic High Speed Downlink Packet Access (HSDPA) functionality. HSDPA is based on a technique where scheduling, link adaptation and physical layer retransmission handling is in the BTS, improving the downlink packet data performance with the achieved high throughput and peak rates and reduced delays. Benefits for the operator: HSDPA offers a lower cost per bit and potentially creates new application areas with higher data rates and lower delay variance. This feature brings the basic performance gain of HSDPA to the operator, that is, a cell throughput gain of up to 60%, as well as higher peak data rates up to 1.8Mbps. Functional description: This feature allows a 1.8 Mbps air interface peak rate with QPSK modulation. Only a single High Speed Shared Control Channel (HS-SCCH) taking care of the HSDPA downlink signalling needs is required, as code multiplexing is not supported. HS-DSCH is transmitted only to one cell at a time from the BTS, that is, it is time multiplexed between the different cells of the BTS. The basic characteristics of the feature are listed below: * Maximum number of HSDPA users per BTS is 16 * Maximum HS-PDSCH codes per cell is 5 * Maximum HS-SCCH codes per cell is 1 * Maximum HS-PDSCH codes per UE is 5 * HSDPA channel encoding/decoding functionality includes HS-DSCH and HS-SCCH encoding in the downlink and HS-DPCCH decoding in the uplink * HSDPA ARQ handling in MAC-hs * HS-DSCH link adaptation based on CQI from the UEs * Up to 3 cells per BTS can be enabled for HSDPA. Even though the maximum number of the HS-PDSCH codes is 5 per UE, all the UE categories (1-12) are still supported. Other categories will be treated in the same way as categories 11-12. Operational aspects: In the BTS platform, HSDPA is implemented on top of WSPC cards. Sufficient baseband processing resources need to be allocated for each BTS using HSDPA. The operator can follow up through the counters HSDPA usage. The counters will be added to the Service Level Measurement. HSDPA requires that all CDSP cards in the RNC are of level C or later.
41
29. HSDPA BTS Packet Scheduler

Summary: The HSDPA BTS Packet Scheduler is a fast BTS based scheduler determining the bit rates to be used for HSDPA services. Benefits for the operator: The HSDPA BTS Packet Scheduler with round-robin principle is a robust scheduler for achieving good HSDPA cell throughput. Functional description: Round-robin scheduler is used for the MAC-hs packetscheduling algorithm serving users in sequential order. It is a robust scheduler achieving resource-fair HSDPA cell throughput. On the average, the UEs close to the BTS get clearly higher bit rates than users on the cell edge. Those users with no data ready for transmission in the BTS buffer are not considered for scheduling. Operational aspects: Through the RAN Level KPIs and counters, the operator can follow on the received and discarded MAC-d data, total and re-transmitted amounts of MAC-hs data and MAC-hs retransmissions per UE capability class and the used number of codes. The counters belong to HSDPA in WBTS Measurement.
42
30. HSDPA Proportional Fair Resource Packet Scheduler

Summary: The high-speed downlink packet access (HSDPA) Proportional Fair Packet Scheduler feature provides a multi-user diversity gain of 30%-60% in terms of improved HSDPA cell throughput for low to medium UE speeds, depending on the environment. Benefits for the operator: Improved end user experience is acquired by increased HSDPA cell throughput. Functional description: The proportional fair resource (P-FR) algorithm is used for the MAC-hs packet scheduling in the BTS. This algorithm utilises the radio channel state information from the UEs in its scheduling decisions. The P-FR principle is to select one UE among those active users that have data in their buffers and are not limited by their capabilities for selection, to maximize the relative instantaneous channel quality (ratio of instantaneous throughput to average throughput) for scheduling in the following 2ms transmission time interval (TTI). The relative stantaneous channel quality is calculated in every 2 ms TTI.
43
31. HSDPA Flow Control

Summary: HSDPA Flow Control ensures that HSDPA capacity and user throughputs can be achieved by having enough data available in the BTS to match with air interface capacity. The flow control prevents packet losses and excessive buffering delays. Benefits for the operator: Enables HSDPA. Efficient flow control increases the enduser experience by providing high application throughput with low delay. Functional description: HSDPA Flow Control ensures that the BTS buffers have enough data for the transmission needs. On the other hand, it minimises the buffering time in the BTS and prevents the overflow in the BTS buffer by avoiding discarded and retransmitted data. The BTS flow controller monitors the buffer status and measures the throughput for each queue.,The capacity allocation towards the RNC is updated based on the buffer status monitoring and the throughput measurements. Operational aspects: Ultrasite/FlexiBTS: The operator can use the RAN Level KPIs and counters to follow the received, sent and discarded RLC AM SDU data and the total and re-transmitted amounts of RLC AM PDU data. The counters belong to Radio Connection Performance for RLC AM Measurement.
44
32. HSDPA Resource Allocation

Summary: This feature provides spreading codes and transmission power management for HSDPA. Benefits for the operator: This feature enables HSDPA and brings the basic performance gain of HSDPA to the operator. Functional description: The RNC allocates the HSDPA spreading codes and sends the code information to the BTS. Five codes (SF = 16) are always allocated for HSPDSCH and one code (SF = 128) for HS-SCCH. The codes are kept reserved independently from the HSDPA usage. The maximum transmission power that can be used for HSDPA in a cell is defined by the cell specific management parameter. The power allocation is signalled from the RNC to the BTS together with the code information after the cell setup. In addition to the maximum HS-PDSCH and HS-SCCH power allowed, the operator can define a power level below which the HSDPA power allocation can be taken into use. The operator can also define a separate power level threshold above which HSDPA power allocation should be released. Furthermore, there is a parameter defining whether the HSDPA is given a higher or lower priority compared to the NRT on DCH. When the RNC allocates the first MAC-d flow to the cell, the HSPDA power allocation is taken into use. In order to take the HSDPA power into use, the total transmission power of the Rel-99 channels in the cell is required to be below a cell specific parameter. This parameter is used as a DL load target threshold for Rel-99 channels instead of PtxTarget as long as any MAC-d flow exists in the cell. Operational aspects: The operator can use counters to follow the HSDPA power levels. The counters belong to Cell Resource Measurement.
45
33. HSDPA Channel Switching

Summary: This feature determines whether the HS-DSCH is allocated to the user. Benefits for the operator: This feature enables HSDPA and allows operator configurable channel type selection. Functional description: The decision to allocate HS-DSCH is based on several issues including UE capability, cell resource availability, UE handover status and UE multi RAB configuration. Further inactivity detection is used to determine how long to keep the HS-DSCH reserved for a given user. Specific priority classes can be configured for interactive NRT data so that HSDPA will not be used for those services, for example to avoid PoC from being mapped on HSDPA. Also, it can be separately defined whether the background class will be allocated on HSDPA.
Operational aspects: The operator can use the RAN Level KPIs and counters to follow the started HS-DSCH setup requests and setup success vs. failures. If a UE capacity request is selected to be started as the DCH setup, the existing counters can be used. The counters belong to Traffic Measurement.
46
34. HSDPA Shared Control Channel Power Control

Summary: High Speed Shared Control Channel (HS-SCCH) Power Control adjusts the HS-SCCH transmission power based on the required power level at the UE. Average HS-SCCH transmission power is reduced and HSDPA cell throughput gain of 5%-20% is achieved. Benefits for the operator: HS-SCCH power control increases the end-user experience by providing better HSDPA throughput. Another benefit is CAPEX and OPEX savings due to reduced transmission power resulting in improved downlink radio capacity. Functional description: This feature adjusts the High Speed Shared Control Channel (HS-SCCH) transmitting power according to the required power level at the UE. It reduces the average power overhead required for the HS-SCCH, compared to using a fixed transmit power level. The HS-SCCH transmit power is adjusted every TTI based on the CQIs and Ack/Nack/DTXs received from the UEs. It is estimated that the HSDPA cell throughput gain provided by this feature is 5%-20% (compared to using fixed HS-SCCH power), depending on the environment and the total power allocated to HSDPA. Operational aspects: The operator can use the counters to follow the HS-SCCH power levels in each WCELL. The counters belong to HSDPA in WBTS Measurement.
47
35. HSDPA Associated Uplink DPCH Scheduling

Summary: This feature selects the data rates that are used for the HSDPA associated uplink return channel.
Benefits for the operator: This feature enables the HSDPA and allows the operator to select the preferred bit rate to be used for HSDPA associated uplink DCH. Functional description: The resource scheduling for the HSDPA associated uplink return channel is based on two parameters: initial bit rate and minimum bit rate. These parameters are cell specific configuration parameters. The bit rates used in the scheduling are 64 kbps, 128 kbps and 384 kbps. The initial bit rate is allocated as an uplink return channel bit rate when HS-DSCH is selected as a DL transport channel. Once the DCH has been configured, the UE may use the TFC selection to momentarily use a lower data rate, for example in the case of power limitations or lack of data to be transmitted. There is an exception to the usage of the initial bit rate: if HS-DSCH selection is performed due to UL capacity request indicating a high data amount, the highest possible bit rate is allocated. The minimum bit rate is the lowest bit rate allowed for the UL DCH for load control purposes. The UL DCH can be reconfigured down to this bit rate due to the following functionalities: * RAB Pre-emption (other call may override) * RT over NRT * Decrease of the Retried NRT DCH Bit Rate * Enhanced Priority Based Scheduling * Upgrade of the NRT DCH Data Rate (from initial or lower bit rate) These procedures will prevent the uplink resources being tied up for example for only a few 384 kbps users in case of a resource shortage. The upgrade of the UL DCH is controlled by traffic volume measurement. The traffic volume measurement is active when the allocated bit rate is equal to or lower than the initial bit rate. Operational aspects: The operator can use the counters to follow the setup requests and successful setups vs.setup failures of the uplink return channels. The counters belong to Traffic Measurement.
48
36. HSDPA 16QAM Support

Summary: This modulation enables 3.6 Mbps HSDPA peak data rates and higher average cell throughput. Benefits for the operator: Improved end-user experience due to increased HSDPA peak data rates. 16QAM support increases the peak data rate with a factor of two compared to a basic HSDPA solution. Functional description: This feature increases the HSDPA peak data rate from 1.8 Mbps (QPSK with 5 codes) to 3.6 Mbps with the use of higher order modulation (16QAM). The link adaptation algorithm in the BTS (MAC-hs) selects 16QAM when the channel quality is sufficient. It also provides 5%-20% higher average HSDPA cell throughput, depending on the environment. Operational aspects: The feature limits the maximum amount of HSDPA users per BTS to 12. This applies to all BTSs under the RNC. The operator can use the counters to follow the number of 16QAM capable UEs. The counters belong to Service Level Measurement.
49
37. HSDPA Cell Reselection

Summary: Intra-frequency mobility for the HSDPA users is implemented via Cell_FACH RRC state. Benefits for the operator: This feature enables HSDPA. Functional description: Based on measurement reports (event 1a: branch addition) from the UE, the RNC makes the decision to transfer the UE into Cell_FACH state. In the Cell_FACH state, the UE performs the cell reselection procedure to select the strongest cell. The resource allocation in the Cell_FACH state is the standard algorithm based on UL and DL capacity requests. The HS-DSCH can be selected in a normal channel type selection, if the conditions for HS-DSCH selection are fulfilled. From the point of view of mobility, a precondition for the HS-DSCH allocation is that the UE has an active, set size of the allocation and there are no other compressed measurements going on. These conditions do not prevent HS-DSCH allocation initiated in Cell_FACH state. To prevent immediate and recurring cell reselections, the HSDPA specific intrafrequency measurement and handover control parameters are recommended to be set to trigger the HSDPA cell reselection only when the target cell is stronger (that is, has better CPICH Ec/No) than the source cell. For the HSDPA cell reselection to succeed, the HSDPA service areas of neighbouring cells need to partly overlap. Operational aspects: The separate intra-frequency measurement and handover control parameter sets for HSDPA UEs are implemented by including a HSDPAspecific identifier in the WCEL parameters.
50
38. HSDPA 15 Codes

Summary: HSDPA 15 Codes allows higher peak rates as well as larger capacity. The average cell throughput is increased by about 50% in a macro cell environment compared to having 5 codes. The peak bit rate for single user is 7.2 Mbps. Peak cell level total throughput is 10.8 Mbps (with code multiplexing). Benefits for the operator: Higher data rates improve the end user experience. HSDPA 15 codes provides more cell capacity compared to HSDPA 10 codes solution. New data service availability results increased revenue. Increased cell capacity means savings in CAPEX and OPEX. Functional description: HSDPA 15 Codes feature is a further evolution for the features Basic HSDPA with QPSK and 5 Codes and HSDPA 16 QAM Support allowing higher peak data rates and increased average cell throughput. The peak bit rate for single user is 7.2 Mbps. Peak cell level total throughput is 10.8 Mbps (with code multiplexing). Depending on the UE category, the RLC payload size of 640 bits may be used when the HSDPA 15 Codes is enabled. HSDPA 15 Codes allows higher peak rates as well as larger capacity. The average HSDPA cell throughput depends on the maximum number of allocated HS-PDSCH codes. When allocating the maximum of 10 HS-PDSCH codes, the average cell throughput is increased by about 30% in a macro cell environment compared to having only 5 HS-PDSCH codes. Allocating the maximum of 15 HS-PDSCH codes increases the average cell throughput by about 50% compared to the same 5 code reference scenario. In a frequency layer dedicated for HSDPA, the gains are significantly higher, as well as in micro cells. Operational aspects: The maximum and sustained user data rates may be lower than the air interface peak bit rate depending on the number of simultaneous HSDPA users, RNC, BTS processing capacity and Iub dimensioning. Whole UltraSite WSPC card(64 CE)/Flexi BTS sub-module(80CE) is required to enable HSDPA with 15 codes to the cell. With code shared HSDPA scheduler, up to three cells in the BTS can be handled by one UltraSite WSPC/Flexi BTS sub-module. HSDPA 15 codes requires also the HSDPA Dynamic Resource Allocation feature to operate and for dynamic adjustment of the cell resources. HSDPA 15 codes feature enables the HSDPA code multiplexing by allocating more than 5 HS-PDSCH codes to the cell. It is recommended to use the HSDPA Code Multiplexing together with this feature as part of the terminals will be 5 HS-PDSCH codes capable. With 15 codes supported by the NW and 5 codes by the terminal, the maximum number of simultaneous users that is beneficial from spectral efficiency point of view is 15/5=3. The operator can follow up through new counters the number of original and retransmissions (separate counters) with 6-15 codes per used modulation (QPSK, 16QAM). There are already the corresponding counters for 1-5 codes. HSDPA 15 codes requires whole UltraSite WSPC card/Flexi BTS sub-module of processing capacity to be reserved for 1-3 cells, depending on the required throughput and number of users. Shared HSDPA scheduler for BB efficiency feature (WSPC or Flexi BTS sub-module per 2-3 cells) can provide upto 48 users per scheduler, and 10.8 Mbps throughput per scheduler. Cell dedicated scheduler (WSPC or Flexi BTS submodule per cell), can provide upto 48 users per cell and 14.4 Mbps throughput per cell. HSDPA 48 users per cell is a separate feature, without it 16 users per cell is supported.
51
39. HSDPA Code Multiplexing

Summary: HSDPA code multiplexing enables simultaneous transmission of (max) three HSDPA users within a single cell during a single Transmission Time Interval (TTI). Code multiplexing improves the code resource utilization and subsequently, improves the cell throughput 30-50% and beyond. Benefits for the operator: Improved end user experience is acquired thanks to better cell throughput in the case of simultaneous users supporting maximum 5 codes. CAPEX and OPEX savings result from increased cell capacity. Functional description: This feature allows sending data packets to more than one HSDPA user simultaneously in each 2ms TTI. Code multiplexing can be used when at least two high-speed secondary control channel (HS-SCCH) codes are allocated by the RNC. With this feature 2-3 users can be code multiplexed on HS-PDSCH depending on HS-PDSCH and HS-SCCH allocation. The available code and power resources are evenly shared between the scheduled users. Decision on how many users are scheduled per cell is done independently on each TTI. The general rule is that when the UE category with the highest scheduling metric from proportional fair scheduling algorithm is supporting less codes than the cell has available, then potentially (in case the first user cannot use all the available power) a second UE is scheduled as well. The second UE to be scheduled is the one with the second highest scheduling metric. If the two scheduled UEs are both supporting max 5 codes each, then a third user is potentially scheduled as well. Note that code multiplexing does not provide any throughput gains in a case where the UEs support as many codes as the NW. In such a scenario, the optimal strategy from spectral efficiency point of view is to schedule a single user at a time. This decreases the power spent for control channels (only one HS-SCCH needed instead of several) and increases the gain from proportional scheduling. With code multiplexing it is possible to use code space larger than five codes also with UEs that support only five codes. The NW capacity gain from code multiplexing is similar to gain from 15 codes in the case where most of the users are supporting maximum 5 codes. Operational aspects: HSDPA code multiplexing is possible only when more HSPDSCH codes are allocated in the BTS than the UEs in the NW can support (otherwise cell level code multiplexing does not bring any capacity gain). Thus the prerequisites for this feature are the activation of the feature HSDPA 10 Codes or HSDPA 15 Codes and a code allocation of more than one HS-SCCH and more than 5 HS-PDSCHs per cell in the BTS. As more than 5 HS-PDSCH codes are required, HSDPA Dynamic Resource Allocation feature is required as well for dynamic adjustment of the cell resources. The operator can see through new counters the number of multiplexed users for each TTI in each cell.
52
40. HSDPA Mobility Handling with DCH Switching

Summary: For the inter-frequency and inter-system mobility the HSDPA users are changed temporarily to DCH. Benefits for the operator: This feature enables HSDPA and introduces separate hard handover management parameters for HSDPA-UEs. Functional description: Inter-frequency and inter-system mobility for the HSDPA users is implemented with the approach that once there is a need to perform intersystem or inter-frequency measurements, the radio bearer is mapped to the DCH of 0 kbit/s (the user has only a signalling radio bearer active). To prevent immediate and recurring HS-DSCH allocations a UE-specific guard timer must be set after the channel switching from HS-DSCH to DCH, if the channel switching was performed due to handover reasons. HS-DSCH transport channel is not allowed for the UE during that guard time period. The timer is configurable and concerns the particular UE in all the cells under one RNC. When the timer has expired, HS-DSCH allocation to the UE is allowed again. It is possible that the DCH of 0 kbit/s is upgraded to some higher DCH bit rate, if a capacity request is received while the guard timer is running. Separate parameter sets can be defined for HSDPA-UEs for controlling the interfrequency and inter-RAT handovers. Operational aspects: Separate inter-frequency and inter-RAT measurement control parameter sets for HSDPA UEs are implemented by including a HSDPA-specific identifier in the WCEL parameters. The operator can use the counters to follow the channel switching from HS-DSCH to DCH. The counters belong to Traffic Measurement.
53
41. HSDPA Serving Cell Change

Summary: This feature enables direct mobility from the HS-DSCH in one cell to the HS-DSCH in another cell. Benefits for the operator: The end use experience is improved due to the enhanced HSPA performance during HOs. Functional description: The HSDPA Serving Cell Change is a HS-DSCH to HSDSCH HO that can happen either - intra-BTS intra-RNC or - inter-BTS intra-RNC The main input for selecting the serving cell are periodical UE's intra-frequency measurement reports for the quantity CPICH Ec/N0. The operator can control the sensitivity of the serving cell change. For all cases, the MAC-hs of the source cell is reset upon the serving cell change and the RLC protocol takes care of the retransmission of the data to the target cell. This feature provides the operator with better performance since the best available radio condition in the active set is used for HS-DSCH. Operational aspects: The serving cell is selected from the active set cells, so the feature HSDPA Soft/softer Handover for Associated DPCH is required for this functionality. Inter-RNC and inter-frequency serving cell change functionalities are not supported. The operator can select whether the HSDPA serving cell change or DCH switching with cell reselection is used for handling the mobility of the HSDPA users. When the HSDPA serving cell change is selected, switching to DCH may still be needed in bad radio conditions. The BTS supporting this feature must be rolled out in the NW before activating this feature. The operator can monitoring the HSDPA Serving Cell Attempts (by reason) and outcome through new counters. The counters are added to the Intra System HHO Measurement. The BTS supporting this feature must be rolled out in the network before activating this feature. The Operator can monitoring the HSDPA Serving Cell Attempts (by reason) and outcome through new counters. The counters are added to the Intra System HHO Measurement.
54
42. HSDPA Dynamic Resource Allocation

Summary: Dynamic HSDPA channelisation codes allocation enables full cell resource utilization, better end-user experience and increased NW capacity. Benefits for the operator: Gain in cell throughput is achieved as the cell resources are better utilized for varying traffic mix. Operator control on resource division between NRT DCH and HSDPA allows flexible support of different pricing strategies for DCH and HSDPA data. Functional description: NodeB will dynamically control the amount of power used for HSDPA, the HSDPA power can be controlled each TTI, i.e. in 2 ms interval. All the power left after DCH traffic, HSUPA control channels and common channels is used for HSDPA. This means that as long as there is HSDPA traffic in the cell, all the available PA power can be efficiently utilized. RNC will still schedule the NRT DCH bit rates. The higher bit rates the RNC allocates for NRT DCHs, the less there is "spare" power that the NodeB can use for HSDPA. To avoid situations where very unfair distribution of power is created between HSDPA and NRT DCH users, the RNC will take into account both the current number of NRT DCH and HSDPA users in the cell when allocating NRT DCH bit rates. By default, the RNC will treat NRT DCH and HSDPA users equal in the sense that NRT DCH bit rates are allocated in such way that roughly equal amount of tx power per user will be available to both NRT DCH users and HSDPA users. This does not mean that each user would have equal bit rates. It simply means that if in a 20 W cell there happens to be 8 W of RT & common channel load, then about 12 W is available for NRT traffic. This 12 W is then divided so that in case of 2 NRT DCH users and 10 HSDPA users, about 2 W would be given to DCH side and 10 W to HSDPA side. The RNC does not directly guide the NodeB in allocating the power for HSDPA, but the RNC does affect this implicitly by decision of NRT DCH bit rates. On an operator choice, the priority between NRT DCH and HSDPA can be weighted so that power is aimed to be spent in relation p1 : p2, where p1 represents the target tx power per user available for NRT DCH and p2 the target tx power per user available for HSDPA. In addition, users with higher Traffic Handling Priority (THP) can be counted more important when deciding the division between power for NRT DCH side and HSDPA side. THP is not taken into account in actual HSDPA scheduling, but all HSDPA users are given roughly equal resources according to proportional fair scheduling principle. The code allocation is dynamically following the power allocation. In practice this means that once the NRT DCH bit rates have been decided, based on equal power criterion, the code requirements for the DCH side have been fixed. All other codes are then given to the HSDPA (operator may leave some margin to allow fast voice call allocation). In case of new DCH connections (for which the bit rate is again determined based on power criteria), the required amount of HSDPA codes are given back to the DCH. Operational aspects: The BTS SW version required for this feature must be updated to the NW before activation of the feature in the RNC. The operator can control whether to favour the NRT DCH or HS-DSCH via the RNC management parameters. This is possible for both codes and power. For power the PtxTargetPS threshold is set dynamically by observing the non-HSDPA power and PtxTotal. The PtxTargetPS is a new target for the NRT DCHs that is adjusted by the RNC, so that power per user on DCH side and on HSDPA side is roughly equal unless unequal priorities have been set. The operator can also set PtxTargetPSmin that guarantees the minimum NRT DCH power over HSDPA. The RT DCHs always follow the existing PtxTarget threshold. The operator
55
can follow up through: 1) New counters when the UE accesses the HS-DSCH related to state transition from CELL-FACH, 2) The allocation durations of different HSDPA Codes (0, 5, 6-15) in each cell (counters for codes 6-15 only updated if supporting features are taken into use), 3) The times when a HS-DSCH setup happens directly from DCH, 4) The number of requested SF in each cell and 5) The average and maximum PtxTargetPS used. There are already existing counters for the HSDPA power levels in each WCELL (specific to Ultrasite and FlexiBTS).
56
43. Basic HSUPA

Summary: This feature provides the High Speed Uplink Packet Access (HSUPA) functionality, also known as Enhanced Uplink DCH (E-DCH). HSUPA functionality is based on the following techniques: - BTS controlled scheduling of the E-DCH within the limits set by the RNC - Physical layer retransmission handling in the BTS Benefits for the operator: Increased UL average and peak data rates improve the end user experience. CAPEX and OPEX savings result from increased cell UL capacity and increased Iub and BTS HW efficiency. New data service availability increases revenue. Functional description: The basic characteristics of the feature are listed below: - HSUPA is supported only with co-existence of HSDPA. - All cells in the BTS can be enabled for HSUPA. - Maximum number of HSUPA users per BTS is 24 (in larger than 6 cell configurations two local cell groups have to be used, and then HSUPA is handled independently on both local cell groups). The maximum number of HSUPA users in a cell is 20, limited by available signatures in E-RGCH/E-HICH channels. One E-AGCH and one ERGCH/E-HICH code channels are configured to each serving E-DCH cell. Maximum number of simultaneous HSUPA serving users is 19 in a cell, and one signature is reserved for non-serving HSUPA users. - Operator can choose to set a lower threshold to the maximum number of users per cell and per BTS. - TTI of 10 ms is used for maximizing the resulting UL range. - The largest supported E-DCH category is 3 (1.44 Mbps), corresponding to two parallel codes of spreading factor four (2xSF4). - HSUPA activation requires a static reservation of UltraSite WSPC card/Flexi BTS sub-module) capacity. Rest of the HSUPA baseband capacity is fully pooled across cells, and also dynamically shared with R'99 traffic. Up to two UltraSite WSPC cards/Flexi BTS sub-modules can be in HSUPA use, R'99 traffic allowing. For Ultrasite BTS it is possible to enable HSDPA and HSUPA in three sectors on a single shared WSPC card, using HSDPA 16 users per BTS scheduler. This allows operators to roll out fast and cost efficient HSUPA service. In case of high capacity UltraSite BTS HSPA sites, operator can select as alternative HSUPA activation on separated WSPC cards. WSPC (64 CE) per BTS or WSPC per cell for HSDPA can be used to increase HSDPA capacity. These together provide high capacity HSPA solution. - The maximum peak data rate per user is 1.44 Mbps as coded L1 bit rate (error protection coding is not counted into bit rate but L1 retransmissions are). - One UltraSite WSPC card/Flexi BTS sub-module supports up to 24 HSUPA users - The minimum combined L1 baseband throughput of all users per UltraSite WSPC card/Flexi BTS sub-module is 4.2 Mbps. - HSUPA channel coding functionality includes E-DCH Absolute Grant Channel (EAGCH), E-DCH Relative Grant Channel (E-RGCH) and E-DCH Hybrid Automatic Repeat Request (ARQ) Indicator Channel (E-HICH) encoding in DL and E-DCH Dedicated Physical Data Channel (E-DPDCH) and E-DCH Dedicated Physical Control Channel (E-DPCCH) decoding in UL.
57
- HSUPA Hybrid Automatic Repeat Request (H-ARQ) operation handling per UE in EDCH Medium Access Control (MAC-e) entity within a BTS. - HSUPA Service Indicator is supported. The total cell data rate for HSUPA users is scheduled between the HSUPA capable UEs in a cell. Scheduling is performed by the NodeB in a fast cycle by using mainly relative grants. All UEs get as much bit rate as they can send in non-congested case. In case of congestion, roughly equal noise rise contribution is allowed for each user. For facilitating smooth mobility operations with non-HSUPA capable BTSs, Signalling Radio Bearer (SRB) is mapped on DCH. HSUPA traffic is mapped on a dedicated Iub virtual channel connection (VCC), allowing Iub capacity consumption be optimized for NRT HSUPA traffic, while preserving the QoS of real-time services, which are mapped on another VCC. The operator may also configure a minimum service level for HSUPA by dedicating a minimum amount of baseband channel elements (CEs) for HSUPA. HSUPA improves the UL packet data performance by providing higher data rates over the whole cell area, increasing the peak data rate and reducing delay. HSUPA also increases the system capacity by improving the cell throughput and the efficiency of the transport and BTS hardware resources. HSUPA benefits are especially significant for bursty high bit rate applications. In a non-congested, single user case the maximum bit rates are greatly improved, since instead of practical maximum of 384 kbps with R'99, 1.4 Mbps can be reached with HSUPA. In a loaded NW with congestion, the capacity gain from HSUPA is expected to be on the order of 20%-50%. HSUPA Service Indicator indicates the HSUPA capability to the UEs. HSUPA capable cell means that the UE may consider this cell/any cell in the same sector as part of the HSUPA coverage area to display HSUPA service indication. Operational aspects: HSUPA will dynamically share the baseband capacity with DCH traffic. The operator may commission a minimum fixed reservation for HSUPA, but the rest of the capacity is dynamically allocated to HSUPA when DCH does not need it. As default, 8CE reservation is done when the first HSUPA cell is configured to the local cell group. The operator can follow the capacity need from the counter indicating the number of HSUPA capable UEs in the cell. The operator can through new counters: 1) See the number of HSUPA capable UEs per cell, 2) See the average and maximum number of used CEs for HSUPA, 3) See the power levels of the HSUPA DL Physical Channel, 4) See the power levels of the HSUPA E-DCH Channels, 5) See the number of HSUPA users per cell. HSDPA Dynamic Resource Allocation feature is required for HSUPA. Iub re-configuration is required for HSUPA.
58
44. HSUPA BTS Packet Scheduler

Summary: HSUPA BTS Packet Scheduler is a fast BTS based scheduler determining the bit rates to be used on E-DCH. Moving packet scheduling from the RNC to BTS is the key change in HSUPA compared to Rel'5. The BTS is able to make much faster decisions when the RNC does not have to be consulted. This increases the efficiency at which especially bursty data can be treated by the packet scheduler. Benefits for the operator: Increased UL data throughput improves the end user experience. In addition, increased cell UL capacity results CAPEX and OPEX savings. Functional description: HSUPA BTS Packet Scheduler (PS) is a cell specific scheduler using 10 ms scheduling periods with both Absolute Grants (AG) and Relative Grants (RG). The scheduling decisions are based on the maximum allowed noise rise, minimum throughput and the physical layer feedback from the UEs in a cell. The HSUPA BTS PS also takes into account the available baseband resources not needed for R'99 DCHs. In a case where air interface and NW resources are not limiting the data rates, each UE is given as much bit rate as they request, up to maximum of 1.44 Mbps. The scheduling grant determined by the PS is applicable to all HARQ processes of the UE (Refer to HSUPA Congestion Control). Operational aspects: The operator can follow up through new counters the total and re-transmitted amount of MAC-e data in the BTS.
59
45. HSUPA Handovers

Summary: This feature brings soft/softer handovers and serving cell changes for HSUPA users allowing HSUPA in the whole cell coverage area and between the cells. Benefits for the operator: This feature enables full mobility for the HSUPA users and widens the coverage area of a given bit rate. The gain is significant especially with high bit rates. Soft handover (SHO) gain for E-DCH is similar in magnitude to traditional R'99 DCH SHO. Functional description: The following intra-frequency soft/softer handovers are supported for E-DCH: - Intra BTS intra RNC softer handover, - Inter BTS intra RNC soft handover. In case of SHO, the active set for DCH can be different from the active set for E-DCH. This allows adding a cell not supporting E-DCH into the active set. In addition, in case of inter-BTS inter-RNC soft handover, the E-DCH will not be configured to a SHO branch under the drift RNC. The serving E-DCH cell follows the serving cell for HSDSCH of the UE. Thus the algorithms of HSDPA are followed. The HS-DSCH and EDCH serving cell is always the same cell. DCH to E-DCH channel switching is carried out if there is a need to change the serving DCH cell into a cell supporting E-DCH. E-DCH to DCH channel switching is carried out if there is a need to change the serving E-DCH cell into a cell not supporting E-DCH or a cell under the drift RNC. E-DCH to DCH channel switching is also needed before compressed mode is activated for inter-frequency or inter-system measurements. E-DCH to DCH channel switching is carried out if there is a need to change the serving E-DCH cell into a cell not supporting E-DCH or a cell under the drift RNC. E-DCH to DCH channel switching is also needed before compressed mode is activated for interfrequency or inter-system measurements. Operational aspects: The benefits from E-DCH SHO are best achieved when all the cells in a particular area are HSUPA enabled. Having only DCH-capable cells among E-DCH cells does not allow optimal UL power control to be applied. DCH only cells can be added to DCH active set of the E-DCH call, but they are not able to affect to the used E-DCH power. Through new counters the operator can monitor the HSUPA Serving Cell changes and SHO related to the HSUPA Active Set. Hardware requirements: Pico BTS supports 12.7 Mbps
60
46. HSUPA Congestion Control

Summary: With HSUPA Congestion Control, the RNC detects congestion on the Iub and notifies the BTS about the congestion. HSUPA packet scheduler in the BTS takes actions on the air interface to reduce the congestion. By preventing congestion on the Iub, the feature prevents radical loss of throughput when the RLC retransmissions start to accumulate due to Iub congestion. This allows tighter Iub dimensioning to be used. Additionally, mobiles do not generate extra interference by sending data that cannot be forwarded to the RNC by the BTS. Benefits for the operator: CAPEX and OPEX savings are achieved by increased Iub efficiency and cell UL capacity. Congestion control is the enabler for efficient Iub with HSUPA. Also UL capacity is improved by avoiding loss of packets, which are already sent over air interface. The end user experience is improved by increased UL data throughput. Without the congestion control, throughput would be impacted by packet loss. Functional description: 3GPP R6 includes mechanisms for Iub HSUPA data congestion detection and control as follows: 1) Build-up delay, detected using the reference time; and 2) Frame loss, detected using the Frame sequence number. The BTS attaches a Connection Frame Number (CFN) to the each Frame Protocol EDCH data frame. By the CFN field the RNC is able to detect if there is delay variation in the Iub interface. The BTS also attaches the Frame Sequence Number to each Frame Protocol E-DCH data frame. By the Sequence Number field the RNC is able to notice frame losses, which is an indication that packets have been lost in the Iub interface due to congestion. Congestion detection is done in the RNC. Congestion detection algorithm for Iub congestion is based on the Multilevel ECN (Explicit Congestion Notification) method. MECN algorithm introduces three delay thresholds instead of two thresholds, which are used in the ECN algorithm. MECN algorithm uses three different thresholds when congestion severity is evaluated: minimum delay (Min_th), middle delay (Mid_th) and maximum delay (Max_th). When there is increase in delay, the probability of rate reduction for all connections increases at the same time. The algorithm selects independently for each flow whether the data rate is decreased and sends congestion indication towards the BTS. In case of detected E-DCH FP frame loss, the RNC will send a corresponding congestion indication to the BTS. The restricting timer controls the maximum rate of indications. The congestion detection algorithm follows a two threshold probability curve similar to ECN. The probability of sending Congestion Indication begins to increase when the processing load exceeds the lower threshold and saturates to a level given as a parameter when the load reaches the upper threshold. Congestion handling is implemented at the BTS. HSUPA Packet scheduler in BTS reduces gradually the bit rate of the E-DCH MAC-d flow when congestion indication is received, and resumes to normal operation when "No TSN congestion" indication is received from the RNC or the BTS has not received additional congestion indications during a period defined by a timer. Operational aspects: The Operator can through new counters see the: 1) The number of congestion indications sent to BTS due to Iub delay buildup, 2) The number of congestion indications sent to BTS due to exceeded FP loss rate,
61
3) The number of congestion indications due to RNC_LED (load early detection), that is RNC internal load control. Together with the already available MAC-d flow setup counters the HSUPA Congestion rate for Iub can be seen.
62
47. Flexible Iu
Summary: Flexible Iu feature provides a standardised mechanism for connecting multiple MSCs and SGSNs to an RNC within a single operator NW. Flexible Iu is also known as 'Iu Flex' and 3GPP uses the names 'Intra Domain Connection of RAN Nodes to Multiple CN Nodes' and 'Multipoint Iu/Gb/A'. Benefits for the operator: Flexible Iu provides CAPEX and OPEX savings resulting from efficient CNs resource utilization and load balancing. Increased service availability and better NW resilience improve the end user experience. Functional description: This feature introduces the concept of Pool Areas. A UE may roam freely within a Pool Area (in either connected or idle mode) without the need to change the CN serving node. The figure below shows an example of the Pool Area configurations in the NW. Pool Area configurations are done in the CN nodes. Pool Areas themselves are not visible to the RAN but the RNC configuration has to be done according to the CN Pool Area configurations so that the RNC is able to route signalling messages to any CN node within a Pool Area. The NAS Node Selector function (NNSF) is a mechanism used for selecting the CN node for the UE. The UE derives the value of the parameter NRI from the (P)-TMSI or IMSI and sends the NRI to the RNC in the Initial Direct Transfer message. The RNC selects the CN node corresponding the NRI value configured in its database. The NNSF in the RNC contains also the CN node recovery functionality, which balances the load between the CN nodes of a pool in different cases, for example, with CN node failure, SW/HW update or adding or removing a CN node to/from the pool. Operational aspects: The relevant PM Measurements already include the possibility of multiple CN IDs in the measurement object. Hardware requirements: This feature does not require any new or additional HW.
63
48. Nokia Multi-Operator RAN

Functional description: Nokia Multi-Operator RAN allows two operators to share physical RNCs and BTSs. When this feature is used, both operators have their own CS and PS interfaces towards the RNC. In such a scenario, the subscribers of different operators use cells in different carrier layers (frequencies). The differentiation is based on the Mobile Country Code (MCC) and Mobile Network Code (MNC) of the cell. Each cell has MCC and MNC corresponding to the operator. This feature is implemented with an RNC software upgrade and it is compatible with R99 and R4 Core Networks. The Nokia Multi-Operator RAN feature: * Enables the operators to reduce the costs of their networks by sharing BTS and RNC hardware without losing control over operator-specific radio cells. * Operators can tune their cell Radio Resource Management parameters and monitor their traffic individually on a cell basis. * Neighbouring cell lists are operator-specific, which enables for example own intersystem handover decisions. * Operators are free to add additional BTSs in locations where they want to provide better coverage or more capacity. * Operators can use their own licensed frequencies and PLMN-id. * UEs show the appropriate operator logo. * Global roaming is easy. * No extra support features from UEs needed, works with 3GPP Rel. 99 WCDMA UEs * Typical areas where to use Multi-Operator RAN are: * Initial coverage when the service demand is still low * Low traffic areas, for example rural and suburban areas * Places where it is hard to find BTS spots, for example subways Cost savings are achieved by sharing the RAN capital and operating expenditure: * RNCs * BTSs * Site investments * Transmission & Transport * Installation and commissioning * Operations support system * Radio network planning The described approach provides a technical solution for allowing operators to share the Radio Access Network. It is required that the shared RAN is operated in cooperation mode so that: * Network Operation and Maintenance, * Network Dimensioning, * Transport, * Network Planning and * Synchronisation (Iu-interface)
64
are based on mutual co-operation. The solution allows operators to individually plan and optimise their own cell parameters, whereas planning and dimensioning of global RNC parameters and BTS, RNC and transmission capacity need to be handled in co-operation. Sharing the RAN offers the operators a lot of freedom in terms of deciding the scope of their co-operation as well as when and where they want to provide additional capacity or coverage of their own. Operational aspects: The PLMN Measurement objects needed. (MCC+MNC) information is added to all PM
65
49. HSDPA Transport with Best Effort AAL2 QoS

Benefits for the operator: This feature provides better efficiency of the Iub, leading to a lower Iub bandwidth reservation per individual user data flow or higher end-user bit rates. Functional description: This feature uses a best-effort transport solution for the NRT HSDPA traffic class with the possibility of reserving a certain amount of transmission capacity for HSDPA traffic on the Iub. Both HSDPA and DCH traffic is carried via the same VCC, thus, there is no need for a separate dedicated VCC for HSDPA usage. The capacity reserved for HSDPA is always available for MAC-D flows over Iub in every load situation. For the remaining Iub capacity, RT DCH and NRT DCH are given higher priority than NRT HSDPA in cases with Iub congestion. The capacity reservation is dynamic and uses parameters to support different Iub environments and Iub capacity strategies: 1. Capacity reservation for HSDPA is a parameter the operator can configure. As a minimum, there is no dedicated Iub capacity reserved for HSDPA (parameter value 0). In this case, there is no throughput guarantee and the throughput depends on the DCH traffic situation. HSDPA is then able to use the Iub capacity not used by DCH traffic. 2. The above-mentioned HSDPA reservation is dynamic, and created by means of AAL2 signalling. When there are no HSDPA users, no capacity is reserved, and the full Iub capacity is available for DCH traffic. When the first HSDPA user enters the system, capacity is reserved according to the parameter value. This reservation is maintained as long as there are active HSDPA users in the BTS. Operational aspects: The operator can use the new RAN Level KPIs and counters to follow the reserved AAL2 capacity for HSDPA and the total, minimum and maximum number of HSDPA AAL2 capacity reservations. The counters are added to a new AAL2 Resource Reservation Measurement. VC-4 or 3*VC-3 mode selectable per interface with EM/MMLs Operational aspects: The STM-1 Measurement shows: * The number of Errored background Blocks (EEB) * The number of Severely Errored Seconds (SES) * The number of UnAvailable Seconds (UAS) The counters are collected per path. VC-4 interface contains only one path.
66
50. Collection of Key Counters

Summary: The feature enables NetAct to provide a set of Key Counters in short intervals in a single new measurement. Key counters are collected from the existing cell level measurements produced by RNC. Benefits for the operator: CAPEX savings are achieved when accurate measurements are required. OPEX savings result from a possibility to improve measurement utilisation. Functional description: NetAct provides a new Key Counter measurement, which can include a collection of priority counters from the cell level measurements produced by the RNC. The data is accessible the same way as any other PM data via NetAct tools and interfaces. Key Counter measurement provides an opportunity for capacity savings in the NW management systems. The source measurements can be collected in parallel with the Key Counter measurement, but the measurement interval for the new measurement can be set to be different. This enables using the Key Counter measurement to collect some of the data more frequently, without compromising too much on the system capacity by collecting everything at the finest granularity. The new measurement can be collected for example at 15min interval while keeping the source measurements on 60 minutes. There will be more flexibility on configuring the contents of the new measurement in OSS5, but this requires manual commissioning tasks, and there are restrictions also on, for example, retaining data over changes in the measurement definition. The measurement id for Key Counter measurement will be M1050. This is just for the administrative purposes of the measurement itself. The counters in the key counter measurement will have the same Mxxxx Id and abbreviation as used in the "originating" measurement. Operational aspects: The feature can be used via the normal PM data collection and activation mechanisms once installed and activated. The Key Counter measurement is only available from NetAct, but it can be forwarded via the open OMeS interface towards other management systems. There can be only one Key Counter measurement, and the definition of that has to be consistent over the network. The supported intervals are 15, 30 and 60 minutes. In addition, the interval has to be shorter than or equal with the interval of the source measurements where the Key Counters is based on. The maximum interval for a source measurement is 60 minutes. The Key Counter measurement will contain 500 counters, and those have to be from the WCEL level measurements that are produced by RNC (M1000, M1001, M1002, M1005, M1006, M1007, M1008 and M1010), not for example from mediated BTS measurements. The schedule of the source measurements will be adjusted to 24 hours, 7 days a week. Modifications on the measurement content are only possible in OSS5. This will require manual commissioning. During commissioning there might be inconsistencies or missing PM data for the related measurements. Depending on the nature of changes, the data history from NetAct PM DB might also be lost for the Key Counter measurement. * Operating temperature range -5 ... +50 C * Main supply -48 VDC or 230 VAC The main physical characteristics of the triple-mode Nokia UltraSite EDGE BTS Outdoor are the following:
* Dimensions H x W x D * Main supply
1940 x 770 x 750 mm -48 VDC or 230 VAC
* Operating temperature range -33 ... +50 C WCDMA part supports up to three sectors, each with one carrier of 8 W average output power. The receiver sensitivity of the WCDMA part of triple-mode Nokia UltraSite EDGE BTS is -129 dBm in static channel with the following conditions: * 0.1% BER for 8 kbit/s codec user bit rate (30 ksps for data + 15 ksps for control) * Average White Gaussian Noise (AWGN) channel type * 2-way receive diversity with non-correlated signals fed to antenna connectors. The minimum reference sensitivity level specified in 3GPP (3GPP TS 25.104 v 3.4.0) is -121 dBm. The corresponding typical value for all Nokia WCDMA BTSs is -123.7 dBm. 0.1% BER for 12.2 kbit/s codec user bit rate (60 ksps for data + 15 ksps for control) * Average White Gaussian Noise (AWGN) channel type * No antenna diversity The transmit signal is always duplexed with a receive signal. The receiver diversity reception is a standard product feature. Masthead Amplifiers (MHAs) are also supported for both main and diversity antennas. The operating power for the MHAs is delivered from the BTS via the antenna feeder cable with the help of Bias-T. The maximum channel capacity is 96 code channels in the WCDMA upgrade. This is achieved by using three of the five channel capacity card slots HW units. The channel capacity can be dimensioned in 32 channel increments. Each channel unit is capable of receiving signals from all three sectors (six antennas), enabling softer handover. This means that the channel elements are fully pooled, thus allowing efficient and dynamic sharing of the HW capacity between sectors. The BTS contains an integrated transmission interface. It consists of an ATM multiplexer unit. The Nokia UltraSite EDGE BTS support E1, T1, STM-1 and Nokia Flexbus.
68
51. Antenna Line Supervision

Summary: Next Generation BTS has integrated Antenna line supervision in Radio module to control antenna line condition by VSWR measurement. This integrated HW based functionality is to be enabled by a specific SW licence. Functional description: The antenna line supervision is integrated to the RF module of Flexi BTS. It measures the VSWR, that is, the reflected RF power of the BTS TX antenna branch. In Next Generation BTS, this antenna line supervision should be enabled by a SW licence because the HW is integrated to all RF Modules. The VSWR monitoring system is used for producing alarms for the antenna line condition against alarm limits. The minor alarm will be generated when the VSWR is 1.9 and major alarm (cell down) will be generated when the VSWR is 2.6.
69
52. Flexi WCDMA BTS 3GPP Antenna Tilt Support

Summary: Flexi BTS has integrated Antenna Tilt control HW in Radio module to control the 3GPP Tilt Antennas. This integrated Antenna tilt HW is enabled by a specific SW licence. Nokia Siemens Networks supports officially only antennas that are sold by us. (Today Kathrein, Powerwave, Andrew) Functional description: Antenna Tilt is integrated to the RF module of Flexi BTS. It feeds DC power to the antenna and controls the antenna tilting. In Flexi BTS this 3GPP specified antenna tilting functionality must be enabled by a SW licence because the HW is integrated to all RF Modules. Operational aspects: RET supported antennas will automatically be detected by Flexi BTS.
70
53. Flexi WCDMA BTS AISG MHA Support

Summary: Flexi BTS has integrated Bias-T HW in Radio module to control Nokia Siemens Networks AISG 2.0 MHA's. This integrated HW based SW functionality is to be enabled by a specific SW licence. Functional description: Bias-T is integrated to the RF module of Flexi BTS. It feeds DC power to the MHA and controls the MHA DC power current consumption. If the current consumption is out of a specified window, an alarm is generated. AISG has specified additional control functionality for MHA. This control is done over OOK modulation using the antenna feeder. In UltraSite, the Bias-Ts have been separate HW units installed to the BTS antenna connectors and customer has paid the functionality in the Bias-T HW price, typically 6 pieces for a 3 sector BTS. In Flexi BTS, this AISG 2.0 MHA power feeding and enhanced MHA alarm control must be enabled by a SW licence because the HW is integrated to all RF Modules. Nokia Siemens Networks supports only Nokia Siemens Networks own MHAs coded with AISG vendor code 'NK'. For 3rd party MHAs there will be special licence key and supported MHAs need to be decided case by case. Operational aspects: AISG supported MHAs will automatically be detected by Flexi BTS. Hardware requirements: Support only Nokia Siemens Networks own AISG compatible MHS with AISG vendor code 'NK'
71
54. Inter-system Handover Cancellation

Summary: Inter-system handover from WCDMA to GSM/EDGE can be triggered due to connection quality or radio coverage reasons. During the handover process the WCDMA network conditions may change so that handover is not needed anymore. With this feature, the inter-system handover can be interrupted. Benefits for the operator: With this feature, unnecessary WCDMA to GSM handovers can be avoided, thus improving end-user service quality. Functional description: Radio coverage and connection quality (uplink DCH quality, UE TX power, downlink DPCH power, CPICH RSCP or CPICH Ec/No) are reasons to start inter-system measurements for the UE. When the inter-system measurements are completed, the target cell selection takes place. The inter-system measurement phase takes a few seconds and during that time the conditions in the WCDMA layer may change. During the inter-system measurements the UE measures also intra-frequency WCDMA neighbours. If the intra-frequency measurements indicate that the conditions have improved in the WCDMA layer so that predefined cancellation thresholds are exceeded, the RNC stops the handover and compressed mode measurements. Also, active set update during the measurements causes the inter-system handover cancellation. Typically even one fourth of the inter-system handovers triggered due to the quality and coverage reasons could be retained in the WCDMA network. Figure:
Current implementation: When the measurements and target cell selection have been completed successfully, the inter-system handover is executed. Operational aspects: Feature-specific counters provide information on the number of triggered and cancelled inter-system handovers.
72
55. RRC Re-establishment for Real Time Services

Summary: RRC connection for AMR speech, CS data and PS streaming services is re-established after temporary loss of RF coverage e.g. in tunnel areas. Benefits for the operator: This feature improves call completion ratio and thus enhances the end user experience. Functional description: This feature extends the support of RRC connection reestablishment procedure to CS and PS RABs of streaming or conversational classes. If a UE loses the radio connection in Cell_DCH state due to loss of coverage, it moves to Cell_FACH state. When the radio coverage is recovered, the UE sends the cell update message to the RNC with cause radio link failure. The RNC starts the operator configurable timer T314 when it receives the radio link failure message from the BTS(s). If the cell update message is received from the UE before T314 has expired, the RNC moves the UE back to Cell_DCH state with cell update confirm message. The interrupted service continues when the radio link synchronization is restored. If timer T314 expires, the RNC releases all RABs and the Iu-connection to the core network.
73
56. QoS Aware HSPA Scheduling

Summary: This feature allows service and subscriber differentiation in HSPA for NRT traffic classes. Benefits for the operator: This feature allows service and subscriber differentiation and supports different tariffing plans for NRT traffic classes, e.g. premium services and subscribers will have higher priority over low tariff broadband HSPA data traffic. Functional description: HSUPA and HSDPA packet schedulers in the BTS take Scheduling Priority Indicator (SPI) into account. HSUPA and HSDPA packet schedulers weight different priority queues based on their SPI values. There is a weight value per SPI value in the BTS, which sets the magnitude how often queues of different SPI classes get scheduled in relation to other SPI classes. Proportional Fair Required Activity Detection with Delay Sensitivity (PF-RAD-DS) scheduler is used for HSDPA. The RNC maps SPI from RAB QoS parameters (TC, THP, ARP) and delivers it to the packet schedulers. The mapping between the SPI and RAB QoS parameters is carried out in the RNC based on operator defined mapping rules. These rules are used also to define the priorities for NRT DCH. This feature includes prioritization in Iub frame protocol (FP) layer. QoS awareness is added to HSUPA Congestion Control and HSDPA Congestion Control features. Iub FP flow control handles congestion in priority order based on SPI.
74
57. Streaming QoS for HSPA

Summary: Streaming QoS traffic class on HSPA is supported. Benefits for the operator: Streaming services with guaranteed bit rate requirements improve service differentiation and therefore make increased revenue possible. Functional description: Guaranteed bit rate (GBR) is supported for streaming traffic class in HSPA. Admission of a new user can be denied if the guaranteed bit rate cannot be provided to the user, or if the guaranteed QoS of existing users would be affected. However, a new streaming user can take resources from HSPA NRT or from DCH NRT users (RT-over-NRT). The guaranteed bit rate is taken into account in the BTS scheduler. On HS-DSCH the PF-RAD-DS scheduler first fulfills the GBR requirements of real time users in the order of SPI. Uplink direction of streaming class RAB using GBR and mapped to E-DCH is not congestion controlled in Iub, i.e. HSUPA Congestion Control feature is not applied to NST users on E-DCH. Operator can also select whether the downlink streaming class bearers are HSDPA Congestion Controlled or not on Iub. In addition to single streaming RAB, this feature includes the multi-RAB support required by streaming traffic class: 1 RT+ 1 NRT PS RAB. This combination is supported with and without AMR. This feature makes it also possible to have Nominal Bit Rate (NBR) for NRT traffic classes. Nominal bit rate can be used as targeted minimum bit rate, e.g. based on subscription. In the scheduler NBR has higher priority than best effort but lower priority than GBR of real time users. Operator can define NBR based on traffic class+THP+ARP. Nominal Bit Rate is sent to the BTS by using GBR information element. Scheduled transmission (ST) is used in case of NBR on E-DCH, as normally for NRT. Thus uplink direction of NBR traffic is congestion controlled in Iub according to QoS aware HSUPA congestion control mechanism, introduced in QoS Aware HSPA Scheduling feature. Current implementation: DCH is used for streaming traffic class bearers. Operational aspects: Feature-specific counters are available for monitoring of HSPA setup attempts, releases, holding times, throughput and delays for streaming. Feature-specific real time monitoring of streaming RAB events on HSPA is available in NetAct Traffica.
75
58. PS RAB Reconfiguration

Summary: This feature provides the radio access bearer (RAB) reconfiguration support for interactive and background traffic classes. Benefits for the operator: With this feature, it is possible to deploy the single APN concept in the network and UEs. The usage of network resources is optimized when the QoS parameters in the network are aligned with the QoS requirements of the service. Functional description: SGSN or UE can request the RAB reconfiguration procedure if there is a need to modify the characteristics of a RAB service. To the RAN the reconfiguration is triggered by the CN with a RAB Setup message requesting reconfiguration of the existing RAB. The following RAB parameters can be changed for the interactive and background traffic class RABs: - Traffic class interactive <-> background - Maximum bit rate (UL/DL) - Change of Traffic Handling Priority (THP) of an interactive RAB - Change of Allocation and Retention Priority (ARP) RNC reconfigures the RNC and BTS with the new RAB/SPI parameters after receiving the RAB reconfiguration request from CN.
76
59. PS UE States: URA_PCH

Summary: URA_PCH RRC state is added to complement the existing RRC states. Benefits for the operator: Signalling load caused by the cell updates can be reduced when the fast moving UEs are transferred to the URA_PCH state. Functional description: Full set of packet data transfer states are provided for the efficient management of the NRT Radio Access Bearer users. In the RRC connected mode there are four different RRC states: Cell_DCH, Cell_FACH, Cell_PCH and URA_PCH. When the UE is in Cell_FACH or Cell_PCH state, its location is known by the cell level based on the cell updates sent by the UE when a cell change occurs. If too many cell updates are received in a predefined time window, the fast moving UE is ordered to transfer to URA_PCH state to reduce signalling between the UE and RNC. In URA_PCH state the location of the UE is known by the UTRAN Registration Area (URA) level. URA areas may overlap and for that purpose up to 8 URA identifiers can be broadcasted in one cell. The first URA-identifier is called primary URA and the rest of the URA identifiers in the URA-list are called secondary URAs. An UE in URA_PCH state has always only one valid URA, which is the primary URA of the cell, in which the UE has entered URA_PCH state, or in which the UE has initiated the latest URA update procedure. The UE does not initiate URA update procedure in the cells where the assigned URA is included in the URA-list. In URA_PCH state the UE uses discontinuous reception and monitors paging indications sent by the RNC. When the RNC wishes to initiate any downlink activity, it first performs the paging procedure in all cells having the UEs URA in their URA-list. Current implementation: RRC connected mode states Cell_DCH, Cell_FACH and Cell_PCH are used. Operational aspects: Feature-specific counters are available for monitoring the packet state transitions to/from URA_PCH and UE times in URA_PCH.
77
60. Spectral Efficient Link Adaptation for HSDPA

Summary: This feature reduces HS-DSCH transmission power of the low data rate users and users who are in good radio conditions. Benefits for the operator: This feature gives capacity gain in highly loaded network when the interference to neighbour cells is decreased due to the power reduction. This feature also improves the spectral efficiency, network stability and end-user performance when R99 and HSDPA channels are used on the same carrier. Functional description: BTS packet scheduler calculates the power reduction based on a function of compensated CQI, TB size, number of HS-PDSCH codes and modulation. If there is less data in the BTS transmission buffer than the recommended transport block size indicated by link adaptation, the BTS packet scheduler reduces HS-PDSCH transmission power accordingly. Also, if the compensated CQI report is indicating that less transmission power is needed, HS-PDSCH power is reduced according to the reference power adjustment parameter in CQI mapping tables of 3GPP TS25.214. HS-PDSCH codes and power resources are shared more efficiently by taking into account current buffer occupancy and channel conditions of the users in a single cell code multiplexing case. Current implementation: In the current implementation, all remaining transmission power not used for R99 or HSUPA downlink channels is used for HSDPA. For code multiplexing, even codes - even power -method is used to share resources for scheduled users. Operational aspects: Existing counters are available for monitoring the number of users per TTI, utilized codes for HSDPA and power levels in cells (HSPA vs. all). Hardware requirements: This feature does not require any new or additional HW.
78
61. Dual Iub for Flexi WCDMA BTS

Summary: This feature enables the use of ATM protocol stack for delay critical traffic and 3GPP Rel-5 / Rel-6 compliant IP protocol stack for more delay tolerant traffic at the Iub interface. Benefits for the operator: Dual Iub allows using Ethernet for HSPA traffic e.g. via Carrier Ethernet or DSL. OPEX and CAPEX savings result from more cost efficient Iub transport compared to leased E1/J1/T1s. The application of this feature is very much the same as with Hybrid Backhaul with Pseudowires, but here the pseudowire gateway at the RNC is not needed anymore. Functional description: With this feature, Flexi WCDMA BTS and RNC support simultaneously both ATM Iub protocol stack and 3GPP Rel-5 / Rel-6 compliant IP based Iub protocol stack in the following configuration: - Rel-99 RT, NRT, control plane and O&M traffic goes over ATM Iub over E1s / STM1s - HSPA (HSDPA and HSUPA) traffic goes over IP based Iub over Ethernet. The ATM part of this feature is based on ATM-based Iub/Iur feature according to 3GPP Rel99. IP part is implemented according to IP based Iub for Flexi WCDMA BTS feature. Figure:
Current implementation: Current Iub solution is based on feature ATM-based Iub/Iur according to 3GPP Rel99. HSPA can be carried over IP/Ethernet with feature Hybrid BTS Backhaul, which supports Pseudo-Wire emulation protocol stack.
79
62. CS Voice Over HSPA

Summary: This feature allows using spectral efficient HSPA transport channels for CS Voice traffic. The mapping of CS Voice to HSPA channels is done in RNC and is not visible to Core Network. Thus the R99 or R4 CS core network can be used without any changes. Benefits for the operator: This feature provides CAPEX savings to the operator increasing CS Voice call capacity of the cell. The feature allows utilizing the high spectral efficiency of HSPA channels for AMR calls and the air interface capacity can be increased by up to 100%. This feature also increases operator's voice call revenue and improves end-user voice call experience because of longer UE battery life time for voice calls. Functional description: CS Voice over HSPA uses HSPA transport channels to carry CS voice traffic. Mapping the CS voice to HSPA takes place in RNC and is not visible to core network. Thus the R99 or R4 CS core network can be used as today. There are no changes to layer 1 in the Radio network but some changes to L2 protocols are required. Uplink de-jitter buffer in RNC ensures that AMR speech frames are sent to Iu-CS as today with R99 CS. Inter system mobility between 2G and 3G is as today, the CS Voice Over HSPA is just RAN internal mapping and it is not visible outside of the RAN. Handover signalling is not affected and RAN provides the measurement periods for UE using compressed mode as today. No changes to voice ecosystem required: CS core, roaming, charging, etc. remains the same. The AMR rate adaptation can be used to provide even higher capacity gains by lowering the AMR coding rate. Voice related RRM algorithms like pre-emption are expanded to cover also the Voice Over HSPA. Air interface capacity gain of the feature depends on parameterisation of HSUPA including CPC parameters, allowed noise rise and voice activity. See the illustration of the CS Voice Over HSPA: Figure:
80
Current implementation: CS voice is carried over R99 transport channels Hardware requirements: Requires Flexi multimode system module or enhanced Ultra site baseband.
81
63. HSDPA 64QAM

Summary: HSDPA 64 QAM enables 21.1 Mbps HSDPA data rate. This functionality increases single user peak rate, overall cell capacity and average cell throughput. Benefits for the operator: HSDPA 64QAM feature enables high HSDPA bit rates and offers possibilities for subscription differentiation and additional data service revenue. In addition to single user peak rate enhancement, the average cell throughput is also increased which improves both end user experience and overall network efficiency. Functional description: 3GPP Rel-7 introduces 64QAM modulation for HSDPA. 64QAM modulates 6 bits per symbol and increases the HSDPA peak data rate up to 21.1 Mbps. New HSDPA terminal categories 13, 14, 17 & 18 supporting 64QAM are introduced. Practical throughput achievable with this feature is limited by radio reception: Maximum theoretical throughput 21.1 Mbps of cat 14 & cat 18 terminals would require the use of coding rate close to 1, i.e. it would require error free reception. Targeting to error free reception reduces the system efficiency and capacity. In all practical conditions the throughput will be degraded if using coding rates close to 1, i.e. having effectively no error correction. Quality of radio reception depends on aspects such as received signal strength, radio channel and interference, transmitter and receiver imperfections. 64QAM is even more sensitive to the quality of radio reception than 16QAM. The link adaptation algorithm in the BTS (MAC-hs) selects 64QAM when the channel quality is sufficient and the UE is 64QAM capable. 64QAM is optional feature for the UE, and the 64QAM capability is signalled to RNC in RRC connection setup. 64QAM provides 3 -15 % higher average HSDPA cell and user throughput, depending on the environment and terminal receiver.
82
64. HSUPA 5.8 Mbps

Summary: The peak bit rate on E-DCH for single user is increased up to 5.8 Mbps Benefits for the operator: This feature enables operator to offer higher HSUPA bit rates to premium data subscribers and increase data service revenue. Functional description: HSUPA UE categories 4 and 6 support higher peak bit rate than 2 Mbps. With this feature category 4 and 6 UEs may transmit data with the maximum bit rate, which is achieved with an E-DCH configuration of 2ms transmission time interval (TTI). Four parallel codes are required for category 6. When four codes are transmitted in parallel, two codes are transmitted with spreading factor two (2xSF2) and two with spreading factor four (2xSF4). Also intermediate bit rates are supported with 2 ms TTI. The maximum theoretical throughput of cat6 terminal is 5.76 Mbps. Practical throughput achievable with this feature is limited by radio reception and allowed noise rise: Maximum theoretical throughput would require the use of coding rate close to 1, i.e. it would require error free reception. Targeting to error free reception reduces the system efficiency and capacity. In all practical conditions the throughput will be degraded if using coding rates close to 1, i.e. having effectively no error correction. Quality of radio reception depends on aspects such as received signal strength, radio channel and interference, transmitter and receiver imperfections. Current implementation: The peak bit rate on E-DCH for single user is 2.0 Mbps, corresponding to two parallel codes of spreading factor two (2xSF2) and 10 ms TTI.
83
65. Continuous Packet Connectivity

Summary: This feature introduces discontinuous uplink DPCCH transmission and discontinuous downlink reception with HSPA. Continuous Packet Connectivity feature saves air interface capacity in case the cell has UE's with low activity and using non-continuous transmission. CPC capable UE's can be kept longer in Cell_DCH state in case of Interactive/Background traffic. Benefits for the operator: This feature improves end user HSPA experience providing longer battery life time (up to 100%) in the UE's. Long battery life time makes it possible to offer true Always-On type of services to the end users and enables new revenue sources to the operator. CPC also increases air interface capacity for voice and data. Up to 50 % capacity increase with CPC and voice over HSPA compared to voice over HSPA without CPC. Functional description: 3GPP Rel-7 introduces continuous packet connectivity (CPC). Discontinuous uplink DPCCH transmission, discontinuous downlink reception operations, MAC DTX and CQI reporting reduction are the supported parts of the continuous packet connectivity feature. CPC is optional feature for Rel-7 UEs and CPC capability is signalled by the UE to RNC in RRC connection setup. CPC is used only in case of HSPA only configuration, i.e. HSUPA in UL and HSDPA and F-DPCH in DL, also the SRBs are always on HSPA. No DCHs in UL/DL are allowed with CPC. RNC commands the UE to start the discontinuous uplink DPCCH transmission and discontinuous downlink reception operations and configures the DTX/DRX parameters when enabling the CPC operations. Relevant parameters of the UE DTX/DRX configurations are signalled (by RNC) also to the BTSs in the active set. Discontinuous uplink DPCCH transmission and discontinuous downlink reception operations can be enabled whenever all BTSs in the active set and the UE support it. During HO procedures, RTT measurements etc. CPC may be temporarily switched off by RNC. UL DTX / DL DRX operations can be de-activated and activated also by serving BTS with fast L1/L2 signalling e.g. in case radio conditions are deteriorating.
84
CPC makes Cell_DCH state more affordable from air interface capacity point of view for low activity/non-continuous transmission. Better user experience could be offered to CPC capable UEs by keeping them longer in Cell_DCH state in case of I/B traffic. Figure:
85
66. Multi-Operator Core Network

Summary: With the Multi-Operator Core Network feature several CN operators can be connected to the same RNC sharing fully all RAN resources. Benefits for the operator: The operators may share the network costs by building the coverage using shared RAN. Especially in the areas where the capacity requirement is low sharing can be a good solution. Functional description: Multi-Operator Core Network (MOCN) is a 3GPP solution for RAN sharing. PLMN-identities of available CN operators are broadcasted to UEs in the system information messages. The 3GPP R6 capable UEs choose the PLMN to which the RNC should start the signalling connection. The chosen PLMN is signalled to the RNC in the initial messaging and based on the selected PLMN the signalling connection is routed directly to the appropriate CN. For the end-users MOCN is not visible; they can see their own network logo in the terminal. The legacy UEs are not able to choose the PLMN and for them the RNC selects the CN. RNC has a re-routing functionality, which is used in case the initial selection is not the correct one. The re-routing is triggered by the CN redirection indication. The RNC will then forward the initial UE message to another CN until it finds a CN that can serve the UE. MOCN may be used at the same time with the Flexible Iu, which allows one operator to have several CN entities connected to the RNC.
86
67. HSUPA Interference Cancellation Receiver

Summary: HSUPA Interference Cancellation Receiver feature greatly improves the data and voice capacity in HSPA+ system. Up to 60% increase in data throughput and more than 40% increase in voice capacity can be achieved. Benefits for the operator: HSUPA Interference Cancellation enables higher HSUPA throughput especially in typical mixed data and voice scenario. It protects the AMR coverage while enabling high throughout for HSUPA UE's HSUPA Interference Cancellation is an enabler for high peak UL data rates (up to 11Mbps with 16QAM). HSUPA Interference Cancellation is also needed for balanced DL/UL. Functional description: HSUPA Interference Cancellation cancels the inter code interference. At the beginning the HSUPA signal is detected and is used to regenerate the spreaded wideband signal, which is then subtracted before the actual receiver. Thus HSUPA channels will be RAKE processed twice. Interference cancellation efficiency and Interference from other cells determines the capacity gain. Additionally the coverage gain depends on the noise rise without interference cancellation. Operational aspects: Amount of cancelled power may be estimated to show power of the algorithm. Hardware requirements: Requires Flexi multimode system module or enhanced Ultra site baseband.
87
68. Frequency Domain Equalizer

Summary: Frequency domain equalizer (FDE) is the most advanced receiver technology for high data rates. FDE is simpler compared to traditional time domain equalizer or G-Rake. It captures the energy from all multi paths and offers robust performance in all channel conditions with up to 2x higher 16QAM data rate compared to Rake receiver. Benefits for the operator: FDE is an enabler for high uplink data rates up to 11 Mbps with 16 QAM. Functional description: FDE is the same solution as in 3GPP LTE utilizing frequency domain equalization. FDE is simpler compared to traditional time domain equalizer or G-Rake. It captures the energy from all multi paths and offers robust performance in all channel conditions with up to 2x higher 16QAM data rate compared to Rake receiver.
88
69. LCS - Cell Coverage Based (RTT) with Geographical Coordinates

Functional description: The cell coverage-based positioning method is based on the fact that the RAN knows which cell is the serving cell of the UE. Information about the serving cell is always available in RAN because an RRC connection is set up before the positioning is started. The cell coverage-based location information can be indicated either as the Service Area that the UE is currently in (in the form of Service Area Identity) or as the geographical coordinates of the location in relation to the serving cell. If the serving area of the UE is requested, the RNC maps the current serving cell to the service area ID (SAI) and returns the SAI to the core network. The same service area ID may include several cells. If the geographical coordinates are requested, the location information includes estimated geographical coordinates of the UE and an indication of the achieved accuracy of the location estimate. When geographical coordinates are used as location information, the estimated position of the UE can be determined as the location within the serving cell. The geographical location estimate is obtained by combining information on the cell-specific geographical location of the BTS with signal Round Trip Time (RTT) measurements between the BTS and the UE. If the UE is in soft(er) handover, the cell-specific information and the RTT measurements are combined and used from all of the active set cells. If the RTT measurements should fail, the cellspecific cell area information is used to formulate the UE position estimate. Operational aspects: This feature is implemented with a software upgrade. The operator can use the counters to follow the total number of LCS requests and the number of successful operations. RAN Level KPI for LCS Success is introduced.
89
70. UE Based A-GPS Using External Reference Network

Summary: A-GPS location method utilises the assistance data sent from Mobile Location Centre to a UE. With this assistance data, the UE's GPS receiver is able to calculate a position faster and in weaker GPS satellite signal conditions. The UE returns the position coordinates to the NW. Benefits for the operator: Increased end-user experience is achieved thanks to better positioning accuracy than is provided with the cell ID / RTT-based positioning method. Functional description: When the GPS is co-operating with UTRAN, the NW can assist the UE to improve the stand-alone GPS receiver performance in several ways. The A-GPS method can: - Reduce the GPS receiver start-up and acquisition times: the search window can be limited and the measurements speed up significantly. - Increase the GPS sensitivity: time information and navigation messages are obtained via UTRAN, so GPS can operate also in high noise rate situations, for example indoors and in building blockage. - Consume less handset power than a stand-alone GPS receiver does: this is due to rapid start-up times as the GPS can be in idle mode when it is not needed. After a locationing request has been received from the CN, the RNC integrated SMLC calculates the CIRTT location estimate for the target. If the locationing accuracy requested by the CN cannot be fulfilled, the A-GPS method is selected. In a UE based A-GPS, all the above mentioned improvements can be achieved with additional assistance data retrieved from the stand-alone SMLC (SAS). The reference NW can be connected to the RNC via proprietary interface or via standard Iu-PC interface. The RNC is able to construct the GPS assistance information elements according to 3GPP standards. At the request of an UE- or NW-based application, the assistance data is transmitted from the RNC to the UE. The UE uses the assistance data and its own GPS measurements to locate itself and sends the locationing results (location coordinates) back to the RNC, from which the RNC forwards the results to the CN. In addition, the UE can ask the A-GPS assistance data only for its own purposes. With this functionality the RNC sends the assistance data to the UE but the location coordinates are not returned to the NW.
90
71. Network Based A-GPS Using External Reference Network

Summary: A-GPS location method utilises assistance data sent from Mobile Location Centre to UE. With this assistance data, the UE's GPS receiver is able to retrieve satellite signal information faster and in weaker GPS satellite signal conditions. Location calculation is done in the Stand-Alone Mobile Location Centre. Benefits for the operator: Improved end-user experience results from better positioning accuracy than the cell ID / RTT based positioning method is able to provide. With the NW-based positioning, the operator can control the UE position calculation in its own NW. Functional description: When the GPS is co-operating with UTRAN, the NW can assist the UE in improving the stand-alone GPS receiver performance in several ways. A-GPS method can: - Reduce the GPS receiver start-up and acquisition times: the search window can be limited and the measurements speed up significantly. - Increase the GPS sensitivity: time information and navigation messages are obtained via UTRAN, so GPS can operate also in high noise rate situations, for example indoors and in building blockage. - Consume less handset power than a stand-alone GPS receiver does: this is due to rapid start-up times as GPS can be in idle mode when it is not needed. After the locationing request has been received from the CN, the RNC integrated SMLC calculates the CIRTT location estimate for the target. If the locationing accuracy requested by the CN cannot be fulfilled, the A-GPS method is selected. In NW-based A-GPS, all above mentioned improvements can be achieved with additional assistance data retrieved from the SAS via the standard Iu-PC interface. At the request of an UE- or NW-based application, the assistance data is transmitted from the RNC to the UE. The UE utilizes the assistance data to make the GPS signal measurements and sends the measurements back to the RNC. The RNC forwards the measurement results to the SAS, which uses the measurements to calculate the UEs location. The SAS sends the location results back to the RNC, which forwards them to the CN. The SAS is able to calculate the coordinates at least with the same accuracy as the UE. The accuracy may be improved by utilizing NW parameters or other positioning methods than GPS. Operational aspects: This feature requires the support of the Iu-pc interface between the RNC and the SAS (see feature Point-to-Point Iu-pc Interface) and a third party SAS NE to generate the GPS assistance data and calculate the UE position.
91
72.
IP Based Iu-PS
Summary: This feature enables the use of IP and Ethernet transport according to 3GPP Rel-5 and Rel-6 at the Iu-PS interface for the RNC. Benefits for the operator: OPEX and CAPEX savings in transport result from a more cost efficient transport network for Iu-PS traffic. With IP based Iu-CS, Iu-PS and Iur interfaces the operator can utilize a common IP backbone network from the RNC upwards to the Core Network elements and other RNCs. Functional description: With this feature the RNC supports 3GPP Rel-5 / Rel-6 compliant IP transport protocol option on the Iu-PS interface. Dual stack operation allows usage of ATM Iu-PS and IP Iu-PS simultaneously. A connection to a single SGSN can be either ATM or IP based. IP Differentiated Services Code Point (DSCP) marking is the backbone of the QoS solution for the Iu-PS over IP. The IP packets are classified into PHBs according to the DSCP field in the IP header and based on this information the RNC and routers schedule the packets. The RNC supports a scheduling algorithm with multiple queues, which are used to implement the PHBs. Scheduling is based on the Weighted Fair Queuing policy. WRED is also supported to avoid TCP global synchronization. The Maximum Transmission Unit (MTU) defines the largest datagram that can be transmitted by an IP interface. If the IP packet size exceeds the MTU, the RNC fragments the packet into smaller units. In an Ethernet network the MTU is 1500 bytes. The RNC is able to operate with the MTUs bigger than 1500 bytes if the external network supports it. This solution is based on IPv4 because IPv4 networks are very widely used and they are expected to be favored also in the future. Figure:
Operational aspects: Counters for monitoring GTP tunnel reservations, UDP layer (RFC1213) and IP layer traffic/QoS are included in this feature.
92
Hardware requirements: This feature requires NP2GE Gigabit Ethernet interface unit in the RNC.
93
73.
KPI Calculations in RNC Element Manager
Benefits for the operator: The operator is able to make KPI-based calculations on performance management data directly at RNC. Functional description: Network performance can be evaluated based on Key Performance Indicators (KPIs), which present some vital information regarding the network. KPIs are either an individual counter or a combination of several counters, which are collected in the network. The idea behind the KPI concept is that the information of one counter value rarely is very descriptive as such, but combined with other counters it can provide valuable information on how well the network is functioning. This feature enables RNC to calculate KPIs and show their results in Element Manager measurement presentation GUI. The operator can use predefined KPIs or define own customised KPI formulas. This feature is a part of WCDMA RAN Measure Solution. Pre-defined KPIs are, for example: KPIs from Cell Resource Measurement Area: * Average UL Load (dBm) * Average DL Load (dBm) * Average RACH Throughput (kbits) * Average FACH Throughput (kbits) * Average PCH Throughput (kbits) KPIs from Service Level Measurement Area: * RRC Setup and Access Complete Ratio (%) * RRC Drop Ratio (%) * RAB Setup and Access Complete Ratio, Voice (%) * RAB Setup and Access Complete Ratio, RT Service Other Than Voice (%) * Service Setup Success Ratio (%) * RAB Drop Ratio, Voice (%) * RAB Drop Ratio, RT Services Other Than Voice (%) * RAB Drop Ratio, NRT Services (%) KPIs from Soft Handover Measurement Area: * Soft Handover Overhead (%) KPIs from Intra-system Hard Handover Measurement Area: * Hard Handover Fail Ratio (%) KPIs from Traffic Measurement Area: * UL Dedicated Channel Throughput (kbits) DL Dedicated Channel Throughput (kbits)
94
Figure:
Operational aspects: This feature is a part of WCDMA RAN Measure Solution.
95
74.
Load and Service Based IS/IF Handover
Summary: Load and Service Based Inter-system / Inter-frequency Handover (HO) is a feature which enables load balancing between operator's 2G and 3G networks. Based on operator definable end-user service categories, the 3G calls can be moved either to a new frequency layer or to 2G network so that the required service performance can still be met. In case that the network (NW) load exceeds a predefined threshold, either an inter-frequency handover (IFHO) or inter-system handover (ISHO) will be performed. Benefits for the operator: CAPEX and OPEX savings are achieved thanks to better resource utilisation in 2G and 3G networks. Load balancing provides the operator withmore capacity, hardware investments are utilised more effectively and there is less blocking in the NW. Functional description: Load and service -based HOs take care of load sharing and service differentiation inside the WCDMA system as well as between WCDMA and GSM/GPRS systems. Both load and service are taken into account simultaneously, but the measured load defines the way of operation. The figure below clarifies the dependency. The load indicators that can be measured are uplink (UL)/downlink (DL) interference, non-real time (NRT) traffic delay, DL spreading code availability and HW/logical resource usage. This feature also enables the operator to set different HO profiles for the service classes. The service classes are split according to the traffic classes specified for radio access bearers (RABs), separating the speech and data services from the CS and PS domains. The RNC-based HO profile defines the preferred system or WCDMA hierarchical cell layer (GSM, WCDMA macro, WCDMA micro, none). By default, only the real-time services are handed over because the NRT-dedicated traffic channel (DCH) allocations are expected to be too short for these kinds of HO procedures. However, the operator may enable HOs also for the NRT services in case of longer DCH allocations. The HO profile is followed in both load and service -based HO decisions unless the CN provides a Service Priority information element on RAB setup. This, for example, overrides the HO profile if the HO decision for the UE in question is made between the WCDMA and GSM systems. Figure:
96
Operational aspects: The list below shows an example of service priority definitions. Each service is given a preferred system/layer, which can be set by the operator. - Conversational CS speech -> GSM - Conversational CS transparent data -> WCDMA, macro - Conversational PS speech -> WCDMA, macro - Conversational PS RT data -> WCDMA, micro - Streaming CS non-transparent data -> WCDMA, macro - Streaming PS RT data -> WCDMA, micro - Interactive PS NRT data -> WCDMA, micro - Background PS NRT data -> WCDMA, micro The Operator can monitor the triggering of Load and Service-Based HO through new counters. The counters are added to the Intra System hard handover (HHO) and Inter System HHO Measurements.
97
75.
HSPA Inter-RNC Cell Change
Summary: HSPA inter-RNC cell change introduces seamless HSPA mobility between RNCs. HSPA serving cell is directly changed from source RNC to target RNC. Benefits for the operator: Improved end user experience, HSPA high data rates can be maintained in RNC border areas. HSPA capacity gains can be achieved also in RNC border areas, reducing CAPEX. Functional description: When intra-frequency measurements indicate that the strongest cell in the active set is located under the DRNC, HSPA intra-frequency inter-RNC cell change is executed. Triggering point for inter-RNC cell change can be specifically defined by the operator by management parameters. Functionality applies both to HSDPA and HSUPA. HSPA intra-frequency inter-RNC cell change utilises SRNS relocation with UE involvement, i.e. UE is reconfigured according to the target RNC resources during SRNS relocation. Source RNC deletes old configuration after successful SRNS relocation. HSPA serving cell change (serving HS-DSHC/E-DCH cell change) is combined with SRNS relocation. HSPA data flow is not established over Iur-interface but HSPA resources are reserved and allocated under DRNC in conjunction of the SRNS relocation. DCHs for SRBs and UL return channel can be setup over Iur interface, whereas HS-DSCH and E-DCH are not used over Iur interface. HSPA inter-RNC cell change is supported also when Iur interface is disabled, congested or not existing. Operational aspects: New counters for HSPA Inter-RNC Cell Change related: - Resource reservations, - Inter RNC HHOs, - Packet Session allocations.
98
76.
HSUPA 2.0 Mbps
Summary: The highest supported user peak rate on E-DCH is 2.0 Mbps, corresponding to two parallel codes of spreading factor two (2xSF2) and 10 ms TTI. Benefits for the operator: HSUPA peak rate is increased up to 2.0 Mbps per user. Functional description: HSUPA category 5 UE is capable of 2.0 Mbps peak air interface bit rate. HSUPA categories 4 and 6 have 2.0 Mbps peak bit rate in case of 10 ms TTI. 2.0 Mbps user peak rate on E-DCH is supported in RNC and BTS user plane processing and in configuration (e.g. RLC) of L2 done by L3. BTS supports reception of two SF/2 multi-codes with 10 ms TTI. Operational aspects: The operator can: 1. In BTS: through new E-DCH (MAC-e) throughput (counters to follow the HSUPA cell throughput, 2. In RNC: through new RLC counters to follow the HSUPA user throughput.
99
77.
IMA (Flexi WCDMA BTS)
Summary: IMA (Inverse Multiplexing for ATM) is supported for E1, T1, JT1 and Flexbus interfaces of Flexi WCDMA BTS.
100
78.
IP Based Iu-CS
Summary: This feature enables the use of IP and Ethernet transport according to 3GPP Rel-5 and Rel-6 at the Iu-CS interface for the RNC. Benefits for the operator: OPEX and CAPEX savings in transport result from a more cost efficient transport network for Iu-CS traffic. With IP based Iu-CS, Iu-PS and Iur interfaces operators can utilize a common IP backbone network from the RNC upwards to the Core Network elements and other RNCs. Functional description: With this feature the RNC supports 3GPP Rel-5 and Rel-6 compliant IP transport protocol options on the Iu-cs interface. Dual stack operation allows usage of ATM Iu-cs and IP Iu-cs simultaneously. A connection to a single MGW can be either ATM or IP based. IP Differentiated Services Code Point (DSCP) marking is the backbone of the QoSsolution for the Iu-CS over IP. The IP packets are classified into PHBs according to the DSCP field in the IP header and based on this information the RNC and routersschedule the packets. The RNC supports a scheduling algorithm with multiple queues,which are used to implement the PHBs. Scheduling is based on the Weighed FairQueuing policy. WRED is also supported to avoid TCP global synchronization. The basic Connection Admission Control (CAC) functionality is implemented for realtimetraffic to confirm reasonable traffic load. The admission is performed against thepredefined Iu-cs guaranteed bit rate. RTP is used to carry user plane traffic. RTCP is supported in order to monitor lostpackets and delay variance. Additionally, RTCP can be used to supervise thecontinuity of the RTP session. OSPF for Redundancy can be used for providing redundancy for userplane traffic between the two Ethernet ports on the same interface unit. This solution is based on IPv4 as IPv4 networks are very widely used and they areexpected to be favored also in the future. Operational aspects: Counters for monitoring the resource reservations at Iu-CS interface, UDP layer (RFC1213) and IP layer traffic/QoS are included in this feature. Hardware requirements: This feature requires the NP2GE Gigabit Ethernet interface unit in the RNC.
101
79.
IP Based Iur
Summary: This feature enables the use of IP transport according to 3GPP Rel-5 and Rel-6 on the Iur interface for the RNC. Benefits for the operator: OPEX and CAPEX savings in transport result from a more cost efficient transport network for Iur traffic. With IP based Iu-CS, Iu-PS and Iur interfaces the operator can utilize a common IP backbone network between RNC, Core Network elements and other RNCs. Functional description: With this feature the RNC supports 3GPP Rel-5 / Rel-6compliant IP transport protocol option in the Iur interface. Dual stack operation allowsusage of ATM Iur and IP Iur simultaneously. A connection to a single neighboring RNCcan be either ATM or IP based. IP Differentiated Services Code Point (DSCP) marking is the backbone of the QoSsolution for the Iur over IP. The IP packets are classified into PHBs according to theDSCP field in the IP header and based on this information the RNC and routersschedule the packets. The RNC supports a scheduling algorithm with multiple queues,which are used to implement the PHBs. Scheduling is based on the Weighed FairQueuing policy. WRED is also supported to avoid TCP global synchronization. The basic Connection Admission Control (CAC) functionality is implemented for realtimetraffic to confirm reasonable traffic load. The admission is performed against thepredefined Iur guaranteed bit rate. IP Iur links are monitored using the Bidirectional Forwarding Detection (BFD) continuitycheck mechanism for packet networks. The Maximum Transmission Unit (MTU) defines the largest datagram that can be transmitted by an IP interface. If the IP packet size exceeds the MTU, the RNC fragments the packet into smaller units. In the Ethernet network the MTU is 1500 bytes. The RNC is able to operate with bigger than 1500-byte MTUs if the external network supports them. OSPF for Redundancy (RAN1510) can be used for providing redundancy for user plane traffic between the two Ethernet ports on the same interface unit. This solution is based on IPv4 because IPv4 networks are very widely used and they are expected to be favored also in the future. Figure:
102
Operational aspects: Counters for monitoring the resource reservations on Iur interface, UDP layer (RFC1213) and IP layer traffic/QoS are included in this feature. Hardware requirements: This feature requires NP2GE Gigabit Ethernet interface unit in the RNC. NP2GE will be available for RNC2600.
103
80.
IP Based Iub for UltraSite WCDMA BTS
Summary: This feature enables the use of native IP and Ethernet transport accordingto 3GPP Rel-5 and Rel-6 on the Iub interface for UltraSite WCDMA BTS. Functional description: With this feature UltraSite WCDMA BTS supports the same IP functionalities as described in feature IP based Iub for Flexi WCDMA BTS. Hardware requirements: IFUH or AXCF (available in RU20) is required in UltraSite BTS. NP2GE Gigabit Ethernet interface unit is required in the RNC. It will be available for RNC2600.
104
81.
IP Based Iub for Flexi WCDMA BTS
Summary: This feature enables the use of native IP and Ethernet transport according to 3GPP Rel-5 and Rel-6 on the Iub interface for the RNC and Flexi WCDMA BTS. Benefits for the operator: OPEX and CAPEX savings in transport result from more cost efficient transport network for Iub traffic. Functional description: With this feature the RNC and Flexi WCDMA BTS support the 3GPP Rel-5 and Rel-6 compliant IP transport protocol option on the Iub interface. Dual stack operation in the RNC allows the usage of ATM Iub and IP Iub simultaneously in the same RNC. With this feature, a single BTS is then connected to the RNC via IP Iub, while other BTSs may still continue using ATM Iub towards the same RNC. IP Differentiated Services Code Point (DSCP) marking is the backbone of the QoS solution for the Iub over IP. The IP packets are classified into PHBs according to the DSCP field in the IP header and based on this information the RNC, BTS and routers schedule the packets. Two operator configurable DSCPs are supported, which allows the mapping ofRT and NRT traffic to separate DSCPs. A full range of DSCPs is supported with the Iub Transport QoS feature. The RNC and BTS support a scheduling algorithm with two queues, which are used to implement the PHBs. Scheduling is based on the Weighted Fair Queuing policy. WRED is also supported to avoid TCP global synchronization. VLAN tagging enables L2 traffic separation and prioritization across the network by using priority bits. VLAN priority bits in the VLANtag are marked according to the PHB allocated to the packet. Mapping between PHBs and VLAN priority bits is operator configurable (also Iub transport QoS feature is required in addition for full configurability). The basic Connection Admission Control (CAC) functionality is implemented to confirm reasonable traffic load towards the BTSs. The admission is performed against the predefined guaranteed bit rate per BTS, which is usually the bottleneck on Iub. BTS synchronization can be provided with Timing over Packet feature, or by another synchronization source such as a TDM link or a GPS. User plane IP links are monitored using Bidirectional Forwarding Detection (BFD) continuity check mechanism for packet networks. The Maximum Transmission Unit (MTU) defines the largest datagram that can be transmitted by an IP interface. If the IP packet size exceeds the MTU, the RNC or BTS fragments the packet into smaller units. In the Ethernet network the MTU is 1500 bytes. Large NBAP messages and HSUPA data packets may exceed this limit and in these cases IP fragmentation is needed. This solution is based on IPv4 because IPv4 networks are very widely used and they are expected to be favored also in the future.
105
Figure:
Operational aspects: This feature includes counters for monitoring the Iub resource reservations, CAC allocations, UDP layer (RFC1213), IP layer traffic/QoS and Iub delay. Hardware requirements: This feature requires the NP2GE Gigabit Ethernet interface unit in the RNC. NP2GE will be available for RNC2600. FTIA/FTIB or FTJA FlexiTransport Ethernet + E1/J1/T1 interface HW module is required in Flexi WCDMA BTS.
106
82.
HSPA 72 Users Per Cell
Summary: This feature increases the number of simultaneous HSPA (HSDPA and HSUPA) users to 72 per cell. Benefits for the operator: CAPEX and OPEX savings are achieved by increased simultaneous HSPA end users in a cell. With this feature more users can be kept on HSPA, providing an instant access to data services after momentary inactivity periods and thus improving the end user experience. Functional description: This feature allows 72 simultaneous HSPA (HSDPA & HSUPA) users per cell, both with dedicated and shared scheduler. In order to be able to schedule and control increased number of HSPA users in a cell, the number of HS-SCCH channels is increased to four. On the other hand, as the DL code space is a scarce resource, a dynamic DL control channel allocation mechanism is introduced to maximize the available codes for HS-PDSCHs. E-HICH/E-RGCH codes are allocated dynamically, based on number of users. In order to avoid fragmentation of the code space, the E-HICH/E-RGCH signatures are actively reconfigured. Current implementation: Currently the maximum number of simultaneous users per cell is 64 for HSDPA and 20 for HSUPA. Supporting NetAct Features: - NetAct functionality for HSPA 72 users per Cell - Service Optimizer
107
83.
HSPA over Iur
Summary: HSPA service is maintained during inter-RNC mobility. Benefits for the operator: This feature improves end user performance by maintaining the HSPA service during inter-RNC mobility. Capacity gain is achieved in the RNC border cells when HSPA can be utilized instead of DCH. Functional description: When the UE's intra-frequency measurements indicate that the strongest cell in the active set is under the DRNC, HSDPA and HSUPA serving cell change over Iur is performed. After the serving cell change, HSDPA and HSUPA data is transmitted over the Iur utilizing HSPA concestion control. The serving cell change over the Iur can also be done between cells controlled by DRNC. When the last active set cell in the SRNC is deleted, SRNS relocation is triggered while HSPA service is in use. Also HSDPA with DCH in UL is supported. This feature supports one PS Interactive / Background RAB per UE on Iur. In case this limit is exceeded then the transport channels are reconfigured to DCH. Basic ATM layer traffic differentiation on the Iur is provided where the HSPA high peak rate traffic can be separated from higher priority traffic at ATM layer: DCH+HSPA (stringent + stringent bi-level) VCC and HSPA (tolerant) VCC. Current implementation: HSPA service is switched to DCH in RNC borders. Direct switch from HSPA to non-zero DCH and back to HSPA is supported. Operational aspects: Feature-specific counters are available for monitoring total number of triggered and successful inter-RNC serving cell changes. Hardware requirements: This feature does not require any new or additional HW Supporting NetAct Features: Service Optimizer
108
84.
HSUPA 2 ms TTI
Summary: This feature enables HSUPA 2ms TTI. It also maps the SRBs (Signalling Radio Bearer) on HSUPA, if 2 ms TTI is assigned to the UE. Benefits for the operator: Shorter TTI and lower latency improve application level performance and end user HSPA experience. Functional description: HSUPA 2ms TTI is used for UE categories 2, 4, 6 and 7. Shorter TTI improves average latency in radio interface by 12 ms for the first transmission. Faster retransmissions also reduce variance of the RTT. Immediate data processing in Iub and RNC user plane also shortens round trip time. Mapping the SRBs to HSUPA enables spreading code allocation of 2xSF2 + 2xSF4 in uplink, which is needed if 5.8 Mbps bit rate is used. Current implementation: 10 ms TTI is used. Supporting NetAct Features: NetAct Configurator functionality for higher peak rates
109
85.
Extension of SIB11 (SIB11bis)
Summary: System Information Block type 11bis (SIB11bis) provides extension segments for SIB11. SIB11bis solves an inconsistency problem in 3GPP TS 25.331, which has prevented the usage of complete neighboring cell lists for idle mode UEs. Benefits for the operator: Complete neighboring cell lists can be provided to guarantee the optimal cell re-selection and end-user QoS. Functional description: 3GPP R6 introduces SIB11bis, which allows operators to define 32 intra-frequency, 32 inter-frequency and 32 inter-system neighboring cells for idle mode UEs. All these neighbors were originally intended to be included in SIB11, but in the specifications the physical size of SIB11 data has capacity only for 47 cells. In demanding environments, the current size of SIB11 may not be enough. As the intra-frequency neighbors are typically given the highest priority, the inter-frequency and inter-system neighbor cell lists may remain incomplete. When relevant neighbors are missing from the SIB11, the UE cannot make the optimal cell selection, which may lower the performance in call success rates. SIB11bis is a backward compatible solution to correct the problem in SIB11. Hardware requirements: This feature does not require any new or additional HW.
110
86.
Directed Retry
Summary: Directed Retry initiates a handover to GSM network in case that congestion is met in WCDMA RAN. It is performed in case that UE is trying to establish a voice call in a WCDMA cell which is fully loaded. Benefits for the operator: This will improve KPIs concerning call setup success rate. The connections that would face congestion in AMR call RAB setup phase are directed to GSM system to continue the connection setup. Functional description: The Directed Retry feature makes inter system handover to GSM system in case of congestion is met in source cell of RAN. It will be done for NBAMR and WB-AMR calls. If a connection includes other RABs in addition to AMR RAB no directed retry is made. The directed retry takes place when the AMR RAB is setup. The RNC indicates an attempt to GSM by sending RAB ASSIGNMENT RESPONSE message with a RAB ID included in the list of RABs failed to setup and a cause value of "Directed Retry". After that the RNC begins relocation by sending the RELOCATION REQUIRED message to the Core Network with the cause value "Directed Retry" and Cell Global ID to indicate the target cell. The handover is blind because no inter RAT measurements are performed for the connection in question prior to the handover. The target cell is always the first GSM cell in the neighbour list of the source cell. Operational aspects: The operation is activated by an FMCG set parameter. That specific set can be linked to the cells that are wanted to use directed retry feature. In addition, at least one GSM neighbour cell has to be pre-configured. Counters for started, successful vs. unsuccessful and dropped Directed Retry based HHOs planned but will not be available before RU10.
111
87.
24 kbps Paging Channel
Summary: This feature allows 24 kbps data rate for Paging Channel (PCH). Benefits for the operator: Higher Paging Channel data rate eases paging message congestion and thus improves the end user experience when number of subscribers and call attempts are increasing. Functional description: The PCH data rate is increased to 24 kbps. This is achieved by using 240 bits Transport Block Size (TBS) with 10 ms Transmission Time Interval (TTI). With the 24 kbps configuration the PCH is mapped on a dedicated Secondary Common Control Physical Channel (SCCPCH). This means that two SCCPCHs are needed in a cell: one for Forward Access Channels (FACHs) and another for PCH. SCCPCH for 24kbps PCH requires SF128 code channel. Current implementation: Currently the Paging Channel (PCH) data rate is 8 kbps. Hardware requirements: This feature does not require any new or additional HW.
112
88.
BTS Auto Connection
Summary: The Flexi BTS Auto Connection feature enables the automated connection of the BTS to a server in the network, through which commissioning may be performed. This feature is part of "BTS plug and play" concept. Benefits for the operator: The prime benefit for the operator is a cheaper and quicker network rollout. After installation the automatic establishment of a connection allows the commissioning to be completed remotely without the need for a skilled commissioner on-site. Alternatively, the commissioning could be performed by a commissioning engineer using a remote connection. Functional description: In BTS Auto Connection new BTS is able to automatically request IP transport parameters from network by using DHCP protocol. Auto Connection procedure includes identification and, when available, location information that will help the installed BTS hardware to be correlated with the required logical configuration. Auto connection includes four phases: Step 1) Preparation, including pre-planning: Factory: The Flexi BTS is delivered from the factory with its initial SW. This SW is sufficient to start the BTS and execute the auto connection process. Initial SW allows the establishment of the IP connection over the transmission interfaces, although it is not necessarily the final SW build in use in the network. Site plan preparation: The planning data related to each new Flexi BTS are prepared using the standard tools. - DHCP server preparation. Since the auto connection phase is based on the usage of standard DHCP services, the DHCP servers are preconfigured with suitable options and vendor specific data. - CA server preparation, to ensure that the BTS is able to establish a secure connection to the auto connection server using CMP. HW plan generation: The hardware plan includes all the required mechanical installation data, such as location, necessary equipment, codes and installation as well as cabling instructions. Step 2) Installation and power on, BTS HW installation: The power cable, transmission link, antenna and actual base station are installed on site. Power on the Flexi BTS: When the base station is booted, it automatically runs self tests to determine whether the configuration is complete and correct to such extent that it will be able to perform auto connection. A successful start-up supports the auto connection with a high degree of reliability. The results of the start-up and self-test are reported to the installer as a simple visual indication. The results - including details of any failure - are also stored locally for later retrieval and failure analysis. After clear indication of the completed installation the installer may leave the site. Step 3) Start of auto connection When BTS is powered up it sends standard DHCP protocol request to obtains an IP address for itself, for a certificate management protocol (CMP) server and an auto connection server to which the BTS should register. BTS registers itself to the auto connection server over an established secure connection, using the information obtained from the CMP server. Step 4) Successfully registered BTS is commissioned either manually through a remote
BTS Site Element Manager or automatically by using the Auto configuration. Figure:
Current implementation: Currently IP transport parameters are defined manually by commissioning engineer. Hardware requirements: This feature does not require any new or additional HW. Supporting NetAct Features: Configuration NetAct Configurator functionality for BTS Auto
Channel Type Switching

Channel type switching is functionality where PS interactive/background radio bearer mapping is changed from DCH to HS-DSCH or from HS-DSCH to DCH. Switch to DCH is needed if use of HS-DSCH is not possible anymore. Switch to HS-DSCH is needed when RB is mapped to DCH but conditions to use HS-DSCH are fulfilled. DCH to HS-DSCH switch follows the basic policy that HSDPA is used every time when its use is possible. External Clock source is required A synchronization reference for BTS and RNC can be provided from external synchro-nization interfaces. The Flexi WCDMA BTS supports 2.048 MHz and GPS/PPS external synchronization interfaces. These interfaces can only be used for providing timing reference for the BTS system clock, not for synchronizing the transmission interfaces. The RNC supports 2.048 MHz, 2.048 Mbit/s and 1.544 MHz external synchronization interfaces.
114
89.
Flexible Upgrade of NRT DCH Data Rate
Summary: This feature allows the operator to control the upgrade of the DCHs allocated for the NRT RABs. This feature complements the feature Lightweight Flexible Upgrade of NRT DCH Data Rate. Benefits for the operator: CAPEX and OPEX savings can be expected due to the better resource utilization. Improved service availability and data rates also increase the end user experience. Functional description: With this feature the operator can control to the flexible data rate upgrades. It is possible to set the NRT DCH bit rate dependent DL traffic volume measurement high threshold separately for each data rate. In addition, the detection of the DCH thoughput is used to ensure the need for data rate upgrade. The DCH thoughput is measured in the RNC on layer 2. The operator can set the minimum accepted throughput below the DCH maximum data rate in terms of percentage as well as control the sliding window size and time to trigger parameters. Furthermore, it is possible to define the sliding measurement windows for radio link measurement reports that are used for Dynamic Link Optimization and PS data rate upgrades. By this it is possible to control the sensitivity of the algorithms. That is, if the change of the data rate is wanted to happen less sensitively, long averaging is used. There is separate control for DyLO and data rate upgrades. All this enables the control of adapting to the fast changes in the DCH data rates and radio conditions without causing unnecessary upgrades and downgrades of DCH data rate. Operational aspects: The operator can monitor the executed NRT DCH upgrades through existing counters. The counters are found in the Traffic Measurement.
115
90.
HSDPA 14 Mbps per User
Summary: The peak bit rate on HSDPA for a single user is increased to 14 Mbps. Benefits for the operator: This feature enables operators to offer higher HSDPA bit rates to premium data subscribers and increase data service revenue. Functional description: The HSDPA category 10 UE offers a peak radio interface bit rate of 14 Mbps with 15codes. With this feature, category 10 UE may receive data with its maximum bit rate when 15 codes for HSDPA are allocated in the cell. The maximum theoretical throughput of category 10 UE is 14 Mbps. In practice, the achievable throughput with this feature is limited by radio reception. The maximum theoretical throughput would require the use of a coding rate close to 1, that is, it would require error-free reception. Targeting error-free reception reduces the system efficiency and capacity. In all practical conditions, the throughput will be degraded if using coding rates close to 1, that is, having effectively no error correction. The quality of the radio reception depends on the received signal strength, radio channel, interference and transmitter and receiver imperfections. Operational aspects: Existing counters are available for monitoring HSDPA Iub throughput in the RNC (RLC) and radio throughput in the BTS (MAC-hs). Hardware requirements: In RNC196 and RNC450 a hardware upgrade is needed according to feature HSPA Peak Rate Upgrade in RNC196 and RNC450. This feature requires cell dedicated scheduler HSDPA baseband solution in UltraSite BTS and Flexi BTS System Module Rel.1 (FSMB). With Flexi BTS Multimode System Module (FSMC/D) HSDPA 14 Mbps per User is also supported with the Shared HSDPA Scheduler for Baseband Efficiency solution.
116
91.
HSDPA Dynamic Power Allocation
Summary: BTS allocates dynamically all available power to HSDPA. Benefits for the operator: Dynamic adjustment of the HSDPA power improves both user and cell throughput particularly at the cell edge, and increases the power utilisation efficiency. Functional description: BTS will dynamically control the amount of power used for HSDPA. All the power left after DCH traffic and common channels is used for HSDPA. This means that as long as there is HSDPA traffic in the cell, all the available PA power can be efficiently utilized at all times.
117
92.
HSDPA Service Indicator
Summary: Idle end user can be made aware of the HSDPA service area. Benefits for the operator: Increased awareness of service level means improved end user experience. Functional description: The NW indicates the HSDPA capability to the UE. The information is broadcast on SIB 5 and SIB 5bis. HSDPA capable cell means that the UE may consider this cell as part of the HSDPA coverage area for display indication only. When HSPDAEnabled parameter has value 1 in any/one cell in the same sector, SIB5 HSDPA capability indication can be triggered by the database. The HSDPA indicator is specified in 3GPP rel6 as a release independent item, thus also rel5 NWs and UEs may use it.
118
93.
HSDPA Soft/softer Handover for Associated DPCH
Summary: This feature provides HSDPA service in the whole cell coverage area and between the cells. Benefits for the operator: The end user experience is improved by the enhanced HSPA performance during HOs. Functional description: Soft/softer HO for HSDPA users enables HSDPA usage in the whole cell coverage area and between the cells. The following intra-frequency soft/softer HOs for associated DPCH are supported: - Intra-BTS intra-RNC softer handover - Inter-BTS intra-RNC soft handover - Inter-BTS inter-RNC soft handover Implementation of the above mentioned HOs ensures full coverage for HSDPA. Therefore, HS-DSCH is also supported for UEs with an active set size larger than one (to the UEs in the soft handover (SHO) region). A specific functionality is needed to prevent the use of SRNC anchoring for HS-DSCH in case of inter-BTS inter-RNC SHO. The serving cell change triggering to map the HS-DSCH to the radio link on Iur interface is prevented by switching the HS-DSCH to the DCH. From that on, the SRNC Relocation procedure can be performed normally using only DCH. However, if the branch(es) from DRNC is (are) released due to normal mobility, the HS-DSCH can be used again. Operational aspects: The BTS supporting this feature must be rolled out in the NW before activating this feature. The operator can follow the Soft/Softer Handover for the Associated DPCH with basic SHO counters like: 1) AS size for Associated DPCH 2) SHO Durations for Associated DPCH 3) Measurement Reports (1A, 1B, 1C) for Associated DPCH Therefore, the counters are similar to other basic SHO counters and are added to the SHO Measurement.
119
94.
BTS Synchronous Ethernet
Summary: BTS Synchronous Ethernet guarantees, thanks to its deterministic nature, a high quality clock recovery over Ethernet links. Benefits for the operator: BTS Synchronous Ethernet is an alternative solution for Timing over Packet which provides an accurate frequency reference for the BTS. BTS Synchronous Ethernet is an easy solution from network dimensioning and configuration point of view. Functional description: BTS Synchronous Ethernet, according to G.8261, provides a SDH like mechanism for distributing frequency information at layer 1. BTS receives the frequency information from the directly connected (next-hop) Ethernet switch or IP router via the Ethernet link. That next-hop node has an access of its own to a frequency reference source, because either it is also connected via Synchronous Ethernet to a node, or it has another access to a primary reference clock. By using Synchronous Ethernet on all transport nodes it is possible to create a completely frequency-synchronized Ethernet network. Differently to TDM network, this frequency accuracy is not needed for the proper functioning of the data plane, but rather for providing devices connected to the network (like a 3G BTS) with an access to reference clock. Figure:
Current implementation: Timing over Packet is currently available along with an alternative solution for synchronization over packet network. Hardware requirements: The Synchronous Ethernet slave functionality is supported on Flexi WCDMA FTIB, FTFB and FTLB transmission sub-modules. UltraSite BTS: AXCF is required.
120
95.
Dynamic Access Class Restriction
Summary: This feature introduces more flexible ways of controlling Radio Network Access and Domain Specific Access Class (DSAC) restriction. Operator can specify the Radio Network Access Restriction (RNAR) level separately in two different location areas and the DSAC restriction level in four different location areas for both core types. Benefits for the operator: The feature makes it possible to control and restrict the user traffic in emergency situations. Functional description: This feature brings enhancement to the current RNAR and the DSAC restriction features by adding the usage of the cell groups. User can define 10 traffic restriction groups. Each group has the type of restriction defined: 'RNAR' or 'CS-DSAC' or 'PS-DSAC'. Each group has its own id, restriction level definition and the functionality can be activated independently for each group. Each cell can be connected to a 'Radio Network Access Regulation function' or 'Domain Specific Access Restriction' group by selecting the group id for the cell. In addition, it is possible to activate the RNAR functionality and DSAC restriction for all cells in the RNC with one selection. Compliance: 3GPP Rel.6 TS 25.331 v6.5.0 Figure:
Operational aspects: Using Dynamic Access Class Restriction Feature is configured by using conventional configuration management operations towards RNC from NetAct or RNC EM applications. Traffic restriction is applied by setting the parameters related to this feature so
121
that wanted restriction level is achieved. Activating Direct Activation of RNW Changes Using NWI3 The feature is optional. To activate the feature related NetAct license have to be bought. Hardware requirements: This feature has no special HW requirements.
122
96.
Efficient ATM Capacity Sharing Using Circuit Emulation
Functional description: Structured Circuit Emulation Service (CES) allows efficient sharing of ATM transmission capacity. With CES, user can share ATM capacity for non-WCDMA applications, as another option to PDH/SDH transmission sharing (which is also supported). Transmission links based on ATM can be used for circuit-switched traffic (for example GSM Abis) with ATM Circuit Emulation Service (CES). This feature supports Unstructured and Structured Circuit Emulation Service (CES) in RAN2.0. Structured CES allows carrying n x 64k channels (Fractional E1) over ATM links, while Unstructured CES carries full E1s. Structured Circuit Emulation is supported using: * At Ultra WCDMA BTS: BTS/E1, JT1, T1 interface unit (IFU). * At NB/RSxxx: Core Controller variants with 16 E1 ports At the RNC site, Structured Circuit Emulation is terminated before the RNC using an Stand-alone ATM switch as a hub with E1/JT1/T1, like i.e. the AXC or the SURPASS hiD31xx.
123
97.
Enhanced Priority Based Scheduling and Overload Control for NRT Traffic
Summary: This feature gives the operator the possibility to select alternative methods for packet scheduling policy and downlink overload control. The operation is based on the radio bearer reconfiguration procedures. Benefits for the operator: Operator can offer and sell different QoS solutions based on the user subscription. This allows increased revenue. Functional description: Enhanced priority based scheduling algorithm by radio link reconfigurations brings new QoS differentiation capabilities to the network. Better QoS is achieved by enhanced bit rate allocation algorithm and priority handling. Existing NRT allocations can be downgraded or released if there are 'higher'/'higher or equal'/'any' priority users requesting capacity in the congested situation (enhanced priority based scheduling policy can be controlled with the RNC configuration parameter). The enhanced priority based scheduling function can be triggered by the congestion of the following resources: downlink power, uplink interference, downlink spreading code, BTS HW and Iub transmission. With enhanced overload control for downlink NRT traffic, the transport channel bit rates of the selected channels are decreased using the radio bearer reconfiguration procedure. In this way, the transmission power levels are decreased in the whole time domain, which in turn reduces variation in the total power level and improves QoS and capacity. Figure:
Operational aspects: When the radio bearer reconfiguration procedure is performed, the physical channel of the radio link, that is the spreading factor, is also reconfigured, as well as the BTS HW resources and transmission resources in RAN. By using new RNC configuration parameters the operator can set the minimum duration of the allocation before the reconfiguration takes place. Separate parameters for different cases are defined: one for enhanced overload control function and three for enhanced priority based scheduling function (own parameters for RBs to be downgraded or released and which have higher/equal/lower priority than the incoming capacity request has). With these timers, it is possible to prevent reconfigurations for very short allocations and thus avoid unnecessary signalling. The operator can use the counters to follow the pre-emptions and downgrades of the different radio bearers based on Traffic Class separation. The counters belong to Cell Resource and L3 Signalling at Iub Measurements.
124
98.
HSDPA Inter-frequency Handover
Summary: This feature introduces inter-frequency compressed mode measurement and handover capability directly from HSDPA to HSDPA. Benefits for the operator: User experience is improved due to faster HSDPA interfrequency handover and higher data throughput during the compressed mode. Functional description: Based on inter-frequency handover (IFHO) triggers, the RNC orders compressed mode on HSDPA so that the inter-frequency measurements can be performed on HSDPA without channel type switching to DCH. Inter-frequency handover can be triggered due to coverage and quality reasons, but also IMSI-based handover can be initiated. Based on the measurement results, the RNC selects the target cell and performs inter-frequency handover and an HSDPA serving cell change. The target cell can be an intra- or inter-RNC cell, depending on the defined neighboring cells. This feature also enables inter-frequency handover directly to HSUPA/HSDPA, even if the handover is started from DCH. If the HSDPA allocation is not possible in the target cell, handover is performed to DCH. Thus the following changes in the channel type are supported during the HSDPA inter-frequency handover: - DCH/HSDPA to DCH/HSDPA - DCH/HSDPA to HSUPA/HSDPA - DCH/HSDPA to DCH/DCH - DCH/DCH to DCH/HSDPA - DCH/DCH to HSUPA/HSDPA Channel type switching to DCH or FACH may be performed during the compressed mode, for example, if the active set is updated or inactivity is detected. Because there is no need to switch to DCH for inter-frequency measurements, high HSDPA throughput can be experienced during the compressed mode. Figure:
125
Operational aspects: Feature specific counters are available for monitoring the HSDPA compressed mode initiations and triggered inter-frequency handovers. Hardware requirements: This feature does not require any new or additional HW.
126
99.
HSPA Multi NRT RABs
Summary: This feature enables establishment of three simultaneous NRT (interactive or background) PS RABs, which are mapped onto HS-DSCH and E-DCH (or DCH for non HSUPA users) transport channels. Benefits for the operator: The usage of HSPA is possible in the case of multiple PS services. This allows the operator to utilize HSPA more efficiently. Functional description: This feature enables the allocation of up to three simultaneous NRT PS RABs on HS-DSCH and E-DCH/DCH. This means that three simultaneous PDP contexts can utilize the HSPA service. The RABs are multiplexed and demultiplexed in the MAC-hs and MAC-e entities in the BTS and in the UE. There are separate priority queues for each RAB in the MAC-hs and MAC-e entities. In downlink the BTS packet scheduler schedules data to the UE from each non-empty queue in turn. In uplink the UE MAC-e multiplexes data from several priority queues into E-DCH. If HSUPA is not supported, RABs are mapped to DCH in uplink as in the current implementation. With this feature RAB combinations up to three NRT RABs on HSPA are supported, with or without AMR. Also a streaming RAB can be combined with NRT RABs on HSPA when the Streaming QoS for HSPA feature is activated. The RABs may also be prioritized in the multiplexing based on their Scheduling Priority Indicator value but this requires the QoS Aware HSPA Scheduling feature. This feature will also extend the UL DCH bit rate support for HSDPA return channel with simultaneous AMR call. The new data rates for UL DCH are 128 kbit/s and 384 kbit/s. Figure:
Operational aspects: Feature-specific counters are available for monitoring of multi- RAB setup attempts, allocations and releases. Feature-specific monitoring of HSPA multi-RAB events is available in NetAct Traffica. Hardware requirements: This feature does not require any new or additional HW.
127
100. High Speed Cell_FACH

Summary: With this feature the HSPA is used in Cell_FACH state. With High Speed Cell_FACH more users can be supported in Cell_FACH state and smooth data transmission can be provided for users not requiring large data volumes. Benefits for the operator: End user experience is improved with better Cell_FACH state response times and high bit rates. For supporting UEs, below 100 ms setup time is expected. Setup time here refers the time difference between user action and the moment when first user data bits arrive to UE. Below 100 ms can be achieved if the starting RRC state is cell_FACH. In case of the starting state can also be cell_PCH. In addition to improving setup times, this feature also significantly reduces signalling load between BTS and RNC especially with UE applications requiring small amounts of data but frequently. Benefits only apply to supporting UEs. Functional description: This feature utilizes the 3GPP enhanced Cell_FACH state for downlink (Rel7) and uplink (Rel8). In the downlink direction the logical channels mapped to FACH transport channel in previous releases can be mapped to HS-DSCH transport channel. Parameters needed for the HSDPA reception in Cell_FACH state, i.e. HS-DSCH and HS-SCCH configuration and common H-RNTI identifier, are included in the system information broadcast. H-RNTI is an UE identifier needed for HS-DSCH usage. High Speed Cell_FACH introduces common H-RNTI, which is used to address multiple UEs in Cell_FACH state when UE does not have valid dedicated H-RNTI. The UE starts monitoring the HS-SCCH and when it detects the H-RNTI, it decodes the data from the HS-DSCH. When the common H-RNTI is used, the UTRAN specific UE temporary identifier, U-RNTI, is included in the MAC header for addressing the UE. When the UE has valid dedicated H-RNTI, it is used also in a Cell_FACH state. The common H-RNTI is only used for a short transitional period, during which a dedicated H-RNTI has to be assigned to the UE. In the uplink direction the E-DCH can be used in Cell-FACH and idle states. At the physical layer the preamble transmission with power ramping is similar to the Rel99 RACH, but the acquisition indication and assignment of resources is done for E-DCH. In idle mode or if no E-RNTI identifier is allocated to the UE, only Common Control Channel (CCCH) data transmission is possible. When the E-RNTI has been allocated collision resolution can be done and dedicated data transmission and control signalling is granted on E-DCH. When UL resources have been assigned, inner loop power control is started and the UE is able to send ACK/NACK and CQI for the HS-DSCH. In case High Speed Cell_FACH uplink is not used, for example in case of Rel7 UE, Rel99 RACH is used for the uplink. Then there is no dedicated uplink feedback signalling channel and HSDPA HARQ can not be used. Instead, MAC layer can be configured to execute fixed downlink retransmissions. High Speed Cell_FACH allows fast service for large number of users at the same time. For bursty data like SMSs and push-email the response times allow Cell_FACH state data transfer without frequent switching to Cell_DCH state. 3GPP defined maximum bit rates in High Speed Cell_FACH correspond to the UE category 2 in UL (1.45 Mbps with 2ms TTI) and UE category 12 in DL (1.8 Mbps). With High Speed Cell_FACH uplink the collision probability remains very low when the Rel99 PRACH has already reached probability of 1. BTS baseband resources are efficiently shared between HS-Cell_FACH state UEs since resources are not reserved for an UE during inactivity. This also improves resource utilization at the RNC, since Cell_DCH setup is not needed for short data burst. Especially considering increasing amounts of keep-alive messaging from smart phones, High Speed Cell_FACH has major benefits in BTS and RNC resource utilization. The control of state transitions takes into account the UE device type.
128
Figure: Current implementation: The FACH scheduling in downlink is done in the RNC MAC layer and further mapped to the SCCPCH at the BTS. The FACH carries following logical channels for the UEs in Cell_FACH state: - Broadcast Control Channel (BCCH) includes the RRC: System Information Change Indications. - Dedicated Control Channel (DCCH) for the UEs having the RRC connection established. - Dedicated Traffic Channel (DTCH) allows data transmission for the RRC connected UEs. - Common Control Channel (CCCH) is used by the UEs for establishing the RRC connection and when the UEs access a new cell due to cell reselection. The PRACH in uplink comprises of a preamble part and a message part. The AICH is a downlink physical channel, which is used for acknowledging the preambles transmitted by the UEs in the PRACH. 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 the increased transmission power.
129
101. Ethernet link aggregation for RNC

Summary: Ethernet link aggregation combines several Ethernet links between RNC and the next hop router/switch. Feature is supported for Iub, Iur, Iu-cs and Iu-ps interfaces. Benefits for the operator: Ethernet link aggregation provides Ethernet link protection without the need for an additional protecting Ethernet interface unit. Functional description: Ethernet link aggregation (IEEE 802.3ad) allows combining multiple Ethernet links between RNC and next hop router/switch as a means for link redundancy. Ethernet interfaces at the physical layer form a single link layer interface, also known as a link aggregation group (LAG) or bundle, according to IEEE 802.3ad. The IP layer sees the Link aggregation group as a single interface. Link aggregation will provide higher reliability between RNC and next hop router/switch. The Link Aggregation Control Protocol (LACP) is a used for exchanging port and system information to create and maintain LAG bundles. For the RNC196/450/2600, two Ethernet ports of the same Ethernet interface unit can be combined. Current implementation: Current redundancy is based on Ethernet unit protection (Requiring a working and stand-by NP2GE unit) or OSPF for redundancy. Operational aspects: If full resiliency is wished, then capacity of the Link aggregation group after failure of link(s) has to still match the capacity of the protected traffic. Hardware requirements: Feature requires NP2GE in RNC
130
102. Ethernet OAM

Summary: OAM is generally beneficial for detection and localizing faults on all logical interfaces (Iub, Iur, Iu-cs, Iu-ps), examining and reporting network status, monitoring network performance and provisioning and configuring parameters. Benefits for the operator: Ethernet OAM allows operator to reduce OPEX as it reduces the effort for maintaining an Ethernet network, especially - to locate and identify faults in an end-to-end Metro Ethernet network - to avoid site visits thanks to the remote fault management and connectivity test - to provide information, which is not available from other layers, e.g. network configuration. Functional description: Two Ethernet OAM protocols are in place from standardization point of view. Due to their different objectives, Link Layer OAM and Ethernet Service OAM protocols are not competing with each other and are actually complementary. Link Layer OAM (IEEE 802.3ah) operating at a single link and mainly targeting at "Ethernet in a first mile" application. BTS and RNC will support following functions: - Discovery: Identify peer device and its OAM capabilities. - Remote Failure Indication: Mechanism to provide fault information to the peer. Includes Dying gasp, link fault and critical events. - Remote Loopback: Used to check the quality of the links. - Link Monitoring: Event notification including diagnosis information (threshold alarms). Service Layer OAM (IEEE 802.1ag / ITU-T Y.1731) tackles the end-to-end Ethernet connectivity and service guarantees. BTS will support following functions: - Ethernet Continuity Check: Reports loss of continuity between two MEPs, within a MEG or unintended connectivity. - Ethernet Alarm Indication Signal: Used to suppress alarms after detection. - Ethernet Remote Defect Indication: Used by a MEP to communicate its peer MEP that a defect condition has been encountered. - Ethernet Automatic Protection Switching: controls protection switching operations. Current implementation: New functionality
131
103. Intelligent BTS Shutdown with BBU Unit

Functional description: In case of a power failure, the BTS is able to switch to battery power supply. Should the power failure continue for some time, the BTS proceeds toshut down the resources to ensure that it remains operational as long as possible. Different shutdown scenarios can be configured for the BTS by using local or remote connection (EM) to the BTS UI. The operator is able to define the alternatives for the BTS behaviour in main power failure situation. * A battery backup timer is defined for each cell in the BTS. The timer defines the time the cells using the WTR unit are allowed to stay in service while working on batteries. * After the timers for all the WTR units in the BTS have expired, all other units except the AXC and interface units, are also shut down to save the batteries. * The AXC will stay active as long as possible using the batteries. This is to make sure that other BTSs in the BTS chain remain unaffected by the power failure. * The BTS uses Common NBAP procedures to request the RNC to clear the cells with the intelligent shutdown procedure after the WTR timer has expired. Additional BTS HW is required (that is, a battery back-up unit). The intelligent shutdown assures the performance of the network in power failure situations. The Operator must be able to tune the shutdown timers in the BTS to ensure the maximum performance in a failure situation. The tuning should be done individually for each BTS so that it will correspond to the most probable shutdown time.
132
104. Iub Transport QoS

Summary: This feature provides further operator configurable traffic differentiation capabilities for the common channels, signaling bearers, R99 DCH and HSPA bearers. It also provides transport layer priority configuration support for the features QoS Aware HSPA Scheduling and Streaming QoS for HSPA. When Iub over ATM is used, operator configurable AAL2 priorities are implemented in the downlink direction in RNC2600 (NPS1) and in the Flexi WCDMA BTS for the uplink direction. In case of RNC196/450 (NIP/NIS/A2SU) the system default fixed downlink AAL2 priorities are provided. The AAL2 VCC differentiation possibilities are provided with the Path Selection feature, where the air interface channel type and AAL2 pathtype are used to control the VCC selection. The Iub Transport QoS feature introduces operator configurable AAL2 path type and AAL2 priority settings controlling the VCC and AAL2 queue selection. With Iub over IP the DSCP selection for the new transport bearer can be configured based on the radio bearer QoS attributes similar to the ATM case. The IP layer priorities are supported by the IP egress scheduling according to the basic IP features content. Benefits for the operator: Operator can benefit from reduced transport costs, because Iub Transport QoS allows the implementation of a strategy where services and individual user flows are treated differently on the same transport network. For example, business users on HSPA can receive a higher grade of service than lowerfee flat-rate HSPA users, following the Radio Network Layer scheduling priority settings. Functional description: With this feature the Radio Network Layer and Transport Network Layer traffic differentiation scheme can be aligned. ATM Iub With RNC2600 (NPS1) the AAL2 layer traffic separation is extended up to four AAL2priorities per VCC. The transport bearers AAL2 Path Type and AAL2 queue mapping can be configured by the operator following the Radio Network Layer traffic prioritization. The AAL2 priority has an effect on the DL AAL2 priority selection and the AAL2 Path Type has an effect on the AAL2 VCC selection. The selected AAL2 Path Type is also signaled at ALCAP ERQ message over the Iub once the feature is activated for the BTS. In case of HSPA bearers the Scheduling Priority Indicator (SPI) mapping is configured at RNL from the RAB QoS parameters and used for the service differentiation in the radio interface packet scheduling. Mapping between the SPI and transport layer AAL2 priority and AAL2 Path type is operator configurable. With Flexi WCDMA BTS four uplink AAL2 priority queues are supported. With Iub Transport QoS feature the uplink AAL2 layer priority information is carried from the RNC to the BTS with the NBAP signaling. This feature can be used together with path selection, which supports traffic differentiation in ATM VCCs. The AAL2 VCC combinations contain the option to label the VCCs with the different channel types and their combinations (DCH, HSPA, HSDPA, HSUPA) as well as different AAL2 Path Types Stringent, Stringent-bi-level and Tolerant and their combinations. ATM VCCs provide the differentiated treatment with CBR and UBR+ service categories. With Hybrid BTS backhaul, AAL2 priorities in the ATM Iub are carried within the VCs, which are then emulated over the packet network.
IP Iub This feature introduces the DSCP mapping based on the Radio Network Layer allocated channel type and scheduling priority. In case of HSPA bearers the Scheduling Priority Indicator (SPI) mapping is derived from the RAB QoS parameters at RNL and used for the service differentiation in the radio interface packet scheduling.Mapping between the SPI allocated by the RNL and transport layer DSCP is operator configurable. The queue corresponding to the PHB is selected based on the DSCP given for the transport bearer of the RAB according to IP features basic functionality. Figure:
Hardware requirements: With UltraSite, AXUB or AXC Compact is required for further AAL2 VCC combinations support with Path Selection feature. For the operator configurable AAL2 priority selection the RNC2600 (NPS1) and Flexi WCDMA BTS are required.
134
105. Support for Tandem/Transcoder Free Operation

Summary: This feature improves the speech quality in mobile-to-mobile calls by avoiding double transcoding. TFO/TrFO can be used for mobile-to-mobile calls within the WCDMA NW or between WCDMA and GSM networks. Benefits for the operator: Improved end user experience is reached because of better speech quality in mobile-to-mobile calls by avoiding double transcoding. TFO/TrFO also provides CAPEX and OPEX savings in transmission and reduces the need for transcoding hardware in the CN. Functional description: With TFO or TrFO the speech is transported in compressed form across the NW(s), which minimises the number of necessary transcodings. Subjective tests performed by ETSI show significant gain in the subjective quality for all speech codecs (FR, EFR and HR). From the RAN point of view, TFO and TrFO are similar functions. The selection between TFO and TrFO is done in the CN depending on the CN capabilities. TFO/TrFO can be used for mobile-to-mobile calls within the WCDMA NW or between WCDMA and GSM NWs. A TFO/TrFO operation requires the Iu UP support mode for predefined SDU sizes, version 2, that is supported in the RNC. TFO/TrFO can be used with all supported AMR codec sets. If the codec set includes more than one codec mode (that is, 12.2, 7.95, 5.90 and 4.75 kbit/s), rate control between the codec modes is supported, enabling link adaptation in the other end UE. In UL, the rate control is based on the maximum rate control received from the Iu interface. The rate control information is conveyed to the UE with the TFCC message on DCCH using AM RLC. In order to save radio capacity, the RNC filters frequent incoming rate control commands. In DL, the RNC selects the transport format based on the AMR RAB sub-flow combination received from the Iu interface. Operational aspects: TFO/TrFO can be switched on/off on a RNC basis. Detailed information about the TFO/TrFO operation with different AMR codec sets can be found from the AMR Codec Set (12.2, 7.95, 5.90, 4.75) and Lower Codec (5.9) feature description. Through a new counter the operator can follow the number of sent "Transport Format Combination Control" messages. The counter is added to RRC Signaling Measurement.
135
106. Route Selection

Summary: Route Selection allows defining dedicated VCCs for Rel99 and HSDPA traffic. The dedicated paths can be managed separately in the RAN transport NW according to their specific QoS targets. Benefits for the operator: OPEX and CAPEX savings are gained in the RAN transport NW. This feature makes it possible to direct different traffic types to dedicated transmission paths and use cost-optimized transport media and service categories according to specific QoS requirements. Functional description: The main idea of the Route Selection feature is to let the operator dedicate a VCC for the HSDPA traffic only. This allows the transport network to support the overbooking / statistical multiplexing of the HSDPA traffic, independently of the Rel99 traffic. The benefit is the resulting capacity savings for HSDPA in the transport network. With the Route Selection feature, the transport nNW is divided into three sections. The local switch section consists of the RNC and the ingress side of the local ATM switch, the Hub section consists of the egress side of the local switch to the egress of the last mile switch and the BTS section is the last link to the AXC/BTS as shown in the figure below. The BTS section is usually called the last mile and it is considered to be the bottleneck of the transmission NW. The main concerns in the local switch section are the VCC configuration in the RNC and the conversion of the HSDPA VCC in the ATM switch. In the shared VCC solution, the RNC in egress direction has a CBR VCC (or several VCCs) that carry the user plane traffic. The VCC is dimensioned so that the packet loss in the transmission NW is minimised. With the Route Selection feature, the RNC is configured so that now there are two CBR VCCs to each BTS (one for the Rel99 traffic and the other for the HSDPA traffic) dimensioned to be equal (or close) to the bottleneck. This way the HSDPA traffic can fully use the last mile capacity if there are no Rel99 traffic and vice versa. The VCCs can be dimensioned to be smaller, but then the last mile capacity could not be fully used. Also, if the HSDPA VCC is configured to be CBR, it gives the HSDPA traffic priority over the O&M traffic, which is typically UBR-type traffic. The Hub section consists of 3rd party ATM switches and the NW between the switches. In the Hub section, the NW should have Hub points where the multiplexing can be done. There should also be enough BTSs behind the Hub points to get the bandwidth savings. In the Hub section, the local switch should do a CBR-UBR conversion for the incoming HSDPA VCCs to enable the statistical multiplexing. For example, in the Hub point, the sum of the ingress HSDPA VCCs in the local switch is 40Mbps and the sum of the egress HSDPA VCCs is 30Mbps, giving a 10Mbps saving. Dimensioning is subject to operator decisions and depends on a number of factors: - Traffic volume - Service mix - Number of BTSs connected to the Hub point - Required QoS Correspondingly, the local switch needs to do an UBR-CBR conversion in the UL direction for the return channel.
136
Figure:
Operational aspects: Overbooking in the Hub section includes a risk of losing packets in the transmission NW during congestion because the RNC may send more data than the transmission NW can handle. The amount of overbooking is the operator's responsibility and cannot be affected by the RNC or BTS. Depending on the capability of the performance counters in the ATM switches, the traffic loss may be detected there and the overbooking may be adjusted. A difference between the Route Selection and the shared VCC solution is that there is no need to do the shared AAL2 allocation in the VCC to ensure the bandwidth for the HSDPA traffic. The idea of this reservation is to reserve some of the Iub capacity for the HSDPA traffic only to guarantee bandwidth and thus to ensure QoS. In case of Route Selection, the capacity is ensured with its own CBR VCC. Route Selection increases the need of AAL2 connectivity in the RNC because of the two CBR VCCs. In some cases the connectivity may become an issue if the RNC is connectivity-limited. Route Selection works also in AXU-A, but the Iub capacity gets fragmented because there is no AAL2 multiplexing. Through the existing counters the operator can see the ATM traffic amounts for each VCC. If AXC is used as an intermediate switch, it provides the ATM interface traffic throughput counters and a counter for discarded cells due to congestion per NE. The counters are found in the ATM Virtual Path Connection and ATM Virtual Channel Connection Measurements.
137
107. Satellite Iub

Summary: Satellite links can be used for BTS backhaul in cases where conventional transport is not available, economical or feasible, for example: - for mobile BTSs, deployed for special or emergency situations in areas without any transmission line or microwave access - on islands, in the mountains, in a jungle or any other remote area. Benefits for the operator: Satellite Iub enables operators to provide 3G coverage on problematic sites like on islands, high mountains or other remote areas by using satellite links. Functional description: Satellite Iub supports R99 voice and data connections as well as HSDPA when a BTS is connected to the RNC over a high delay satellite link. Handovers are not supported. The delay introduced by a geostationary satellite hop is approximately 240-280ms. Thus the two-way delay between the BTS and RNC may be around 600-700 ms. Delay variations are not expected to clearly increase. The delay of the satellite links also affects the round-trip time (RTT) as seen by the end user and has, thus, an impact on the perceived service quality in terms of, for example: - longer call set-up times - reduced achievable data rates - degraded voice quality (audible delay). Figure:
Hardware requirements: This feature does not require any new or additional HW in the BTS or RNC. Satellite transmitters, modems, installation equipment, for example, are not part of this feature.
138
108. Radio Network Configuration Management

Summary: Radio Network configuration management can be done by using NetAct or via RNC object browser in RNC element manager. Benefits for the operator: Efficient and flexible radio network parameter management functionality offered. Functional description: In general, there are two alternative ways for the operator to change the RAN configuration: element-level operations can be done using the GUI interface locally in the RNC or remotely from the NetAct. Bigger changes, which concern the RNW on a larger scale, can be done from NetAct by downloading a new plan to the RNC and activating it. The BTS can initiate operational state information changes for some network object due to BTS faults and BTS recovery actions. The local RNC GUI offers an operator an element-level service to operate the RNW. The local GUI is also available in NetAct. The radio network configuration in the RNC is stored in the RNW database and all modifications are updated to it. The modifications are updated to BTS sites and telecom processes as needed. Figure 66 illustrates the GUI-initiated modification sequence. The radio network configuration management in NetAct allows the operator to take a radio network plan into use in the network under the RNC or a part of it, or make changes to an existing configuration. The radio network plan is downloaded to the RNC from NetAct and is stored in the radio network database. The plan contains the planned objects in the network and their configuration with corresponding parameters. Those parameters are related to handovers, power control, admission control and so on. When the NetAct operator activates the plan made with the help of network planning tools, the BTSs and the RNC are configured by the system. The BTS checks whether the changed parameters require a restart. If restarts are required they are performed with minimum effect on traffic. RNC reports the status of the network to NetAct. Possible traffic downtime caused by the configuration updating is kept to a minimum.
139
109. Radio Network Online Monitoring

Functional description: The RNC radio network online monitoring gives real-time information of the radio network in a detailed level. Online monitoring is managed locally in the RNC by using the GUI. Online monitoring data can be stored in file. The data can also be seen online without saving the data to the file.
140
110. RNC Management Tool for Fault Localisation

Benefits for the operator: This feature enables an easy to use graphical diagnostics handling tool. Functional description: With this feature, the RNC Element Manager (EM) user is able to start the fault localization procedure in the RNC using a Graphical User Interface (GUI) application. This feature brings two new RNC applications: Diagnostics and State Handling GUI. The results of the procedure are automatically transferred to the EM as events without the need for manual polling of the history file. This feature allows the following: With Diacnostics GUI: * Scheduled diagnostics * Automatic unit state handling for diagnostics * Several units (of same type) can be diagnosed in one command * Diagnostic report filtering * Diagnostic report storing and printing With State Handling GUI: * Making state inquiries for units and I/O devices * Changing unit and I/O device states * Changing unit status info * Restarting units and the system Figure:
141
111. RNW Configuration Event Management

Summary: Introduces automatic radio network configuration parameter updating to NetAct Radio Access Configurator parameter database. Benefits for the operator: OPEX saving as no separate RNC radio network parameter upload needed before planning activities or daily operations. Functional description: With this function the RNC reports online to the NetAct locally made changes to the Radio Network configuration. Previously, it was necessary to upload the configuration manually to the NetAct once all changes had been made. With this feature, the changes are reported automatically as events to the NetAct, which then has up-to-date documentation of the Radio Network Configuration all the time. This function works even if there should be a break for some reason in the connection between the RNC and NetAct. The upload is automatically resumed once the connection has been restored.
142
112. Service Area Broadcast

Functional description: The WCDMA Service Area Broadcast (SAB), also known as Cell Broadcast Service (CBS), is a teleservice that enables an information provider to submit short messages for broadcasting in a specified area. These messages could be used for a wide variety of purposes such as informing about PLMN news, emergencies, traffic reports, road accidents, delayed trains, weather reports, theatre programmes, telephone numbers or tariffs. CBS messages are broadcast to all UEs within a particular area. These defined geographical areas are known as Service Areas. The RNC can be connected to up to four Cell Broadcast Centers (CBC). The Cell Broadcast Center is part of the core network and connected via lu-BC interface to the RNC. The Service Area Broadcast Protocol (SABP) is used for transferring CBS messages between CBC and RNC. The Broadcast/Multicast Control protocol (BMC) is used between RNC and UEs for message broadcasting on the radio interface. SABP uses TCP/IP/AAL5/ATM transport. SAB data is broadcast using the CTCH logical channel. At the MAC layer, the CTCH is mapped to the FACH transport channel, which is broadcast to the whole cell. Information about the scheduling of the SAB data is sent to the UEs in the System Information broadcast. Figure:
Operational aspects: There are specific measurements and counters for the Iu-BC interface. The operator can use the counters to follow the throughput of the SAB messages.
143
113. Subscriber Trace

Summary: Trace data, provided by subscriber or equipment trace in RNC, includes detailed radio interface data from the traced subscriber or equipment. The trace data provided by the RNC can be used for legal interception purposes and for troubleshooting, as well as for optimisation of the Radio Network. Benefits for the operator: Efficient NW troubleshooting with trace data. Functional description: The operator is able to set a trace of a specified subscriber from NetAct by using the user's IMSI or MSISDN number in HLR, local MSC/VLR or 3G-SGSN. When the trace function for a particular subscriber is activated in HLR, the HLR activates the trace in MSC/VLR and/or in the 3G-SGSN where the subscriber is registered. It is also possible to activate and deactivate a specific IMSI Trace directly from RNC using RNC EM/MML. (This functionality was introduced in RN2.0 GCD3.) Moreover, the operator is able to trace specified mobile equipment by using the equipment's IMEI number in local MSC/VLR or in 3G-SGSN. After the trace is on in MSC/VLR or in 3G-SGSN for a specified subscriber or equipment, the trace is activated in RNC for that subscriber or equipment when it has an RRC connection and an Iu connection is established. The trace for the subscriber or equipment is deactivated in RNC after the RNC receives a trace deactivation message from CN or when the Iu connection is released for that subscriber or equipment. The operator gets useful data on the subscribers or equipment actions both in Radio Network and in Core Network. This is possible because HLR, MSC/VLR, 3G-SGSN, GGSN and RNC all provide their own trace reports, which can then be linked to one subscriber or equipment by using the trace reference number. The trace reference number is specified when the trace is activated in NetAct by the operator. Trace data, provided by subscriber or equipment trace in RNC, includes detailed radio interface data from the traced subscriber or equipment. The trace data provided by the RNC can be used for legal interception purposes and for troubleshooting, as well as for optimisation of the Radio Network. The trace data provided by RNC is automatically transferred to NetAct for further processing. Therefore, the trace data is only available in NetAct. Trace can be used in: * Capacity and Coverage verification * Quality ensurance * Troubleshooting
144
Figure:
Operational aspects: Trace can be used in - Capacity and Coverage verification. - Quality ensurance. - Troubleshooting.
145
114. Transport Bearer Tuning

Summary: This feature allows the operator to configure the activity factors of Iub transport bearers. By optimizing the activity factor of different transport bearers it is possible to have higher number of simultaneous users in the system. Benefits for the operator: OPEX and CAPEX savings and improved end user experience are achieved by support of increased number of simultaneous data calls. Functional description: The activity factor is defined as the relation between average cell rate and peak cell rate. Average cell rate and Peak cell rate are part of bearer specific AAL2 Link characteristics (ALC). Tuning the activity factors is recommended to be done by the operator, based on the information of the actual activity of the bearers. In case the actual activity exceeds the configured activity factor, there is a risk of traffic loss on Iub, and consequently, the performance of the system as a whole is degraded. Risk related to traffic loss can be reduced by utilizing this feature with RAN06 Path selection, UBR+ for Iub user plane, and Dynamic scheduling for nrt DCH with Path selection. Operational aspects: For the transport VCC reserved bandwith there exist already CAC based counters. For AAL2 Scheduling monitoring in each VCC see the "Dynamic Scheduling for HSDPA Path Selection" and "Dynamic Scheduling for NRT DCH Path Selection" counters.
146
115. Automatic Definition of Neighbouring Cells

Summary: This feature introduces new measurements for HO statistics to verify the performance of current adjacencies. These measurements can be used for Neighbour Cell list optimization. Benefits for the operator: OPEX savings result from faster and less resource consuming neighbour list optimization. Increased revenue and improved end user experience are acquired through smaller number of dropped calls and better data throughput. Neighbouring Cell list optimization reduces the signalling load and ensures fast and reliable HO process of Mobile Terminals. Functional description: The automatic definition of neighbouring cells consists of operational and basic RNW measurement aspects. Operational aspect: The operational aspect means the centralised performance analysis of current adjacencies and automated optimisation of the adjacency lists using the performance statistics from RAN. HO adjacency lists are initially defined with RNW planning based on geographical locations and the estimated behaviour of the cells. However, this is not the optimal case; unnecessary cells may be included or necessary cells excluded. In order to guarantee good NW performance immediately after launch, it is essential to be able to analyse the performance of current adjacency lists, and if needed, to optimise the adjacencies according to the performance statistics from operational cells. This process needs to be fast and reliable and therefore aided with appropriate tools. In the portfolio, NetAct Optimizer provides means to optimise the adjacency lists based on measurements, while the other NetAct tools complement the solution with centralised change management and performance data collection and reporting tools. Basic radio network performance measurement aspect: In order to enable the NW management system to optimise the cell neighbour lists, several counters supplied by the RAN are needed (such as cell to cell HO statistics). The new HO measurements for the automatic definition of neighbouring cells are: 1013 Autodef SHO 1014 Autodef IFHO 1015 Autodef ISHO However, the new HO measurements can be activated and used as any other basic RAN performance measurements. When optimizing neigbours, the NetAct Optimizer also uses CPICH Ec/No difference information between the source and target cells. The optimizer retrieves this information directly from the RNC. This information is planned to be available as basic counters in later releases.
147
Figure:
Operational aspects: There have been introduced the new SHO, Intra Frequency and Inter System HHO PM measurements. In each measurement there will be counters for attempt and success HO.
148
116. OSPF for Iu-PS Redundancy

Summary: The OSPF feature is aimed to provide a redundancy solution for the Iu-ps interface between RNC and SGSN. As OSPF is unaware of the underlying protocol layers, it is well suited for different network environments and usable as a generic solution. Functional description: The OSPF Hello protocol is used between elements to monitor the route availability. When the route fails, the OSPF notices this and starts using an alternate route. Loopback addresses are used to separate physical (interface) IP addresses from the ones used for GTP routing: SGSN routes GTP traffic using a loop back address of the GTPU instead of using its physical (interface) addresses. Should the primary VCC go down, the GTP end-point is still accessible via the alternative route. Correspondingly, the RNC will use a loopback address of the Tunneling Unit in the uplink direction. IP packet connection protection in RNC and SGSN: * Dynamic redundancy with two or more alternative routes Route availability is monitored periodically * RNC re-routes the IP packets to the working route in case of a failure Quick recovery No human intervention needed immediately * Reduces traffic outages due a broken VCC (for example because of STM-1 line or equipment failures) If two NIUs are used, this gives increased equipment protection * Enhanced network protection Better experience of network availability
149
117. OSPF for Redundancy

Summary: This feature provides a redundancy solution for all RNC IP/Ethernet interfaces with the Open Shortest Path First (OSPF) protocol. As the OSPF is unaware of the underlying protocol layers, it is well suited for different network environments and usable as a generic solution. Benefits for the operator: The OSPF provides dynamic redundancy with two or more alternative routes allowing a quick recovery from failures without a need of immediate human intervention. Operators will benefit from enhanced network protection and better experience of network availability. Functional description: The OSPF Hello protocol is used to monitor the route availability between network elements. If a route fails, the OSPF notices this and the RNC starts re-routing the IP packets via an alternate route. If two interfaces on the same unit are used, this feature also gives interface protection. The OSPF is supported by most routers, MGWs and SGSNs. Figure:
Hardware requirements: Ethernet unit NP2GE is needed in the RNC.
150
118. Packet Scheduler Algorithm

Functional description: The Packet Scheduler (PS) functionality is a part of the Radio Resource Management (RRM) functionality of the RAN. Based on the radio interface interference information, capacity requests from UE (uplink) and received data in the RNC buffers (downlink), the PS allocates radio resources for the Radio Access Bearer (RAB). The traffic in the RAN consists of both real-time (RT) and non-real-time (NRT) radio access bearers. The proportion between RT and NRT traffic varies all the time. It is typical to the RT traffic that the load caused by it cannot be controlled in an efficient way. The load caused by the RT traffic, interference from other cell users and noise is called a non-controllable load. The capacity available which is not used for the noncontrollable load can be used for NRT radio access bearers on a best effort basis. The load caused by the best effort NRT traffic is called a controllable load. To fill the whole load budget and achieve the maximum capacity, the functionality of allocating NRT traffic needs to be fast. The capacity division between non-controllable and controllable traffic is illustrated in the figure below. The packet scheduler takes care of scheduling radio resources for the NRT radio access bearers for both uplink and downlink directions. The packet access can be implemented for both dedicated and common transport channels. The packet scheduler makes the decision of the used channel type for downlink direction. For uplink direction the decision of the used channel type is made by the UE. Figure:
Operational aspects: The Traffic Measurement can be used to follow the number of incoming resource requests, resource allocations and rejected resource requests.
151
119. Path Selection

Summary: Path Selection allows defining dedicated VCCs for selected types of traffic. This feature makes it possible to separate, for example, RT-DCH, NRT-DCH and HSPA traffic to dedicated paths. The paths can have different service categories and traffic parameters according to the required QoS targets. Benefits for the operator: OPEX and CAPEX savings are gained in RAN transport NW. This feature makes it possible to direct different traffic types to separate transmission paths and use cost-optimized transport media and service categories according to the specific QoS requirements. Functional description: Path selection divides the traffic into 3 path types (4 with HSUPA). Stringent path is designed to be used for RT-DCH, bi-level for NRT-DCH and tolerant for HSDPA and HSUPA. For each path a dedicated VCC can be configured. Thus alternative configurations are with 2 or 3 VCCs: - 4 VCC configuration: dedicated VCCs for HSDPA, HSUPA, NRT-DCH and RT-DCH - 3 VCC configuration: dedicated VCCs for HSPA, NRT-DCH and RT-DCH - 3 VCC configuration: dedicated VCCs for HSDPA and HSUPA, all DCH traffic in another VCC - 2 VCC configuration: dedicated VCC for HSPA, all DCH traffic in another VCC - 2 VCC configuration without HSPA: dedicated VCC for RT-DCH, another VCC for NRT-DCH For each interactive traffic class THP group the operator can define whether it is treated as delay sensitive or delay non-sensitive and accordingly, it is assigned stringent or bi-level path. Capability Set 2 for the AAL2 signalling protocol is supported. CS2 AAL2 Path type parameter is added to AAL2 signalling message if Path Selection feature is used. The following transport features may provide further benefits when used together with Path Selection: - UBR+ for Iub User Plane for the statistical multiplexing gains - Transport Bearer Tuning for configurable activity factor for DCHs - Dynamic Scheduling for HSDPA with Path Selection for reduced packet loss and delay on the Iub - Dynamic Scheduling for NRT-DCH with Path Selection for reduced packet loss and delay on the Iub - Hybrid BTS Backhaul for using Ethernet for the tolerant path. - Path Selection feature enables more versatile configurations for HSUPA transport solution.
152
Figure:
Operational aspects: The operator can monitor the used multi-RAB configurations through multi-RAB specific counters.
153
120. Extended Cell (180km)

Summary: Cell radius extended up to 180 km. Benefits for the operator: Economical method to build WCDMA coverage on rural areas. Functional description: 3G extended cell feature can be used to efficiently provide coverage in coastal and rural area, where big capacity or high data rates are not needed. Furthermore, new lower WCDMA frequency bands 850 MHz and 900 MHz make it possible to achieve larger cell sizes and also utilize the existing GSM cell raster. The feature is needed also with optical repeater cases (train tunnels, FlexiBTS remote RF heads) to overcome the decreased cell radius caused by the delay of optical cables. BTS has the main functionality of this feature. The feature is activated from the RNC/NetAct with Cell Range parameter. The operator has a possibility to modify Cell Range Parameter up to 180 km. In 3GPP, RACH/AICH detection & transmit power control delays define the cell range. SW implementation support up to 180km cell range. The feature activation is based on SW licences. Operational aspects: The basic principles for Extended Cell in WCDMA BTS are as follows: - A cell is called Extended Cell when its radius is >20km, - Cells with radius 20 km are treated according to normal baseband dimensioning rules, - CE dimensioning needs to be calculated separately for each Extended Cell. For example, if there is a 1+1+1 configuration, with 1 * 20 km cell and 2 * 100 km cell, it is needed to calculate 1* 20 km cell according to normal common channel dimensioning rules and 2 * 100 km cells according to Extended Cell dimensioning rules, - Extended Cell CE dimensioning rules are the same for all WCDMA frequencies - One or several of the cells in the BTS (supported configurations) can be configured as Extended Cells. Extended Cell common channel dimensioning in Flexi WCDMA BTS: - Up to 60 km cell: 27 CE (UL/DL), - Up to 120 km cell: 54 CE (UL/DL), - Up to 180 km cell: 80 CE (UL/DL). Extended Cell common channel dimensioning rules for UltraSite WCDMA BTS are as follows, provided that every Extended Cell has its own WSPC: - Up to 60 km cell: 16 UL / 16 DL CE, - Up to 120 km cell: 40 UL/ 16 DL CE, - Up to 180 km cell: 64 UL / 64 DL CE. Hardware requirements: For UltraSite WCDMA BTS, it is advisable to have at least one WSPC per Extended cell (+WSP for normal CCCH) for optimal CE consumption.
154
121. HSDPA Congestion Control

Summary: The purpose of the HSDPA Congestion Control feature is to maintain the maximum Iub load without causing a congestion situation. Benefits for the operator: The Iub congestion after hub points is hidden to the RNC, thus the full view of the congestion situation is not available in the RNC. With this feature the Iub HSDPA congestion can be detected at the BTS and even proactively prevented, which makes higher statistical multiplexing ratios feasible. Functional description: 3GPP Rel-6 includes mechanisms for Iub HSDPA data congestion detection and control. The HSDPA congestion detection mechanism is similar to the mechanism introduced for HSUPA. Congestion control is implemented at the BTS, and its target is to maintain the maximum Iub load without causing a congestion situation. The RNC includes build-up delay information and sequence numbering in the downlink FP frames. Both the buildup delay and the lost frames are monitored at the BTS and the congestion status is indicated to the congestion control algorithm. The existing FP layer flow control mechanism is used to signal how much data is the RNC allowed to send towards MAC-hs. Congestion detection algorithm for Iub congestion is based on the Multilevel Explicit Congestion Notification (MECN) method. The MECN algorithm introduces three delay thresholds instead of two thresholds used in the ECN algorithm. The MECN algorithm uses three different thresholds when congestion severity is evaluated: Minimum delay (Min_th), Middle delay (Mid_th) and Maximum delay (Max_th). When there is an increase in the delay, the probability of rate reduction for all connections increases at the same time. The algorithm selects independently for each flow whether the data rate is decreased and sends HS-DSCH capacity allocation messages with decreased credits towards the RNC. When Iub Transport QoS is in use, the probability of rate reduction is higher for low scheduling priority connections than for high scheduling priority connections, that is, statistically they are targeted more often by HSDPA Congestion Control. The congestion detection algorithm follows a two threshold probability curve similar to ECN. Different probability functions are defined for moderate congestions (delay between minimum and middle delay) and severe congestions (delay between middle and maximum delay). The amount of the rate reduction is more aggressive in the case of severe congestion. When maximum delay threshold is exceeded or packets are lost, rate reduction is always performed. Operational aspects: Feature-specific counters are available for monitoring HSDPA congestion and congestion control. Hardware requirements: This feature does not require any new or additional HW.
155
122. Dual-Cell HSDPA 42Mbps

Summary: Dual-Cell HSDPA of 3GPP Rel8 uses two adjacent WCDMA carriers to transmit data for a single UE. Together with 64QAM, peak bit rate is 42 Mbps. Benefits for the operator: Dual-Cell HSDPA increases the average user data rates 100% in low loaded network. Even in loaded networks Dual-Cell HSDPA can bring over 20% network level capacity gains, depending on the traffic profile. Gains can be achieved also at the cell edge. Functional description: Dual-Cell HSDPA can be used in the downlink direction for the UEs, which have interactive or background traffic to be scheduled. If conversational or streaming services are needed, dynamic switching between single-carrier and dual-carrier modes is done. UE sends the Channel Quality Indicator (CQI) information and L1 acknowledgements (HARQ) for both carriers on the common HS-DPCCH. Thus BTS scheduler takes into account differences in fading conditions between carriers, improving the spectral efficiency of the system. Dual-Cell HSDPA can be used together with 64QAM, enabling the peak data rate of 42 Mbps. In the MAC-ehs joint scheduler is used. The proportional fair scheduler logic is slightly enhanced so that the scheduling metric is calculated for each carrier separately but common throughput history is used. If same user has the best metric on both carriers, the user is scheduled on both carriers simultaneously. Scheduler aims to maximize the sector throughput in proportional fair manner, respecting QoS. BTS configurations up to 3 sectors are supported. Figure:
Current implementation: This is a new feature.
156
123. LTE Interworking

Benefits for the operator: LTE rollout phase interworking is supported and WCDMA services can be provided for LTE users in the areas where LTE is not yet available. Functional description: In LTE rollout phase the coverage is typically limited and UEs easily run out of LTE coverage especially in idle mode. This feature enables the LTE cell reselection when UE is in idle mode, Cell_PCH or URA_PCH state in WCDMA layer. Operator can set cell based camping priority for LTE capable UEs. The UE can then, on operator preference, select to camp on LTE once coverage is available. WCDMA, LTE and GSM can be prioritized with eight distinct absolute priorities, different Radio Access Technologies (RATs) having always different priorities. In idle, URA_PCH and Cell_PCH states, UE camped in WCDMA will periodically measure all higher priority RATs. Also lower priority RATs are measured when WCDMA quality criteria falls below a threshold. In addition to idle mode camping functionality also HO from LTE to 3G, without data forwarding, is supported. Figure:
Current implementation: This is a new feature. Operational aspects: Operator sets absolute priorities for WCDMA, LTE and GSM. Operator also defines thresholds, below which measurements on lower priority RATs or equal priority inter-frequencies are started and when reselection is made. Hardware requirements: This feature does not require any new or additional HW.
157
124. BTS backhaul over multiple IP interfaces

Summary: Feature enables to run Iub/IP over more than one IP interface in the BTS. An IP interface can be e.g. an Ethernet port. This allows to have either different physical backhaul paths for specific traffic types, or to distribute traffic among them via load balancing. Benefits for the operator: Load balancing provides the benefit for improved resiliency. Two or more IP physical paths with different quality can be used. Otherwise this would only be possible with additional costs of an external element (cost of HW, its management and providing outdoor capability for example). Functional description: With the feature more than one IP interface can be used in the BTS to transport Iub traffic. IP interface can be an Ethernet interface or e.g. IP over ML-PPP over E1. Two applications can be envisaged: 1: Traffic Separation, where each port can be used for specific traffic types. One port can be for example for low priority traffic, and the other for high priority traffic. This allows using different backhaul technologies without needing an additional Ethernet switch. The two technologies could be for example two DSL variants or alternatively MWR and DSL. Traffic is separated by using RU10 Transport QoS feature, and then further mapped to physical IP interfaces. 2: Load balancing, where Iub traffic is evenly split among the two interfaces. Benefits in this case are higher transport capacity and better redundancy. Figure:
Current implementation: Currently only one Ethernet port in the BTS can be used for Iub uplink traffic. Hardware requirements: FlexiWCDMA BTS has to be equipped with FTIA, FTIB, FTJA, FTFB or FTLB. UltraSite WCDMA BTS needs AXUF.
158
125. 4-Way RX Diversity

Summary: This feature introduces 4-branch diversity reception per sector with maximum ratio baseband combining of four uplink signals. Benefits for the operator: 4-Way RX Diversity gain is substantial, typically in order of 3 dB additional diversity gain. This enables reduced site number for building the coverage. Functional description: Feeders can be replaced by fibre optic cables using the Flexi feederless site concept. This brings significant cost savings as well as it is removing need for mast head amplifiers. Figure:
Current implementation: This is a new feature. Hardware requirements: This feature requires Flexi BTS Multimode System Module.
159
126. UBR+ for Iub User Plane

Summary: The UBR+ service makes it possible to benefit from statistical multiplexing gain in the RAN transport, and together with Path selection and Dynamic scheduling features, it increases the transport efficiency. Benefits for the operator: More efficient usage of the available Iub capacity mean OPEX and CAPEX savings in transport NWs. Functional description: UBR+ VCC is defined by its Minimum Defined Cell Rate (MDCR) and Peak Cell Rate (PCR). User traffic is able to utilize the free capacity up to the PCR value, and a guarantee of MDCR is given in order to support a minimum throughput in case of high Iub load. With Path Selection, one UBR+ VCC can be used for NRT-DCH traffic, and another UBR+ VCC can be used for HSDPA traffic. It is recommended to keep the real time traffic in CBR VCC to maintain the QoS. In this kind of configuration, UBR+ VCCs can share the free capacity up to the defined PCR. Capacity of MDCR is guaranteed also in case of high Iub load. Since the NRT traffic carried over the DCH has more stringent Iub delay requirements than HSPA, priorities need to be defined so that it is delivered with lower delay and delay variation. This is supported with UBR+ parameters that are operator configurable: - MDCR value for NRT-DCH should be set high enough for the guaranteed throughput. - Among multiple UBR+ VCCs, priority can be assigned by parameters settings. Division of excess bandwidth between NRT-DCH VCC and HSDPA VCC should be set so that NRT-DCH gets higher priority over HSDPA. (At NB/RSxxx this configurable prioritization is not available) Admission control for NRT-DCH is done against the MDCR value, unless Dynamic scheduling for NRT DCH with path selection feature is used. In that case admission control is done against the VCC bundle rate. Operational aspects: The operator can follow up through new counters in RNC 1) The INGRESS and EGRESS ATM cell traffic for each RNC ATM Interface distributed per ATM Service Classes: CBR, UBR and UBR+, 2) The discarded traffic due to ATM layer congestion per ATM interface.
160
127. HSDPA Upgrade from 5 Codes to 10 Codes

HSDPA 10 Codes merged with HSDPA 15 Codes. A separate feature is not needed for HSDPA 10 Codes as it is a subset of HSDPA 15 Codes feature. HSDPA 15 Codes feature is a further evolution for the features Basic HSDPA with QPSK and 5 Codes and HSDPA 16 QAM Support allowing higher peak data rates and increased average cell throughput. The peak bit rate for single user is 7.2 Mbps. Peak cell level total throughput is 10.8 Mbps (with code multiplexing). If features HSDPA 10 Mbps per user and HSDPA 14.4 Mbps per cell are activated then the figures are 10 Mbps per User and 14.4 Mbps per Cell. HSDPA 15 codes requires also the HSDPA Dynamic Resource Allocation feature to operate and for dynamic adjustment of the cell resources.
161
128. Robust Header Compression: Not Compliant

Research item for future software release
162
129. IP Header Compression: Not Compliant

Research item for future software release
163
130. AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75) (For Conversational AMR 12.2 kbps (voice service))
The AMR lower codec modes 7.95, 5.90 and 4.75 kbit/s will be added to the supported codec modes from the CS CN. This feature allows three separately configured AMR mode sets: {12.2}, {12.2, 7.95, 5.90, 4.75} and {5.90, 4.75}.A new management parameter is introduced to enable the operator to configure the different AMR mode sets on cell basis. When an AMR call is established, the RNC will make an attempt to set up a radio bearer configuration using the maximum size of the configured AMR mode sets that is the subset of the assigned AMR modes and conforms to the maximum rate control principle required for TFO/TrFO support. Iu Support Mode 2, which is used with TFO/TrFO by standard, enables only the maximum rate control.
164
131. Iu Link Break Protection

Nokia Siemens Networks provides following two transport resiliency features for Iu link break protection: 1) SCTP multi-homing (Iu control plane) 2) OSPF for Redundancy
165
132.
RAN - UE Connection Establishment (For Conversational CS 64 kbps (video call) and NRT PS data 32 to 384 kbps UL & DL)
The Radio Resource Control (RRC) connection allows a dialogue of signalling messages between the UE and RNC and also a dialogue between the UE and CN, including the support of the SMS. The RRC connection is needed for example for radio access bearer establishment, reconfiguration and release, SMS and Location Updating.The RRC signalling entities on the network side are located in the serving RNC. For the BTS the actual information on the RRC connection is transparent, with the exception of cell broadcast that can also be received by the packet data users.
166
133. Dynamic Scheduling for HSDPA with Path Selection

This feature reduces the HSDPA cell losses in case of Iub congestion. Radio layer scheduling rate is reduced. It also shapes the traffic according to the available last mile capacity (expressed by a VCC bundle rate). The end user experience is improved thanks to higher data throughput. The feature minimizes HSDPA packet losses and thus reduces overall transport delay between BTS and RNC. Functional description: This feature introduces a rate limit functionality, which controls the combined data rate of multiple VCCs. The VCCs are grouped into a bundle, which has a common peak cell rate (PCR) defined. The rate limit functionality takes care that the traffic in the bundled VCCs does not exceed the PCR set for the bundle. In a bundle there can be VCCs towards only one BTS. The rate-limited VCC bundle can be used to prevent the cell losses in the last mile of the transport NW or in another bottleneck area. Within the bundle, the rate limit functionality respects the VCC characteristics. For the CBR and UBR+ VCCs the defined minimum bandwidth for the VCCs is guaranteed. On the other hand, the individual VCC can use all the available capacity of the bundle if the PCR of the VCC equals to the PCR of the bundle. As in the Dynamic HSDPA Transport Scheduling, the flow control is based on the monitoring of AAL2 queue, operator definable Target Delay and four AAL2 buffer occupancy thresholds. The flow control algorithm however, is improved so that it takes into account the variable bandwidth of the UBR+ VCC. The traffic situation in other bundled VCCs and bundle parameters define the bandwidth available for the HSDPA.The flow control gets the available bandwidth information in short intervals from the bundling functionality and the thresholds are adjusted accordingly.
167
134. IP over ML-PPP on E1/T1/JT1 Interfaces

Multilink PPP allows carrying IP traffic over one or multiple PDH links. It can be used to enable IP transport on PDH based infrastructure like TDM microwave radios and PDH interface units in the BTS. Feature allows operator to postpone investments to replace existing PDH infrastructure when introducing IP transport. Functional description: Multilink PPP (Point-to-point protocol) allows to aggregate multiple PDH links into a single bundle and to carry IP traffic over. It is relevant to operators, who want to use IP based transport, but still have PDH based infrastructure in some part of the network. Examples are TDM Microwave radios: Without this feature those would have to be replaced new ones supporting packet transport, or - Installed Flexi WCDMA BTS with FTEB, FTPB, FTHA, FTFA: they can be migrated to Iub/IP without swapping the transport submodule and the legacy last/first mile equipment. The supported multiclass extension adds QoS support, needed especially for low capacity links. ML-PPP runs between Flexi WCDMA BTS and the next hop IP router (e.g. Cisco76xx).
168
135. HSUPA channel type selection:

The HSUPA channel type selection feature determines the optimal uplink transport channel for the user (RACH, DCH or E-DCH). The packet scheduler (PS) performs the channel type selection. The main input for the channel type selection is the traffic volume measurement, which the MAC layer of the RNC or the UE performs for each NRT RB. The result of the traffic volume measurement is handled in the PS as a capacity allocation request (for example, as a request for DCH or E-DCH). Channel type selection between DCH and E-DCH: The uplink channel type selection between DCH and E-DCH is performed by the UE-specific packet scheduler, handover control and cell-specific packet schedulers. There can be several cell-specific packet schedulers because of a soft handover. The UE-specific packet scheduler, handover control and the cell-specific packet scheduler also performs the E-TTI selection between 2 ms and 10 ms. When the E-TTI = 2ms is selected then UL SRBs is mapped on E-DCH. It is possible to allocate uplink E-DCH only in conjunction with downlink HS-DSCH. If the allocation of HS-DSCH in downlink is not possible, the packet scheduler tries to allocate the DCH in both uplink and downlink.
169
136. OCNS (Orthogonal Channel Noise Simulator): Not Compliant

OCNS/DLLG is study item for future releases and could be developed as per requirements.
170
137. NodeB Control Port (NCP)

This functionality is supported by VLAN Traffic Differentiation feature. RNC and BTS support tagging of Ethernet frames with VLAN (Virtual LAN) IDs according to the traffic type. Ethernet switches can aggregate and separate traffic according to VLAN ID values. Additionally, VLAN ID values can be used to mark the priority level of the traffic, as it is required by some Ethernet lease line service providers. Functional description: There can be up to 3 VLAN IDs defined per user plane (high, medium and low priority), one VLAN ID for control plane, one VLAN ID for management plane traffic and one VLAN ID for Timing over Packet. Ethernet frames are tagged in RNC and BTS with VLAN IDs according to the traffic type, for example, R99 voice, R99 data, HSPA. In case of Iub Transport QoS is in use, each bearer type can be mapped to one of up to three different specific VLAN IDs. Otherwise, a limited set of mapping options are supported. Ethernet switches in the network can separate the traffic according to VLAN IDs to different transmission media like microwave radios or DSL. Traffic from multiple base stations can be aggregated on Ethernet level for each traffic type separately. Ethernet bandwidth can be reserved on Ethernet switches for each VLAN separately. Some Ethernet leased line providers can support prioritization only based on the value of the VLAN ID. In that case this feature can be used to set the VLAN ID per traffic class according to the intended priority. If the VLANs run over different physical paths, then RNC and BTS will shape the egress traffic per VLAN. Admission control will be done against VLAN and IP-based route capacity. Within each VLAN a separate Bidirectional Forwarding Detection (BFD) session is running for supervision of the connectivity of that specific path. VLAN Traffic Differentiation is supported on Iu, Iur and Iub interfaces.
171
138. Timing over Packet for BTS

This feature introduces Timing over Packet support according to IEEE 1588v2. Timing over Packet allows synchronization of the WCDMA Ultrasite BTS or Flexi WCDMA BTS through an Ethernet physical interface. Timing over Packet requires a master clock at the RNC site. Slave clocks need to be installed in the BTSs. Functional description: In the Timing over Packet (ToP) solution there is a ToP master clock at the RNC site (or at another place in the network where a suitable reference clock can be accessed). The ToP master clock and the BTSs communicate through ToP messages according to the IEEE 1588 v2 protocol. The master clock sends synchronization messages (which carry a time stamp) through the Ethernet/packet network to the BTSs, from which the BTSs then recover the original reference clock. Timing over Packet can be applied with all packet-based backhaul solutions, i.e. Iub over IP as well as packet-based backhaul with Pseudowire, where ATM based Iub is carried over a packet network.
172
139. HSUPA Pre-emption Light

In accordance with the RT-over-NRT approach, NRT HSUPA users and NRT DCH users are downgraded or released in order to admit incoming voice users in case of scarce BTS resources in UL.
173
140. BTS Power Saving

In areas which have multiple frequency layers one or several layers can be shut down during low load periods. Functional description: Cells in one BTS can be grouped for Power Saving Mode (PWSM) purposes. Cells in PWSM group typically have coverage in the same sector, and Shutdown Order (SO) parameter defines the order in which cells are shut down within one BWSM group. Shutdown Order value 0 is reserved for the remaining cell, which is typically the cell not to be shut down. Also the last remaining cells can be configured to be shut down. Total BTS shut down can be a feasible solution in special cases, for example in the indoor office environment with macro cell coverage from another BTS. The PWSM concept allows operator to control flexibly the use of this feature according to cell configuration and power amplifier mapping. RNC monitors the load in downlink and uplink directions and triggers the cell shutdown once all the following operator adjustable conditions have been met in a cell: - Time of day - No emergency calls in cell - Traffic load in the cell goes below the defined threshold - Duration of low traffic - Traffic can be fitted into those cells, which remain active - UEs served by another RNC allowed or not present, according to operator definition Prior to the cell switch-off in BTS, the cell is barred. The RNC will send NBAP: Cell Deletion -command to the BTS. During cell deletion the existing traffic is moved to other cells. The BTS reacts to this message by turning the power amplifier to stand-by mode to achieve best possible power savings. After cell shutdown, the RNC monitors the load on the active cells. A shutdown cell can be activated when the following conditions are true: - Traffic load in the active cells exceed the defined threshold - Duration of high traffic If complete BTS shutdown has been performed, the cell activation is done at the defined time of day. When one power amplifier is shared among multiple cells, the cell shutdown needs to be done simultaneously for all those cells. Otherwise this feature does not bring benefits and can not be used.
174
141. Directed RRC Connection Setup

Functional description: Directed RRC Connection Setup provides an efficient way to balance the load between two frequencies. The load is balanced between cells of the same sector inside one BTS. This feature uses RRC Connection Setup message that is sent on FACH before setting up the dedicated channel. It is possible to allocate resources on another cell without affecting the connection setup procedure. The cell load status of different frequencies is checked at this early stage and the traffic can be balanced over several frequencies. The algorithm checks whether a load of an initially accessed cell (cell1) exceeds the load of another cell of different frequency (cell2). If so, the connection establishment is directed to the less loaded cell. It is also possible to define an adjustable hysteresis for this operation using dedicated radio network planning parameters (called load_threshold in the figure). The operator can adjust these parameters separately for the uplink and downlink. By balancing the load on different frequencies the capacity available can be used efficiently. Operational aspects: There are counters defined for following the number of executed RRC Connection Setup redirections. The counters belong to Service Level Measurement.
175
142. Macro Diversity Combining and Splitting

Functional description: In a soft handover a UE is connected to two or more cells, and the Iub and Iur DCH data streams coming from the different BTSs are combined in the serving RNC to one data stream in the uplink direction. In the downlink direction the DCH data stream is split towards the BTSs. The macro diversity combining in the RNC is based on the information received from the BTSs in the FP frames, namely the transport-block-specific CRC check results and the estimated quality information. Reliable soft handover transmission in the radio interface requires that the target-UEspecific Connection Frame Number (CFN) information is included in the Iub data streams. In the RNC one UE may have up to three soft handover branches. In a softer handover the UE is connected to two or more cells, but the cells belong to the same BTS equipment. Therefore, macro diversity combining and splitting can be done at the BTS. The softer handover combining uses optimised receiver processing, that is, received signals are combined at the symbol level (maximum ratio combining). At the BTS, the softer handover can be done for three radio links between all cells in a six-sector configuration. It is possible to use two levels of macro diversity combining: first the softer handover combing at the BTS and then the soft handover combing at the serving RNC. The soft and softer handovers are applicable for dedicated channels.
176
143. Dynamic Routing for the Iub

Summary: This feature introduces a number of functionalities, which allow operators to build new redundancy schemes, reduce configuration effort in site routers and efficiently use multiple BTS interfaces in parallel. Following new functionalities should be supported: - Virtual / Service IP addresses for User, Control and Management Plane - OSPF routing protocol - Multipath (equal cost multipath) and constrain/policy-based routing - BFD depending routing entries (indirect route status based on BFD availability). Benefits for the operator: Feature helps customer to save OPEX and CAPEX, as it allows building more robust networks with an improved resilience. It also reduces configuration effort using BTS embedded functionality. Functional description: This feature introduces a number of new functionalities for the Iub: - Virtual IP addresses: In addition to the "transport" IP address allocated to the BTS' Ethernet interface, also separate "service" IP addresses from another subnet will be used for terminating User, Control and Management Plane traffic. Logically those service IP address will be connected to the "transport" IP address via an IP router. This allows e.g. to use indirect route entries in the next-hop router, which can be then controlled dynamically. - OSPF routing protocol: BTS and RNC are supporting OSPF Hello messages as well as Link State Advertisements (LSA), which are used towards other OSPF capable IP routers. This allows e.g. to reduce configuration effort in the other routers in the network, because indirect routes towards the BTS do not have to be configured manually. When there are multiple paths to the same BTS (enabled via the feature BTS Backhaul over multiple IP Interfaces), then traffic can be automatically re-routed in case of link failures. - BFD towards IP routers:38 (107) Nokia Siemens Networks DN0671022 Version 1.7.0 BFD messages will be exchanged with other IP routers for fast detection of network problems and according consecutive actions, e.g. change of route entries. Figure:
Hardware requirements: Requires IP capable interfaces in BTS. Requires AXCF in UltraBTS. Requires NP2GE in the RNC.
177

Aircel 3g Features Document

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Aircel 3g Features Document

Diunggah oleh

Hak Cipta:

Format Tersedia

RAN Feature Description Document for Aircel

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

Copyright 2009 Nokia Siemens Networks. All rights reserved.

Copyright 2009 Nokia Siemens Networks. All rights reserved.

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

RAN Procedures for the Idle UEs

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

RAN - UE Connection Establishment

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

Management of the Connected Mode UE

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

Radio Access Bearer Establishment and Release

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

Radio Link Allocation for Real-Time Radio Access Bearer Services

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

UE Location Management with Handover Procedures

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

Packet Data Transfer States

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

Encryption and Integrity Protection

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

10. Packet Data Handling on Iu

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

11. Multi-RAB: AMR + 3 PS data

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

12. Multi-RAB: CS data + PS data

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

13. Admission Control Algorithm

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

14. Resource Manager Algorithm

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

15. Power Control Algorithm

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

16. Load Control Algorithm

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

17. Soft Handovers

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

18. Inter-Frequency Handover

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

Copyright 2009 Nokia Siemens Networks. All rights reserved.

3G Features Description - Aircel

19. WCDMA - GSM Inter-System Handover

Copyright 2009 Nokia Siemens Networks. All rights reserved.