UTRAN UR11.1 Optional Feature Description

Transcription

1 UTRAN UR11.1 Optional Feature

2

3 UTRAN UR11.1 Optional Feature Version Date Author Reviewer tes V /04/05 ZTE t open to the third party 2012 ZTE Corporation. All rights reserved. ZTE CONFIDENTIAL: This document contains proprietary information of ZTE and is not to be disclosed or used without the prior written permission of ZTE. Due to update and improvement of ZTE products and technologies, information in this document is subjected to change without notice.

4

5 FIGURES Figure 1-1 Logical Architecture of CBS System... 7 Figure 2-1 An example of DSAR activated for both CS domain and PS domain Figure 2-2 Enhanced Iur-g Handover Procedure Figure 2-3 Handover from UMTS to GERAN Figure 2-4 Handover from GERAN to UMTS Figure 2-5 Handover from UMTS to GSM Figure 2-6 Handover from GSM to UMTS Figure 2-7 UTRAN to E-UTRAN Inter RAT HO Figure 2-8 E-UTRAN to UTRAN Inter RAT HO Figure 2-9 SR-VCC Figure 2-10 Video Call Fall-Back to Voice Figure 2-11 Schematic Diagram of the Iu Flex Networking Figure 2-12 Networking under MOCN Network Sharing Figure 2-13 Networking under GWCN Network Sharing Figure 2-14 Dedicated Frequency Sharing Network Figure 2-15 Four operators shared Iub interface Figure 2-16 PA Efficiency with D-PT Technology Figure 2-17 Mechanism of Four-Antenna Receiving Diversity Figure 2-18 Logical Connection of Transmit Diversity Figure 2-19 Electrical Tilt Antenna System Figure 2-20 A-RAKE receiver structure Figure 3-1 ATM Protocol Stack of IuCS Interface Figure 3-2 ATM Protocol Stack of IuPS Interface Figure 3-3 ATM Protocol Stack of Iur Interface Figure 3-4 ATM Protocol Stack of Iub Interface Figure 3-5 AAL2 QoS Differentiation Figure 3-6 VLAN Tag Figure 3-7 PPP/MLPPP Protocol Stack

6 Figure 3-8 Application of IEEE 1588 Clock Synchronization Figure 3-9 IP Protocol Stack on Iub Interface Figure 3-10 Iub Interface Transmission through the Satellite Figure 3-11 IP Protocol Stack on IuCS Interface Figure 3-12 IP Protocol Stack on IuPS Interface Figure 3-13 DS0 Cross Connection Figure 3-14 IP Protocol Stack on Iur Interface Figure 3-15 LACP Figure QAM Constellation Graph Figure 7-1 Basic Principle of 2 2 MIMO Technical Solution Figure 7-2 VAM Option with MIMO Figure 7-3 F-DPCH Multiplexed Figure 7-4 Enhanced UE DRX TABLES Table 2-1 Types of Transmit Diversity and Physical Channel Supported by ZTE Table 3-1 Types of AAL Services Table 3-2 Features of Various ATM Services Table 4-1 HSDPA UE Category Supported by ZTE current version Table 6-1 HSUPA UE Category Supported by ZTE

7 1 Services and Radio Access Bearers 1.1 ZWF WB-AMR Speech Support This feature can provide high quality of voice which makes the voice more natural, and provide high quality telephone, voice and conference video services. AMR-WB, which is the abbreviation of Adaptive Multi-Rate Wideband, is a wideband voice coding standard adopted by both ITU-T and 3GPP. It is also called G722.2 standard. Since AMR-WB supports 50~7000Hz speech bandwidth and employs 16KHz sampling, compared with 300 to 400Hz speech bandwidth and 8KHz sampling supported by AMR-NB, users can feel the voice more natural, more comfortable and more distinguishable. ZTE RAN equipment supports all the nine speech rates of WB-AMR sessions, which are 23.85Kbps, 23.05Kbps, 19.85Kbps, 18.25Kbps, 15.85Kbps, 14.25Kbps, 12.65Kbps, 8.85Kbps, and 6.6Kbps, together with the mute rate 1.75 Kbps. The feature also supports any combination of the above rates. Whether WB-AMR coding is used and what rates to be used are decided by CN according to user s signing information and the terminal capability. The RAB parameters of ZTE RAN equipment, used to bear sessions of AMR-WB service, follow the definition in the 3GPP TS

8 1.2 ZWF PS Signaling RAB for IMS This feature supports signaling transmission of IMS system (using SIP or SDP protocol). The IMS employs the Session Initiation Protocol (SIP) and the Session Protocol (SDP) to control services. As defined in the 3GPP , the SIP/SDP exclusively occupies an RAB. The SIP/SDP does not require high bandwidth, which generally corresponds to 5% of media stream bandwidth. It has certain requirements for delay and no packet loss is allowed. Therefore, the data transmission model is similar to that of interactive services. But IMS signaling needs to be ensured to have a higher QoS priority than other common traffic classes. Besides the four existing traffic classes, a new traffic class needs to be defined to transmit SIP/SDP signaling. On the basis of interactive services, the 3GPP has defined a new parameter to indicate that this RAB bears SIP/SDP signaling. For PS-based voice or video services in the IMS, the UMTS uses an interactive PDP context to bear SIP/SDP signaling and uses another session PDP context to bear RTP/RTCP stream. These two PDP contexts have the relationship between primary activation and secondary activation. That is, they have the same PDP address. This ensures that signaling flow and media stream are consistent in IP routing. UE initiates the SIP/SDP PDP (primary PDP) activation flow first. The CN assigns an interactive class RAB and configures signaling indication for it. This indicates that this RAB bearer is IMS signaling and this RAB requires high priority, low delay, but small bandwidth. Then, UE initiates the second PDP (secondary PDP) activation flow. The CN assigns a PS conversational RAB to bear IMS voice or video packet stream. And this RAB requires high priority and low delay. ZTE RAN equipment supports the IMS signaling which is compliant to 3GPP TS According to the RAB parameters assigned by the CN, the RNC judges whether an interactive RAB bears common user data or IMS signaling. If the interactive service bears IMS signaling, the RNC will provide an extra QoS class for this interactive service.

9 1.3 ZWF Cell Broadcast Service This feature is used to support cell broadcast short message service and could be utilized to deploy text broadcast services like weather forecast, traffic information and etc. ETWS is expected to be deployed based on CBS system to alarm people in the area where disaster, for example earthquake, typhoon and tsunami, takes place. CBS is a basic tele-service defined by UMTS to supply text broadcast service in the mobile telecommunication system, and is called SMS-CB as well. The main difference between CBS and SMS lies in that the receiving target of SMS is a specific user in the network but the target of CBS involves all users in a certain area, including roaming users. The minimal granularity of address of CBS is a cell in PLMN. The content of CBS could be but not limited to: service notice, weather forecast, traffic information, international and domestic news, emergency events, advertising and etc. The logical architecture of CBS system is shown in Figure 1-1. Figure 1-1 Logical Architecture of CBS System UE UE UTRAN de B de B RNC Routing de (e.g. 3G- SGSN) Cell Broadcast Center (CBC) Iub Uu Iu Bc 1

10 In Figure 1-1, CBE (Cell Broadcast Entity) is the source of CBS content, interface to information provider and is in charge of formatting CBS messages. CBC is cell broadcast center and is in charge of the storage and the management of CBS messages. CBC connects to RNC via Iu-BC interface standardized by 3GPP. RNC receives commands and CBS messages from CBC and executes the broadcasting procedure in the air in the certain area. RNC also needs to give response to the CBC inquiring and report broadcasting states of CBS messages. ZTE RNC supports standard Iu-BC interface and its protocol SABP (please refer to 3GPP TS25.419). ZTE RNC can be connected to one or more CBC products from the third party with standard Iu-BC interface. ZTE RNC also supports ETWS service (please refer to 3GPP TS ) to activate user to receive alarming CBS message in case of a disaster. To enable ETWS function, CBC and UE are required. U ZWF21-02-A VoIP Package ZWF PS Conversational RAB for VoIP This feature provides IMS video and voice service, that is, it provides radio access bearer for PS AMR or WB-AMR services in PS domain. Coded voice and video data is encapsulated in IP packets.

11 The IMS introduced into the R5 version by the 3GPP provides universal network architecture of multimedia service in an IP-based network. It also makes it possible to bear AMR or WB-AMR services based on PS. These services require higher real time requirements than those of the interactive services, background services, and streaming services that generally borne by PS. The CN is required to configure traffic class as session when establishing the RAB of this type of services. ZTE RAN equipment supports PS session services: According to the parameters assigned by the CN, ZTE RAN equipment can provide a higher priority for PS session services during the packet scheduling and RRM algorithm processing to ensure the QoS performance required by session services, such as GBR, delay, and jitter and provide better services. The improved user plane supports multiple PDU lengths of RLC in UM mode to match data load. It also reduces the padding resulting from RLC segmentation and reassembly, and enhances the efficiency of payload transfer rate of an air interface. Support the establishment of PS IMS signaling RAB to bear SIP/SDP stream. For details, refer to the function ZWF PS IMS Signaling Bearer. Support the reduction of IP header overhead in VoIP packets by means of the PDCP header compression algorithm. For details, refer to the function ZWF Robust Header Compression. The RAB radio parameters of ZTE RAN equipment, used to bear PS session services, follow the definition in the 3GPP TS

12 1.4.2 ZWF Robust Header Compression This feature supports compressing IP header of the service data in PDCP layer to reduce the radio bearer bandwidth required for VoIP service and enhance the capacity of system VoIP service. When a radio link bears VoIP service, the overhead of the IP packet header is large. A VoIP data packet includes an IPv4 header (20 bytes), a UDP header (8 bytes), and an RTP header (12 bytes). When IPv4 is used for bearer, VoIP protocol header needs altogether 40 bytes; the header of IPv6 is 40 bytes; therefore, VoIP packet header amounts to 60 bytes; but in 12.2K AMR codec voice, a frame only occupies 32 bytes. Thus, the data payload in the VoIP packet is even smaller than the protocol header. For a radio link which can only provide limited data bandwidth, direct VoIP service bearer will waste a huge number of radio resources. Between a terminal and a UTRAN access point, channelization code, scrambling or other user IDs are used for addressing. This is a point-to-point connection and it is unnecessary for both call parties to transfer complete RTP (RTCP)/UDP/IPv6 (IPv4) header in each frame. IP header can be compressed through negotiation to reduce the waste of radio resources. However, characteristics of a radio link make a common IP header mark compression plan unable to work well. First, a radio channel has path loss and must bear 10-1 ~10-3 Bit Error Ratio (BER); second, the Return Time (RTT) may be as long as 100ms; last but not least, the residual BER should be taken into consideration. That is, sometimes a low layer submits an undetected error frame to a higher layer. The 3GPP introduces the robust header compression ROHC algorithm defined in the RFC3095. This algorithm can effectively compress header on a link with a long RTT and high error rate. The ROHC enhances the error recovery mechanism. Each compressed header contains a checksum calculated according to the original uncompressed header. Loss of synchronization of context can be repaired at the receiving terminal based on this checksum. After the adoption of the ROHC technology, IP/UDP/RTP protocol header

13 may be compressed to one byte. This greatly improves the bandwidth efficiency of VoIP bearer on a radio link ZWF PS Conversational RAB for VoIP over HSDPA This feature supports IMS video and voice services over HSDPA. This feature supports PS session RAB over an HS-DSCH channel to support AMR or WB-AMR services in an IMS subsystem. Coded voice and video data is encapsulated in an IP packet and transmitted. The SIP/SDP data stream and RTCP data stream of VoIP service are characterized with bursts. The DCH bearer which employs semi-static configuration mode is not good for the effective use of system resources. The effective multiplexing and fast scheduling of the HS-DSCH are better for VoIP service bearer. The spectral efficiency of the HS-DSCH is higher than that of DCH. It also helps improve the VoIP service capacity of the system. For VoIP service information, please refer to the function ZWF PS Session VoIP Service Bearer.

14 1.4.4 ZWF PS Conversational RAB for VoIP over HSUPA This feature supports IMS video and voice services over HSUPA. This feature supports PS session RAB over an E-DCH channel to support AMR or WB-AMR services in an IMS subsystem. Coded voice and video data is encapsulated in an IP packet and transmitted. The SIP/SDP data stream and RTCP data stream of VoIP service are characterized with bursts. The DCH bearer which employs semi-static configuration mode is not good for the effective use of system resources. The effective multiplexing and fast scheduling of the E-DCH are better for VoIP service bearer. The spectral efficiency of the E-DCH is higher than that of a DCH. It also helps improve the VoIP service capacity of the system. For VoIP service information, please refer to the function ZWF PS Session VoIP Service Bearer. 2 Radio Network Functionality 2.1 Connection Management ZWF SIB11bis

15 This feature supports the cell System Information Block broadcast of the SIB11bis, realizes the broadcast of more adjacent cell information over complicated networking environment (such as dense urban area) and optimizes cell reselection of the terminal. Limited by the length of the broadcasted information block, SIB11 can broadcast information to up to 96 adjacent cells, including intra-frequency cells, inter-frequency cells and inter-system cells. In the complicated networking environment with multiple frequency points, multiple frequency bands, and multiple systems, the configuration of adjacent cell broadcasting is a bottleneck. The SIB11bis extends the adjacent cells broadcasting capability of SIB11 with the adjacent cell number doubled ZWF Domain Specific Access Restriction (DSAR) This feature enables operator to efficiently control access to a specific Core Network domain under critical conditions (e.g. emergency situations, situation of overload, etc.) to avoid performance problems due to the user traffic s exceeding the network capacity. A normal UMTS UE is assigned an access class (AC) randomly from 0 to 9; this is stored in USIM card. A special UE may also be assigned an AC from 11 to 15; these would be typically used by emergency services (for example, fireworks, ambulance). AC with 10 is used for emergency calls. A mapping between AC and Access Service Class (ASC) is indicated in SIB 5 or SIB 5bis. The ASC determines certain parameters for an RACH procedure and controls the priority of the access to the RACH. A lower ASC has a higher priority to access to the channel.

16 Domain Specific Access Restriction (DSAR) enables operator to restrict the traffic load of a specific Core Network (CN) domain. And moreover, different access restrictions can be applied to different CN domains. Most possibly, core network may become congested in case of football games, large meeting presentations and etc. When a CN domain is overloaded, RAN informs UEs belonging to some access classes (AC) that they are not allowed to access to such a CN domain. The restriction information is broadcasted in the system information message on AC basis sequentially. A certain proportion of AC, R%, is limited at a fixed interval. Within the next interval, RAN limits the other R% of UEs and releases all the other UEs. The proportion of limited AC is configurable per domain for a cell. And the restriction interval is also configurable per cell. It is possible to have different access class restrictions on different CN domain. 错误! 未找到引用源 below gives an example as 2% of AC is prohibited from accessing CS domain and 3% of AC are prohibited from accessing CS domain. The restriction interval is 1 minute. Figure 2-1 An example of DSAR activated for both CS domain and PS domain Timer (minute) AC0 x o o x o AC1 x o o x o AC2 o x o x o AC3 x o o x o AC4 o x o x o AC5 o x o x o AC6 o x o x o AC7 o x o x o AC8 AC9 o o x x o o x x o o x CS Domain O PS Domain When the specific CN domain recovers from overload, RAN would stop DSAR for the domain. The operator can decide whether to trigger the DSAR function when a CN domain is overloaded.

17 Manually enabling DSAR for a domain is also supported in ZTE RAN. It is possible to control and restrict CS traffic and PS traffic separately with more flexibility. For example, More PS traffic may be restricted in order to leave CS capacity for users. Logs and alarms about DSAR are provided for operator to monitor the network status. Function of PPAC, Paging Permission with Access Control, also could be implemented to set indicator in cell broadcast system information to allow UE responding paging message, which is useful to avoid failure of communication between UE or emergency service call back where access control is performed. U ZWF Kbps High Speed Signaling RB This feature helps to reduce the time delay for CS/PS service setting up, and shorten SMS services reception. It improves user experience. This feature enables the system to use the 27.2 kbps Signaling Radio Bearer (SRB) when it establishes the RRC connection, and recovers the 3.4Kbps SRB after RAB is established. If 27.2k SRB is set to apply on OMC, ZTE RAN will employ 27.2kbps SRB to speed up transferring the NAS signaling messages (including location update message, authentication message, and call setup message) between the UE and the CN. Compared with 13.6kbps SRB, the 27.2 kbps SRB can reduce the call setup time delay by several hundreds of ms and shorten the SMS service reception in different scenarios. U9.2

18 2.1.4 ZWF Deferred SIB11/12 When numbers of neighboring cells have been configured, reading and storing these neighboring cells information after cell reselection or channel type switching procedure will take a longer time. And this may result in service outrage. Deferred SIB11/12 feature can decrease servcie outrage and enhance user experience. Due to SIB11, SIB11bis or SIB12 should be read and stored by the UE before sending message or acting on received message on FACH after the process of cell reselection or channel type switching, in case that a lot of neighbouring cells are configured (over 20 neighboring cells for example), this will cause the obvious interruption of services. To solve this problem, in 3GPP R7 specification, UE is allowed to send messages through RACH or receive messages through FACH before reading and storing SIB11/12 information. UTRAN broadcasts through SIB3 to notice if the network supports this feature. If the feature is applied, UE s switching to CELL-DCH status must notify the UTRAN that SIB11/11bis/12 are not read and stored. After switching to a non CELL-DCH status, UE needs to complete SIB11/11bis/12 reading and storing. This feature complies with TS CR2557R2. U9.3

19 2.1.5 ZWF Ciphering Algorithm UEA2 Besides UEA1, an alternative encryption algorithm is offerd to make the network safer. Subscriber class differentiated Ciphering service can be realized. This feature realizes UEA2, which is known as f8 and is specified in 3GPP R7. The algorithm f8 is used to protect the confidentiality of the data and signaling sent between the UE and the RNC. The followings are the differences between UEA2 and UEA1: UEA1 is KASUMI based algorithm and UEA2 is SNOW 3G based algorithm. KASUMI is a Blockcipher with 64-bit block, 128-bit key. SNOW 3G is a 32-bit word-oriented stream cipher generator with 128-bit key and 128-bit IV. When a UE makes a connection with the UTRAN, the UE indicates the confidentiality and integrity algorithms supported by the UE in MS/USIM Classmark. RNC compares the information with the confidentiality and integrity capability when a user subscribes for the service, then a proper algorithm is selected. Thus more and more flexible encryption algorithms are provided. This feature complies with the security mechanism and SNOW 3G algorithms specified in 3GPP TS TS ~218 TS U ZWF Integrity Protection Algorithm UIA2

20 Besides UIA1, an alternative integrity protection algorithm is offerd to make the network safer, and integrity protection can be carried out based on user level. This feature realizes UIA2, which is known as f9 and is specified in 3GPP R7. The algorithm f9 is used to protect the integrity of the signaling sent between the UE and the RNC. The followings are the diffirences between UIA2 and UIA1: UIA1 is KASUMI based algorithm and UIA2 is SNOW 3G based algorithm. KASUMI is a Blockcipher with 64-bit block, 128-bit key. SNOW 3G is a 32-bit word-oriented stream cipher generator with 128-bit key and 128-bit IV. When a UE makes a connection with the UTRAN, the UE indicates the confidentiality and integraty algorithms supported by the UE in MS/USIM Classmark. RNC compares the information with the integrity capability when a user subscribes for the service and the RNC capability, then a proper algorithm is selected. Thus more and more flexible integrity algorithms are provided. This feature complies with the security mechanism and SNOW 3G algorithms specified in 3GPP TS TS ~218 TS U Mobility Management ZWF Transmitted Power Based Handover

21 This feature is used to guarantee user s communication quality, avoid the interference to other users, and optimize the system capacity. This feature contains two handover types: HO based on uplink transmitting power and HO based on downlink transmitting power. In the real network, there may exist such a scenario: the quality of pilot signal hasn t reached the threshold which can trigger the coverage based handover, but UE s uplink transmitting power or de B s downlink transmitting power has already reached a high degree as a result of the interference or the different coverage scope between the service channel and the pilot signal channel. In that case, increasing transmitting power can t guarantee UE s QoS. To avoid the interference to other users, it is necessary to hand over UE to other cell. ZTE RNC equipment detects uplink transmitting power reported from UE or downlink transmitting power reported from de B. Once the transmitting power is higher than a certain threshold (configured as close to the maximum transmitting power allowed in usual), RNC can automatically initiate inter-frequency or inter-system measurement to let UE hand over to an inter-frequency or inter-system cell which has better quality ZWF Quality Based Handover This feature guarantees user s communication quality, and reduces the call drop rate.

22 In the real network, there may exist such a scenario: the quality of pilot signal hasn t reached the threshold which can trigger the coverage based handover, but the UE s uplink quality is bad, error packet ratio is high and the target SIR value has reached the maximum, as a result of the interference or the different coverage scope between the service channel and the pilot signal channel. In that case, power control can t guarantee UE s QoS anymore. To avoid call drop, it is necessary to hand over UE to other inter-frequency cell. ZTE RNC equipment detects certain user s uplink connection. Once the quality of the connection can t keep the QoS and inner-loop power control has modified the target SIR to the maximal SIR value allowed, RNC will automatically initiate inter-frequency or inter-system measure to let UE hand over to an inter-frequency or inter-system cell which has better quality ZWF Enhanced Iur-g This feature supports the enhanced Iur-g interface between GERAN BSC and 3G RNC. By employing this interface, inter-rat handover procedure is able to be optimized, so the time delay of the handover is shortened, the success rate of the handover is increased, and user experience is improved. Meanwhile, the delay of handover from 3G to 2G can be reduced. The handover between controllers includes two phases: handover preparation and handover execution. Typically, inter-rat handover preparation needs 600ms, which increases the delay of handover and the possibility of resource block, namely the handover failure and call drop rate are increased.

23 ZTE develops a unique enhanced Iur-g interface to connect RNC and BSC, with proprietary messages and the handover procedure to reduce the delay and failure rate of inter-rat handover. Through the enhanced Iur-g interface and its procedure, RNC and BSC can exchange the cell load information to increase the handover success rate. The enhanced Iur-g procedure parallels the two phases of inter-rat handover by sending Radio Resource Prepare message to BSC before handover is performed, as shown in Figure 2-2. So the BSC can prepare the radio resource in advance. Compared with the typical inter-rat procedure, ZTE enhanced Iur-g can reduce the delay by about 200ms to 300ms. Figure 2-2 Enhanced Iur-g Handover Procedure Target 2G cell information included in Radio Resource Ready message, like NACC Related Data, cell capacity and Load/RT Load/NRT, is also used in load balancing strategy of RRM algorithm. U9.2

24 2.2.4 ZWF Hierarchical Cell Structures This feature supports building hierarchical cell coverage in areas with high subscriber density to realize higher system capacity, more efficient mobility management and more efficient radio resource management (RRM) strategy. The hierarchical cell structure (HCS) describes a wireless system in which cells of at least two layers (such as macro cells and micro cells) are overlaid. Macro cells provide continuous coverage, whereas micro cells absorb traffic. In general, different cells use different frequencies. Low-mobility and high-rate UEs should camp on micro cells, while high-mobility and low-rate UEs should camp on macro cells as much as possible so as to reduce handover and improve the spectral efficiency and system capacity. The essential aim of HCS is to improve network capacity and QoS. The feature supports informing the UE whether the cell adopts HCS networking, which priority level is chosen in HCS cell (the range is from 0 to 7, 0 is the lowest, and 7 is the highest), and the reselection parameters in other cells in cell system information broadcast so that the UE can camp on micro cell to absorb more traffic according to cell reselection algorithm which is defined in 3GPP TS This feature also supports the detecting of user s moving speed by RNC through monitoring the number of times that UE changes its best cell in a certain period. If the number is larger than a threshold, it is reasonable to consider the UE is at a high speed. At this moment, once the UE is connected with a micro cell which uses HCS architecture, RNC will automatically hand over it to an HCS Marco cell to reduce the handovers. On the other hand, if the number of times is smaller than a threshold, it is reasonable to consider the UE is static. At this moment, once UE is connected with a macro cell which uses HCS architecture, RNC will initiate inter-frequency measurement. In the case that micro cell can supply a better coverage, RNC will hand over the UE to an HCS micro cell to absorb traffic and thus the capacity of the network is enhanced.

25 2.2.5 ZWF IMSI Based Handover This feature supports handover mechanisms based on user s IMSI number. IMSI-based handover can limit the handover target cell range according to UE s IMSI. The scope of authorized cells based on the IMSI information on the network side can be configured. The IMSI information is resolved through the Common ID on lu interface during service setup or handover, and UE is not allowed to access or handover to unauthorized cells. ZTE RAN equipment supports that when a UE tries to access an unauthorized cell, if there is an authorized adjacent cell with different frequency or GSM cell that has the same coverage with the cell the UE want to access, inter-frequency hard handover flow or inter-system handover flow will be triggered to connect the UE to an authorized cell ZWF Inter-RAT PS Handover

26 This feature shortens the PS service interruption when there is a handover between inter-rat adjacent cells. With this feature, PS service continuity is enhanced, especially for real-time packet service with higher QoS requirements. User experience gets improved. Cell reselection procedure is usually executed when UE is moving between GERAN and UTRAN. But this makes the PS service interruption last for a long time, which will definitely affect user experience. Inter-RAT PS handover is applicable for a UE in Cell_DCH state. The procedure of Inter-RAT PS handover is just like the CS service inter-rat handover. The message flow of inter-rat PS handover is shown as below, with message within CN omitted: Figure 2-3 Handover from UMTS to GERAN UE de B RNC PS CN BSC RRC RANAP RANAP Handover from UTRAN Command RRC (PS handover) RANAP RANAP Relocation Required Relocation Command First correctly received RLC/MAC block Iu Release Complete RANAP BSSMAP BSSMAP RANAP (XID Resp., RAU req. or Cell Update) Iu Release BSSMAP Command RANAP RANAP PS Handover Request PS Handover Request ACK PS Handover Complete BSSMAP BSSMAP BSSMAP

27 Figure 2-4 Handover from GERAN to UMTS UE de B RNC PS CN BSC RR RRC Handover to UTRAN Complete PS Handover Required Relocation BSSMAP BSSMAP RANAP Request Relocation RANAP RANAP Request ACK RANAP PS Handover BSSMAP Required Ack BSSMAP RANAP RRC RANAP PS Handover Command Relocation Detect Relocation Complete RANAP RR RANAP BSSMAP Clear Command BSSMAP BSSMAP Clear Complete BSSMAP Compared with the cell reselection, inter-rat PS handover decreases both interruption of data transmission and packet loss rate. And it provides better user experience of real-time PS service with higher QoS requirements in inter-rat moving. Inter-RAT PS handover is not applicable unless UTRAN, GERAN, CN and UE all support it. Otherwise, either NACC or normal cell change order will be used for PS service to access an inter-rat adjacent cell. U ZWF DTM Handover This feature guarantees the CS service continuity combined with PS service during Inter-RAT moving. It improves user experience.

28 When a user is establishing CS service and PS service simultaneously and moving between inter-rat adjacent cells, CS service and PS service are handed over to inter-rat cell in parallel via DTM (Dual Transfer Mode) mechanism. The message flow of DTM handover is shown as below, without the message within CN: Figure 2-5 Handover from UMTS to GSM UE RNC CS CN PS CN BSC RANAP Relocation Required RANAP RANAP Relocation Required BSSMAP Handover Request RANAP BSSMAP PS Handover Request BSSMAP BSSMAP BSSMAP Handover Request Ack BSSMAP BSSMAP PS Handover Request Ack BSSMAP RANAP Relocation Command (L3 information: DTM handover Command) RANAP RRC Handover from UTRAN Command ( DTM handover Command) RRC Relocation Command RANAP RANAP (Target BSS to Source BSS Transpatent container: DTM handover Command) BSSMAP Handover Detect BSSMAP BSSMAP Handover Detect BSSMAP RR 7. Handover Complete RR BSSMAP Handover Complete BSSMAP RANAP RANAP RANAP RANAP Iu Release Command Iu Release Complete Iu Release Command Iu Release Complete RANAP RANAP BSSMAP RANAP RANAP PS Handover Complete BSSMAP

29 Figure 2-6 Handover from GSM to UMTS UE RNC CS CN PS CN BSC Relocation Request RANAP BSSMAP RANAP BSSMAP Handover Required PS Handover Required BSSMAP BSSMAP RANAP RANAP RANAP Relocation Request Ack. Relocation Request Ack. RANAP Relocation Request RANAP RANAP BSSMAP Handover Command BSSMAP BSSMAP PS Handover Required Ack BSSMAP RR RRC Handover to UTRAN Complete RANAP RANAP RRC Relocation Detect Relocation Detect RANAP DTM Handover Command RANAP RR Relocation Complete RANAP RANAP Relocation Complete RANAP RANAP Without DTM handover, for CS service and PS service in parallel, PS service does not access inter-rat cell until CS service completes handover to inter-rat cell. Obviously, DTM handover improves inter-rat handover performance of PS service when CS service and PS service are in parallel. It also improves user experience. DTM handover is applicable when both UMTS system and GSM system support DTM handover, and UE supports PS service inter-rat handover. U ZWF NACC

30 This feature shortens the procedure of inter-rat cell re-selection. It improves the performance of the package service during inter-rat moving. As a result, user experience is enhanced. When a UE establishes a PS service handover to GREAN via cell reselection procedure, the interruption of PS service is among 4 seconds to 8 seconds, which brings about bad user experience. Network Assisted Cell Change (NACC) reduces the duration of UE inter-rat cell re-selection procedure. RNC adds the SI/PSI (System Information /Packet System Information) of the target GERAN cell in CELL CHANGE ORDER FROM UTRAN message, and transfers the message to UE. With this information, UE doesn t search the target cell s system information. Consequently, the procedure of the inter-rat cell re-selection is shortened. This kind of inter-rat cell re-selection is NACC. When an Iur-g connection works normally between an RNC and a BSC, SI/PSI of the target GERAN cell is transferred to the RNC via Iur-g. Otherwise, the RNC initials DIRECT INFORMATION TRANSFER message to a CN to request SI/PSI of the target GERAN cell via the Iu connection, and the CN responses SI/PSI in DIRECT INFORMATION TRANSFER message. NACC is used if an RNC gets SI/PSI of the target GERAN cell and UE supports NACC. Otherwise, inter-rat cell reselection without network assistance is used. U ZWF Target cell Load based inter-rat HO

31 This feature increases the success rate of inter-rat handover and decreases the call drop rate in inter-rat handover between UMTS system and GSM system, which improves user satisfaction. Without this feature, the load of target cell is not considered in the inter-rat handover. When the load of a target cell is high, inter-rat handover is easy to fail or the quality of service in the target system cannot get guaranteed. The Target cell Load based inter-rat HO enables the RNC, via an Iu connection or an Iur-g connection, to get load information of GSM adjacent cell, or transfer load information of UMTS adjacent cell to GSM system. The RNC selects a GSM adjacent cell with lower load as target cell to perform handover to the GSM system. When an Iur-g connection works normally between an RNC and a BSC, the Iur-g is preferred to be used to exchange load information. Otherwise, the load information is exchanged in relocation procedure via the Iu connection. RNC will periodically update the load of adjacent GSM cells, to guarantee the availability and correctness of adjacent cell s load information. This feature is applicable when the UTRAN, Core Network, GSM network and UE all support it. U9.2 ne ZWF Handover with LTE This feature guarantees PS service continuous when user moving between UMTS coverage and LTE coverage.

32 When a PS service user leaves LTE network to UMTS network, PS service handover from LTE to UMTS is needed to keep service connectivity continuity. The handover is initialized via relocation required from E-UTRAN to core network. When UTRAN receives relocation request, it allocates resource for the UE and waits for UE accessing. For a LTE-capable UE is ongoing PS service in UMTS and enters the coverage of LTE, it is recommended to handover to LTE for high bit rate service experience in LTE. UTRAN initials relocation required message to core network to start handover. When UTRAN receives relocation command message, it informs the UE handover to E-UTRAN neighbor. Signal flow for PS service handover form UTRAN to E-UTRAN is shown in the figures below. Figure 2-7 UTRAN to E-UTRAN Inter RAT HO UE Source RNC Target edeb Source SGSN Target MME Handover Initiation Relocation Required Handover request Forward Relocation Request Handover Request Acknowledge Handover from UTRAN Command E-UTRAN access procedure Relocation Command Forward Relocation Response Handover to E-UTRAN Complete Handover tify Forward Relocation Complete tification Forward Relocation Complete Acknowledge Iu Release Command Iu Release Complete Signal flow for PS service handover form E-UTRAN to UTRAN is shown in the figures below.

33 Figure 2-8 E-UTRAN to UTRAN Inter RAT HO UE Source edeb Target RNC Source MME Target SGSN Handover Initiation Handover Required Relocation Request Forward Relocation Request Relocation Request Acknowledge Handover from E-UTRAN Command UTRAN access procedure Handover Command Forward Relocation Response Handover to UTRAN Complete Release Resource Relocation Complete Forward Relocation Complete tification Forward Relocation Complete Acknowledge This feature includes dual direction handover between UMTS and LTE, and it is applied in only PS service scenario. UR ZWF SR-VCC This feature maintains IMS VoIP call when the LTE coverage gets worse, and allows making use of CS domain in UMTS network for bearing voice call.

34 SR-VCC provides the ability to transition a voice call from the VoIP/IMS packet domain to the legacy circuit domain. Voice call is allowed to be provided to user only when IMS network elements are deployed in LTE network. Then a user is ongoing voice call and the E-UTRAN coverage gets worse, via SR-VCC, the user is transited to UMTS network and the voice call is carried by circuit domain in core network, In case of a user establishing voice call and packet data service both in LTE network, SR-VCC mechanism can also be used to transit user form LTE network to UMTS network. When the user completes accessing in UMTS network, the voice call is serviced by circuit domain core network, and the packet data service is serviced by packet domain core network. The signaling flow for SR-VCC during voice call and data service in combination is shown in figure below.

35 Figure 2-9 SR-VCC UE Source E-UTRAN Source MME MSC Server/ MGW Target MSC Target SGSN Target RNS/BSS SGW IMS (SCC AS) 1. Measurement reports 2. Decision for HO 3. Handover Required 4. Bearer Splitting 5a. PS to CS Req 5b. Prep HO Req 6a. Forward Reloc Req 7b. Forward Reloc Resp 8b. Prep HO Resp 5c. Reloc /HO Req 6b. Reloc /HO Req 7a. Reloc /HO Req Ack 8a. Reloc /HO Req Ack 8c. Establish circuit 9. Initiation of Session Transfer (STN-SR or E-STN-SR) 14. HO from EUTRAN command 15. UE tunes to UTRAN/GERAN 16. HO Detection 12. PS to CS Resp 13. Handover Command 10. Session transfer and update remote leg 11. Release of IMS access leg 17a. Reloc/HO Complete 17b. SES (HO Complete) 17c. ANSWER 17d. PS to CS Complete/Ack 17f. TMSI Reallocation 17e. UpdateLoc HSS/ HLR 18b. Forward Reloc Complete/Ack 18a. Reloc/HO Complete 18c. Update bearer UR Radio Resource Management ZWF AMR Rate Controlling

36 This feature supports the dynamic AMR adaptation according to the uplink transmission power of the UE or the downlink transmission power of the base station. And in case of an admission failure or a handover failure, the AMR rate is also adjusted to guarantee that maximal services can access the system. It is useful for increasing the number of voice users in the system and enhancing the coverage of a voice service in the case of the radio link quality degrading. In the UMTS system, the radio environment between UE and a base station always changes. When a UE is far away from the base station or the radio environment degrades, the base station or the UE will transmit at a higher power under the action of the closed-loop power control in order to guarantee the QoS of the AMR service. The power change and the power increase at this time may result in a sharp increase of the power and further deterioration of the radio environment. Even when the power is increased to the maximum value, QoS requirements of service cannot be satisfied. As a result, the system capacity will decrease. ZTE RAN monitors the uplink transmission power of the UE reported by internal measurement or the downlink transmission power of a de B reported by dedicated measurement. When the uplink or downlink transmission power rises to a certain threshold, the RNC will automatically adjust this user's AMR to reduce the power necessary for service. That is, a conversation is most probably kept at the cost of reducing voice quality. When the radio environment between the UE and the base station is good and the transmission power of the base station or the UE decreases to a certain threshold, AMR can be increased to provide users with better voice quality as long as other users' feeling and system performance are not affected. When a cell has high downlink load and uplink load, which is evaluated by means of the downlink transmission power and the uplink interference respectively, ZTE RAN can lighten the cell load by reducing the AMR of some low-priority users. In this way, more users can be accommodated. Considering the call quality of the AMR service, ZTE RAN always allocates the highest bit rate supported by the AMR call and the system resource correspondingly. When the system is congested, an AMR call, which requests a new establishment or handover to

37 access the current cell, is refused to access the system. At the moment, ZTE RAN decreases the allocated bit rate of the AMR call to reduce the required resource. It makes it easier for the AMR call to access the system. At the same time, congestion control (pls refer to feature ZWF Congestion Control) is triggered to recover the system from congestion. Consequently, the success rate of AMR call establishment is increased and the user satisfaction is improved. If the load of a cell is a little bit higher, the bit rate of voice call (including NB-AMR and WB-AMR) is allowed to be restricted. It means a low bit rate is assigned to voice call. Some area such as stadium is crowed sometimes. So when RAN detects the load of cells belonging to these area getting higher than the pre-defined threshold, RAN restricts the AMR voice call to a level to ensure more users accessible. The actual AMR coding rates which can be adjusted by the RNC must belong to the AMR code set configured for users by the CN during the call establishment. The voice quality with low-rate AMR coding is not as good as that with high-rate AMR coding, but low-rate AMR coding has higher capacity (number of users) and wider coverage than high-rate AMR coding. Analysis of simulation result shows that there is about 30% coverage radius gain when the lowest AMR (4.75Kbps) instead of the highest AMR (12.2Kbps) is used. When the lowest AMR is used, a cell will accommodate twice as many users as those when the highest AMR is used. This feature supports AMR rate adjusting in case of admission failure or handover failure in release U9.2. In release U9.3, the restriction to voice call bit rate based on cell load is introduced ZWF User Differentiated Power Control

38 This feature allows the operator to configure a power control policy according to the priority of the user so that the QoS of high-priority users in areas with poor network quality can be guaranteed. Sometimes, the transmitting power of a terminal is so strong as to interfere with other terminals, or the transmitting power of the base station targeting at a user occupies too many downlink power resources. To avoid such event, the RNC needs to configure the maximum uplink/downlink transmitting power allowed for each user. The ZTE RAN supports configuring the maximum uplink/downlink transmitting power for various services based on the priorities of these services so that users of high priority can obtain more system resources and the QoS of users with high priority can be guaranteed even though the network quality is poor, thus realizing differentiated QoS policy. 2.4 QoS Guarantee ZWF Video Call Prohibited in Specific Area This feature enables the system to suspend the video call service for a specific cell. The UMTS network provides the video call service. In some areas with security control or areas with privacy protected, the video call service is prohibited and it is necessary to suspend the service in the network layer.

39 This feature provides service suspension parameters for each cell through the NMS. Through the feature, the system can suspend specified services for specified cells. After a service is suspended in an area, if the user initiates the service, the RNC indicates RAB setup failure for the CN during the service setup process. If a connection has been set up for a service, it is prohibited to hand over the service to the area where the service is prohibited. If the CN and the UE support the feature, when the video call service is set up or is handed over to the area where the service is closed, the RNC may roll back the video call service into a common voice service. In this case, it is necessary to configure the function ZWF video call fallback to voice call ZWF RAB Negotiation & Re-negotiation This feature enables the system to select the QoS service for the user according to the load of the RAN, which heightens the success rate of service access and lowers call drop rate. The RAB QoS negotiation and re-negotiation require the cooperation between RNC and CN. When the CN configures the RAB QoS, CN assigns the MBR (maximum bit rate) and GBR in the RANAP message to RNC. And a new IE (Alternative RAB Parameter Values) is adopted in the RAB assignment and relocation request message. CN will assign another set of QoS parameter in this IE. In general, the QoS parameter in this IE is smaller than in the normal RAB parameter. RNC will choose the QoS in these two sets based on the current system load. If the system load is heavy, RNC will choose the QoS set assigned in Alternative RAB Parameter Values IE to reduce the resource consumption. When the resources of the system are scarce, the RNC selects the QoS of

40 a lower level rather than simply rejects the service. It can improve the success rate of access and improve the customer satisfaction. If the RNC sets up a bearer using the parameters in the Alternative RAB Parameter Values rather than the MBR and GBR in RAB parameters assigned by the CN, the RNC notifies the CN of the actual MBR and GBR after the completion of the bearer setup so that the CN knows the actual capability of the bearer and bills the user on basis of the bearer capacity. The RAB QoS renegotiation is based on the system resource utilization. If the load of the system is very low, the system can provide better services for the user through negotiation; if the load of the system is very high, the system can adopt lower bit rate through negotiation. In this way, the system can effectively utilize the resources and serve more users. The RAB QoS negotiation can be triggered in two modes: The renegotiation is triggered by the network When the PDP context is activated, if the network loads change or the service changes, the CN triggers a QoS modification process to modify the E2E QoS parameters and then the RAB reassignment process modifies the RAN radio bearer. The renegotiation is triggered by the RNC The RNC may initiate RAB modification request to the CN according to the load of a cell. When the load of the access network is very high, the RNC provides services at lower bit rates through negotiation; when the load of the access network is very low, the RNC provides services at high bit rates through negotiation. By defining parameters in Alternative RAB Parameter Values in the RAB assignment message, the CN specifies whether the RNC can execute negotiation and operate at negotiable bit rates.

41 2.4.3 ZWF Service-Based Handover This feature supports handover strategies from UMTS to GSM according to CN configuration so that operators can control service distribution between two networks according to load situation or user priority. This feature decides whether to hand over and when to hand over service to GSM according to the attribute service handover in RAB assignment message: Handover to GSM should be performed: it means that it is necessary to hand over to GSM as soon as possible after the service is set up successfully. Handover to GSM should not be performed: it means that the service will have to hand over to GSM in the case that UMTS cannot carry the service, and RNC will trigger inter-rat handover in the case UMTS quality degrading. Handover to GSM shall not be performed: it means that this kind of service can neither be handed over to GSM nor trigger a handover to GSM. Regarding concurrent services, RAN network can combine service handover of multiple services based on the priorities of service handover configured via OMC. For example, one operator wants to have CS service in GSM network and PS services kept in WCDMA network as long as possible. The configuration of service handover for CS service can be Handover to GSM should be performed, and the configuration of service handover for PS service can be Handover to GSM should not be performed. Also Handover to GSM should not be performed should have a higher priority than Handover to GSM should be performed. Based on this configuration, while one UE has concurrent services of CS voice and PS data, WCDMA network is still selected to provide both CS and PS services for the user in order to guarantee PS servie experience. CS service can not be handed over to GSM network until PS service is released.