Zte utran ur11.1 optional feature description

UTRAN UR11.1 Optional
Feature Description
PDF 文件使用 "pdfFactory Pro" 试用版本创建 www.fineprint.cn

UTRAN UR11.1 Optional Feature Description
Version Date Author Reviewer Notes
V1.70 2012/04/05 ZTE Not 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.

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 ................14
Figure 2-2 Enhanced Iur-g Handover Procedure ...............................................................21
Figure 2-3 Handover from UMTS to GERAN .....................................................................24
Figure 2-4 Handover from GERAN to UMTS .....................................................................25
Figure 2-5 Handover from UMTS to GSM..........................................................................26
Figure 2-6 Handover from GSM to UMTS..........................................................................27
Figure 2-7 UTRAN to E-UTRAN Inter RAT HO..................................................................30
Figure 2-8 E-UTRAN to UTRAN Inter RAT HO..................................................................31
Figure 2-9 SR-VCC............................................................................................................33
Figure 2-10 Video Call Fall-Back to Voice..........................................................................41
Figure 2-11 Schematic Diagram of the Iu Flex Networking ................................................49
Figure 2-12 Networking under MOCN Network Sharing.....................................................52
Figure 2-13 Networking under GWCN Network Sharing ....................................................52
Figure 2-14 Dedicated Frequency Sharing Network ..........................................................54
Figure 2-15 Four operators shared Iub interface................................................................58
Figure 2-16 PA Efficiency with D-PT Technology...............................................................68
Figure 2-17 Mechanism of Four-Antenna Receiving Diversity............................................72
Figure 2-18 Logical Connection of Transmit Diversity........................................................74
Figure 2-19 Electrical Tilt Antenna System ........................................................................75
Figure 2-20 A-RAKE receiver structure..............................................................................80
Figure 3-1 ATM Protocol Stack of IuCS Interface ..............................................................86
Figure 3-2 ATM Protocol Stack of IuPS Interface...............................................................87
Figure 3-3 ATM Protocol Stack of Iur Interface ..................................................................88
Figure 3-4 ATM Protocol Stack of Iub Interface .................................................................89
Figure 3-5 AAL2 QoS Differentiation..................................................................................93
Figure 3-6 VLAN Tag.......................................................................................................103
Figure 3-7 PPP/MLPPP Protocol Stack ...........................................................................115

Figure 3-8 Application of IEEE 1588 Clock Synchronization ............................................125
Figure 3-9 IP Protocol Stack on Iub Interface...................................................................126
Figure 3-10 Iub Interface Transmission through the Satellite ...........................................128
Figure 3-11 IP Protocol Stack on IuCS Interface..............................................................129
Figure 3-12 IP Protocol Stack on IuPS Interface..............................................................131
Figure 3-13 DS0 Cross Connection .................................................................................132
Figure 3-14 IP Protocol Stack on Iur Interface .................................................................138
Figure 3-15 LACP............................................................................................................141
Figure 4-1 16 QAM Constellation Graph..........................................................................157
Figure 7-1 Basic Principle of 2×2 MIMO Technical Solution.............................................240
Figure 7-2 VAM Option with MIMO ..................................................................................242
Figure 7-3 F-DPCH Multiplexed.......................................................................................245
Figure 7-4 Enhanced UE DRX.........................................................................................252
TABLES
Table 2-1 Types of Transmit Diversity and Physical Channel Supported by ZTE...............73
Table 3-1 Types of AAL Services.......................................................................................83
Table 3-2 Features of Various ATM Services.....................................................................85
Table 4-1 HSDPA UE Category Supported by ZTE current version.................................146
Table 6-1 HSUPA UE Category Supported by ZTE .........................................................207

1 Services and Radio Access Bearers
1.1 ZWF21-02-020 WB-AMR Speech Support
Benefits
This feature can provide high quality of voice which makes the voice more natural, and
provide high quality telephone, voice and conference video services.
Description
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 34.108.
Introduced Version
U9.1&Before
Enhanced Function
No

1.2 ZWF21-02-022 PS Signaling RAB for IMS
Benefits
This feature supports signaling transmission of IMS system (using SIP or SDP protocol).
Description
The IMS employs the Session Initiation Protocol (SIP) and the Session Description
Protocol (SDP) to control services. As defined in the 3GPP 25.862, 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 34.108.
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.

Introduced Version
U9.1&Before
Enhanced Function
No
1.3 ZWF21-02-025 Cell Broadcast Service
Benefits
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.
Description
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
Uu Iu
Cell
Broadcast
Center
(CBC)
UTRAN
RNC
Node B
Node BUE
UE
1
Routing
Node
(e.g.
3G-
SGSN)
Iub
Bc

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 22.168) to activate user
to receive alarming CBS message in case of a disaster. To enable ETWS function, CBC
and UE are required.
Introduced Version
U9.2
Enhanced Function
No
1.4 ZWF21-02-A VoIP Package
1.4.1 ZWF21-02-021 PS Conversational RAB for VoIP
Benefits
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.
Description

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 ZWF21-02-022 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
ZWF21-06-020 Robust Header Compression.
The RAB radio parameters of ZTE RAN equipment, used to bear PS session services,
follow the definition in the 3GPP TS 34.108.
Introduced Version
U9.1&Before
Enhanced Function
No

1.4.2 ZWF21-06-020 Robust Header Compression
l Benefits
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.
l Description
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

may be compressed to one byte. This greatly improves the bandwidth efficiency of VoIP
bearer on a radio link.
l Introduced Version
U9.1&Before
l Enhanced Function
No
1.4.3 ZWF23-02-005 PS Conversational RAB for VoIP over HSDPA
Benefits
This feature supports IMS video and voice services over HSDPA.
Description
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 ZWF21-02-021 PS Session
VoIP Service Bearer.
Introduced Version
U9.1&Before
Enhanced Function
No

1.4.4 ZWF25-02-005 PS Conversational RAB for VoIP over HSUPA
Benefits
This feature supports IMS video and voice services over HSUPA.
Description
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 ZWF21-02-021 PS Session
VoIP Service Bearer.
Introduced Version
U9.1&Before
Enhanced Function
No
2 Radio Network Functionality
2.1 Connection Management
2.1.1 ZWF21-01-009 SIB11bis
Benefits

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.
Description
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.
Introduced Version
U9.1&Before
Enhanced Function
No
2.1.2 ZWF21-01-018 Domain Specific Access Restriction (DSAR)
Benefits
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.
Description
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.

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
x ooxoAC9
x ooxoAC8
oxoxoAC7
x ooxoAC6
oxoxoAC5
oxoxoAC4
oxox oAC3
oxoxoAC2
oxox oAC1
oxox oAC0
10987654321
x ooxoAC9
x ooxoAC8
oxoxoAC7
x ooxoAC6
oxoxoAC5
oxoxoAC4
oxox oAC3
oxoxoAC2
oxox oAC1
oxox oAC0
10987654321
Timer (minute)Timer (minute)
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.

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.
Introduced Version
U9.3
l Enhanced Function
No
2.1.3 ZWF21-01-020 27.2Kbps High Speed Signaling RB
Benefits
This feature helps to reduce the time delay for CS/PS service setting up, and shorten
SMS services reception. It improves user experience.
Description
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.
Introduced Version
U9.2

Enhanced Function
No
2.1.4 ZWF21-01-022 Deferred SIB11/12
Benefits
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.
Description
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 25.331 CR2557R2.
Introduced Version
U9.3
Enhanced Function
No

2.1.5 ZWF21-01-025 Ciphering Algorithm UEA2
Benefits
Besides UEA1, an alternative encryption algorithm is offerd to make the network safer.
Subscriber class differentiated Ciphering service can be realized.
Description
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 33.102 TS 35.215~218 TS 35.919.
Introduced Version
U9.3
l Enhanced Function
No
2.1.6 ZWF21-01-026 Integrity Protection Algorithm UIA2
Benefits

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.
Description
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 33.102 TS 35.215~218 TS 35.919.
l Introduced Version
U9.3
l Enhanced Function
No
2.2 Mobility Management
2.2.1 ZWF21-03-012 Transmitted Power Based Handover
Benefits

This feature is used to guarantee user’s communication quality, avoid the interference to
other users, and optimize the system capacity.
Description
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 Node 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 Node 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.
Introduced Version
U9.1&Before
Enhanced Function
No
2.2.2 ZWF21-03-013 Quality Based Handover
Benefits
This feature guarantees user’s communication quality, and reduces the call drop rate.
Description

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.
Introduced Version
U9.1&Before
Enhanced Function
No
2.2.3 ZWF21-03-014 Enhanced Iur-g
Benefits
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.
Description
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.

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.
Introduced Version
U9.2
Enhanced Function

No
2.2.4 ZWF21-03-021 Hierarchical Cell Structures
Benefits
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.
Description
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 25.304.
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.

Introduced Version
U9.1&Before
Enhanced Function
No
2.2.5 ZWF21-03-022 IMSI Based Handover
Benefits
This feature supports handover mechanisms based on user’s IMSI number.
Description
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.
Introduced Version
U9.1&Before
Enhanced Function
No
2.2.6 ZWF21-03-023 Inter-RAT PS Handover
Benefits

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.
Description
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
BSSMAP BSSMAP
PS Handover
Request ACK
RANAP RANAP
Iu Release
Complete
BSSMAP BSSMAP
PS Handover
Request
RANAP RANAP
Relocation
Command
BSSMAP BSSMAP
PS Handover
Complete
RANAP RANAP
Relocation
Required
UE Node B RNC PS CN BSC
RRC
Handover from UTRAN
Command RRC
RANAP RANAP
Iu Release
Command
First correctly received
RLC/MAC block
(XID Resp., RAU req.
or Cell Update)
（PS handover）

Figure 2-4 Handover from GERAN to UMTS
RANAP RANAP
Relocation
Request
BSSMAP BSSMAP
RANAP RANAP
BSSMAP BSSMAP
PS Handover
Required Ack
BSSMAP BSSMAP
BSSMAP BSSMAP
Clear Complete
RANAP RANAP
Relocation
Complete
UE Node B RNC PS CN BSC
RRC
Handover to
UTRAN Complete RRC
RR RR
RANAP RANAP
Relocation
Detect
PS Handover Required
Relocation
Request ACK
PS Handover Command
Clear Command
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.
Introduced Version
U9.2
Enhanced Function
No
2.2.7 ZWF21-03-024 DTM Handover
Benefits
This feature guarantees the CS service continuity combined with PS service during
Inter-RAT moving. It improves user experience.
Description

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
BSSMAP BSSMAP
RANAP RANAP
Iu Release
Complete
BSSMAP
RANAP RANAP
UE RNC CS CN PS CN BSC
RRC RRC
RR RR
RANAP RANAP
Iu Release
Command
RANAP RANAP
Relocation
Required
Relocation
Required
BSSMAP BSSMAP
B SSMAP
PS Handover
Request
BSSMAP BSSMAP
Handover
Request Ack
Handover Request
PS Handover
Request Ack
RANAP RANAP
RANAP RANAP
(L3 information: DTM handover Command)
Command
(Target BSS to Source BSS Transpatent
container:DTM handover Command)
Relocation CommandHandover from UTRAN Command
( DTM handover Command)
BSSMAP BSSMAP
Handover Detect
BSSMAP
Handover Detect
7 . Handover Complete
BSSMAPBSSMAP
Handover Complete
PS Handover
Complete
BSSMAP BSSMAP
RANAP
Iu Release
Complete
RANAP RANAP
Iu Release
Command
RANAP
BSSMAP
Relocation

Figure 2-6 Handover from GSM to UMTS
BSSMAP BSSMAP
PS Handover
Required
RANAP RANAP
Relocation
Request Ack.
BSSMAP BSSMAP
PS Handover
Required Ack
RANAP RANAP
Relocation Complete
RRC
Handover to
UTRAN Complete
RRC
RR
DTM Handover Command
RR
RANAP RANAP
Relocation
Detect
BSSMAP BSSMAP
Handover Required
RANAP RANAP
Relocation Request
RANAP RANAP
Relocation Request
RANAP RANAP
Relocation
Request Ack.
BSSMAP BSSMAP
Handover Command
RANAP RANAP
Relocation
Detect
RANAP RANAP
Relocation Complete
UE RNC CS CN PS CN BSC
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.
Introduced Version
U9.2
Enhanced Function
No
2.2.8 ZWF21-03-025 NACC
Benefits

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.
Description
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.
Introduced Version
U9.2
Enhanced Function
No
2.2.9 ZWF21-03-026 Target cell Load based inter-RAT HO
Benefits

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.
Description
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.
Introduced Version
U9.2
Enhanced Function
None
2.2.10 ZWF21-03-110 Handover with LTE
Benefits
This feature guarantees PS service continuous when user moving between UMTS
coverage and LTE coverage.

Description
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
Target
eNodeB
Forward Relocation
Request
Handover from UTRAN
Command
Relocation Required
Source
RNC
Handover request
Handover Request Acknowledge
Source
SGSN
Target
MME
Handover Initiation
Forward Relocation
Response
Relocation Command
E-UTRAN access procedure
Handover to E-UTRAN Complete
Handover Notify
Forward Relocation
Complete Notification
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.

Figure 2-8 E-UTRAN to UTRAN Inter RAT HO
UE
Target
RNC
Forward Relocation
Request
Handover from E-UTRAN
Command
Handover Required
Source
eNodeB
Relocation Request
Relocation Request Acknowledge
Source
MME
Target
SGSN
Handover Initiation
Forward Relocation
Response
Handover Command
UTRAN access procedure
Handover to UTRAN Complete
Relocation Complete
Forward Relocation
Complete Notification
Forward Relocation
Complete Acknowledge
Release Resource
This feature includes dual direction handover between UMTS and LTE, and it is applied
in only PS service scenario.
Introduced Version
UR11.1
Enhanced Function
No.
2.2.11 ZWF21-03-120 SR-VCC
Benefits
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.

Description
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.

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

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.
Description
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 Node 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

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 ZWF21-04-010 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.
Introduced Version
U9.1&Before
Enhanced Function
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.
2.3.2 ZWF21-04-024 User Differentiated Power Control
Benefits

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.
Description
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.
Introduced Version
U9.1&Before
Enhanced Function
No
2.4 QoS Guarantee
2.4.1 ZWF21-05-016 Video Call Prohibited in Specific Area
Benefits
This feature enables the system to suspend the video call service for a specific cell.
Description
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.

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 ZWF21-05-024 video call fallback to voice call.
Introduced Version
U9.1&Before
Enhanced Function
No
2.4.2 ZWF21-05-020 RAB Negotiation & Re-negotiation
Benefits
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.
Description
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

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.
Introduced Version
U9.1&Before

Enhanced Function
No
2.4.3 ZWF21-05-022 Service-Based Handover
Benefits
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.
Description
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.

In reality, the load of GSM cell is high in some hot spots. If service based handover is
enabled and the load of GSM cell is not considered, it brings more load to GSM cell. To
avoide this, a configurable switch per cell is provided to disenable service based
handover. When the switch is set to be off, the attribute “service handover” is not
checked by RAN.
After introduction of LTE, information element of “E-UTRAN Service Handover” in RAB
assignment message is also introduced to indicate whether a UE could be handed over
to LTE. ZTE RAN can abbey the indication in the information element from CN.
Handover strategies based on services actually need to be configured in CN.
Introduced Version
U9.1&Before
Enhanced Function
The priority for attribute “service handover”, and service based handover
enabling/disenabling per cell are introduced in U9.3.
In UR11.1 ZTE RAN can abbey the indication of “E-UTRAN Service Handover”.
2.4.4 ZWF21-05-024 Video Call Fallback to Speech
Benefits
The GSM system does not support the CS video call defined by the 3GPP. When a user
moves from the UMTS system to the GSM system, this feature can automatically make
the video call fall back to the voice service, and then implement the inter-system
handover, thus reducing the call drop rate of the video call service.
Description
In the initial network construction, the UMTS system usually cannot provide complete
coverage. If the GSM adjacent cells exist at the edge of the UMTS network or areas with
poor UMTS coverage, it is necessary to switch the user from the UMTS to the GSM
system so that the services can be provided continuously.

Figure 2-10 Video Call Fall-Back to Voice
UE Node B
Serving RNS
Serving
RNC
CN
RRCRRC
7. DCCH: Radio Bearer Reconfiguration Complete
NBAPNBAP
4. Radio Link Reconfiguration Ready
NBAPNBAP 5. Radio Link Reconfiguration Commit
RRCRRC
6. DCCH: Radio Bearer Reconfiguration
RANAP RANAP
8. RAB Assignment
Response
RANAP RANAP
2. RAB Assignment
Request
[Modification]
NBAPNBAP
3. Radio Link Reconfiguration Prepare
RANAP RANAP
1. RAB Modification
Request
The video call service, as a special feature in UMTS system, has been applied
extensively. But the GSM system cannot provide the video call service. As a result, the
video call service in the UMTS network cannot be switched to the GSM system. If the
video call service has to be switched to the GSM system, it may be interrupted forcedly.
This feature enables the system to roll back from the video call service to AMR service
and then implement handover from the 3G system to the 2G system, thus ensuring the
continuity of the voice service.
The implementation of the feature requires the cooperation from the CN and UEs that
support the SCUDIF function.
Introduced Version
U9.1&Before
Enhanced Function
No

2.5 User Plane Process
2.5.1 ZWF21-10-001 Cell ID & RTT Positioning
Benefits
This feature supports location service based on cell ID. Cell ID positioning does not
require additional hardware and investment is little. It provides large coverage and rapid
positioning delay, suitable for location service with low requirement on accuracy.
Description
When a location request is received from CN, a proper location method is selected
according to the requirement on accuracy. After UE position is calculated, the result is
reported to CN.
According to the reporting method involved in the location request, the RNC reports
service area (SA) or geographical area (GA) to CN.
− SA mode
RNC reports the SA ID (SAI) of the cell where the UE camps to CN.
− GA mode:
When there is no information about accuracy in the location request, the
coverage information (usually pre-configured in OMC) of the cell where the UE
camps is reported.
When accuracy requirement is indicated to be greater than a specific value
(usually 100 meter), cell ID + RTT method is used, which means UE position is
determined by Time of Arrive (TOA). Round Trip Time (RTT) is the time
difference between the start of a downlink frame and the reception of the
corresponding uplink frame. TOA can be derived by the NodeB RTT
measurement and the UE Rx-Tx time difference measurement. Type 2
measurement on UE Rx-Tx is adopted with priority Type 1 is used if UE does
not support type 1.

Cell ID + RTT positioning has an accuracy of 80-100m. But it requires that Node B should
support RTT measurement. Otherwise, only cell ID positioning is used.
According to the location request from CN, RNC reports position results immediately or
when SA where UE resides changes.
Introduced Version
U9.1&Before
Enhanced Function
No
2.5.2 ZWF21-10-002 AGPS
Benefits
This feature provides high-accuracy position service with large coverage, rapid location
and quick response.
Description
To use the A-GPS location service, the UE and radio access network must support GPS.
Compared with the traditional GPS, A-GPS system sends GPS location reference
information (encapsulated in system broadcast SIB15 or measurement control message)
from the network side to the mobile UE to help it acquire satellite signal and
measurement code phase information quickly. Therefore, A-GPS locates UE quickly with
rapid response, reducing power consumption of the UE.
A-GPS positioning methods are classified into two modes: UE-assisted (UE-A) and
UE-based (UE-B).
In the UE-A A-GPS location method, location calculation is achieved by the Service
Mobile Location Center (SMLC) at the network side. UE reports measurement results of
the satellite signals and code phase information to the RNC at the network side. The
RNC transmits the measurement results to the SMLC through the Iu-PC interface. The
SMLC then calculates the mobile location based on the measurement results and finally
reports the calculation result to the CN through the RNC. In the UE-B A-GPS method,

location calculation is achieved by UE and UE reports the calculation result to network
side. For the A-GPS, the location result is reported with ellipsoid point with altitude and
uncertain Ellipsoid.
ZTE RNC completes location calculation with their built-in Iu-PC interfaces and SMLC
function, helping the operators reduce the cost for purchasing additional SMLC devices.
The accuracy of A-GPS positioning has an advantages of 5 to 50 meter over the cell
ID+RTT methods.
According to the location request from the CN, the RNC can report the measurement
results immediately or when SA where UE resides changes.
Additional GPS antenna and the feeder are needed because they are not included in
RNC and Node B equipment.
Introduced Version
U9.1&Before
Enhanced Function
No
2.5.3 ZWF21-10-003 Emergency Call Re-direct to GSM
Benefits
If location service is not provided in UMTS system, or accuracy of location service in
UMTS system is not high, this feature makes use of location service in 2G network to
give the location information of a user in an emergency call. With the location information,
emergency assistance could be provided in time by some rescue organization.
Description
Emergency call is always requested by a user in certain emergency situations. If the
location of a user in emergency is identified, assistance would be provided without delay.
When location service is not provided in UMTS system or the accuracy of location

service in UMTS system is not high, UMTS system redirects emergency call to 2G
network. Then the location of the user is got via 2G network’s location service.
When the Flag related to Emergency Call Re-direct to GSM is on, if a UE transfers RRC
CONNECTION REQUEST message with a cause of Emergency Call, and the cell where
the message is received has more than one co-located GSM adjacent cell, ZTE RAN
responds RRC CONNECTION REJECT message with the co-located GSM cell
information to the UE. Then the UE performs inter-RAT cell reselecting to the GSM cell
and makes an emergency call again. User does not feel the procedure of re-direction to
GSM, and it seems that the emergency call is launched in GSM network originally.
Introduced Version
U9.2
Enhanced Function
No
2.5.4 ZWF21-10-004 LCS Classified Zones
Benefits
This feature enables operators to acquire the information of specific areas when a UE
enters or leaves these areas so that operators can deliver user-location-based services.
Description
ZTE RAN equipment can specify areas (usually a cell or a set of cells) in OMC. When a
UE enters or leaves these areas, the RNC automatically reports location information of
the UE to the CN by SA method.
With this feature, operators can deliver user-location-based services such as alarm
messages to UEs when they enter these areas.
Introduced Version
U9.1&Before

Enhanced Function
No
2.5.5 ZWF21-10-005 LCS over Iur
Benefits
Increase the precision of location service, including CellID based LCS, CellID+RTT
enhanced LCS, UEB AGPS LCS, LCS Classified Zones
Description
Generally the realization of LCS is limited in the scenario, where the best cell of the
active set of the UE is only in the SRNC, and the measurement of RL of inter Iur can’t be
done. The feature LCS over Iur supports UE’s LCS even when some RLs in DRNC .
If the best RL in the active set is in DRNC, LCS information and NodeB measurement
result are exchanged through Iur between SRNC and DRNC,
− Cell ID LCS, Cell ID+RTT enhanced LCS
When the best cell is in the DRNC, SRNC obtains the location information of the
reference cell through iur information. For the Cell ID+RTT, SRNC needs to start
the RTT measurement on DRNC side through Iur common measurement
procedure.
− UEB AGPS
When the best cell is in the DRNC, the SRNC obtains the accessory GPS
information of the reference cell on the DRNC side through initiating Iur information
exchange procedure
− LCS Classified Zones
Supporting Iur direct neighbor cell reported as LCS Classified Zones
Introduced Version
UR11.1

Enhanced Function
No
2.6 RAN Management
2.6.1 ZWF21-20-017 Intelligent Carrier Power Off/On
Benefits
This feature enables the system to close some carrier frequencies in the multi-carrier
sector when the traffic volume is very low, thus reducing power consumption of
equipments and the operator's OPEX.
Description
The load of the telecom system varies greatly within a day. During peak traffic hours in
the daytime, the system needs multiple carrier frequencies (for example, S333) to carry
services; at night, one carrier frequency (S111) is enough. When the traffic volume is
very low, the system still uses multiple carrier frequencies to carry services. Though the
load of each carrier frequency is not very high, each carrier frequency needs common
channels such as the pilot channel. The power of the common channels covers 20% of
the transmitting power of the overall carrier frequencies.
The intelligent carrier power off/on technology of the ZTE RAN can automatically monitor
the network service status. When the traffic volume is relatively low, the RAN
automatically closes idle carrier frequencies. If the RAN finds that the traffic volume
increases to such a threshold that the current working carrier frequencies cannot handle
the extra services, it starts the closed carrier frequencies.
When the traffic volume is very low and it is necessary to close some carrier frequencies,
the intelligent carrier power off/on technology can gradually reduce the maximum
transmitting power of a cell until the RF units on the redundant carrier frequencies are
switched off. In this way, the small traffic in the closed cell can hand over to the adjacent
cell smoothly.

Introduced Version
U9.1&Before
Enhanced Function
No
2.7 Enhanced RAN Functionality
2.7.1 ZWF21-30-021 Iu Flex
Benefits
This feature supports that one RNC can be connected to multiple MSC Servers/SGSNs
and these MSC Servers/SGSNs are combined into a pool to provide redundancy so as to
improve the network security, helping to achieve load balance between MSC
Servers/SGSNs and reducing waste of hardware resource and signaling overhead.
Description
The Iu Flex is a networking technology in the 3GPP R5 version. This networking mode
eliminates the restriction that one RNC can be connected to only one MSC Server/SGSN
in a traditional network. In the Iu Flex networking, one RNC can be connected to multiple
MSC Servers/SGSNs, and these MSC Servers/SGSNs are grouped to a pool area which
provides services to the RNC. As shown in Figure 2-11, a pool area is set according to
different CN domains. All the connected CS CN nodes constitute a CS pool area, and all
the connected PS CN nodes constitute a PS pool area.

Figure 2-11 Schematic Diagram of the Iu Flex Networking
Compared with traditional networks, the networking based on the Iu Flex technology has
the following advantages:
− Load sharing and disaster recovery
The capacity of an RNC has been increased, even higher than that of an MSC
Sever or SGSN. In traditional networking, the actual capacity of RNC has been
restricted since only one MSC Server/SGSN is allowed to connect to one RNC.
With all MSC Servers/SGSNs forming a pool area, the capacity of all CN
nodes in pool area are combined to connect to more RNCs. Network load is
shared among MSC Servers/SGSNs. And the CN nodes in pool area back up
for each other. If one is down, the traffic of the CN node is transferred to other
CN nodes.
− Reducing signaling load of mobility, increasing the actual capacity of the
network
If there are too many subscribers, equipment capacity will be a limitation and
Area 1
RAN
node
Area 5
RAN
node
Area 6
RAN
node
Area 7
RAN
node
Area 8
RAN
node
Area 2
RAN
node
Area 3
RAN
node
Area 4
RAN
node
PS pool-area 2PS pool-area 1
CS pool-
area 2
CS pool-
area 1
MSC 3
MSC 2
MSC 1
MSC 6
MSC 5
MSC 4
SGSN 6
SGSN 2
SGSN 1
SGSN 5
SGSN 4
SGSN 3
MSC 7

then the coverage of a single MSC Server/SGSN will be small. When UEs
move between the different CN nodes frequently, there are many signalings of
the LA/RA update, handover, relocation and the exchange of the HLR
parameters. With Iu Flex networking, a subscriber within one pool area can
enjoy his/her services provided by a specific MSC Server/SGSN, and need not
change serving CN node when moving within the pool area. So signaling load
caused by mobility is decreased significantly and the system capacity and the
network performance also get improved effectively.
ZTE RAN supports Iu Flex networking, that is multi MSC Servers/SGSNs can be
connected to one RNC. Network Node Selection Function (NNSF) is used to select a
serving CN node among multi CNs when a subscriber accesses the network or the
network pages a subscriber:
− When users initiate attach procedure or LA/RU update procedure, RNC will
select CN node based on NRI configuration and IDNNS information to
establish a signaling connection, which reduces signaling interaction of
mobility between CN nodes.
− If there is no NRI information or CN nodes have problems or the CN load is
high, the RNC will reselect a CN node to establish a signal and traffic
connection so as to achieve load-sharing and redundancy protection.
− When a user has a terminated call, the RNC will buffer the CN node
identification for utilization in future paging procedure to select a correct CN
node.
− Configuration of Preferred Pool Area (PPA) supported, the CN equipment in
PPA pool will be selected with a higher priority to serve UE. This feature can
increase the flexibility of Iu Flex configuration.
ZTE RAN equipment can recognize CN ID (Global CN-ID) in RANAP procedure of SRNS
relocation, the CN reset, the resource reset and the overload in the case of Iu Flex
networking, and it only processes messages from some specific CN nodes.
ZTE RAN equipment supports the combining of MBMS service of multiple SGSNs in the
case of Iu Flex networking.

Introduced Version
U9.1&Before
Enhanced Function
No
2.8 ZWF21-30-A RAN Sharing Package
2.8.1 ZWF21-30-100 Basic RAN Sharing Support
Benefits
This feature allows multiple operators to use the same UTRAN resources to provide their
own services. In this way, the operator can shorten the network construction, save the
investment on site acquisition, site construction, transmission construction, and wireless
network devices, and greatly decrease the cost in network construction and operation.
Description
ZTE RNC can be connected to one or more CN equipments belonging to multiple
operators, allowing multiple operators to share many kinds of UTRAN resources and
equipments including RNC cabinet and boards, OMC devices, Node B cabinets,
baseband processing boards, RF units and feeder cable system, and other RAN
auxiliaries (including power and transmission lines of the Iub/Iur interface).
ZTE RAN supports two UTRAN network sharing modes defined by the 3GPP:
− Multi-Operator Core Network (MOCN)

Figure 2-12 Networking under MOCN Network Sharing
Radio Access Network
Operator X
CN
O perator A
CN
Operator B
CN
O perator C
RNC
Iu
Node B Node B
In this network sharing mode, different operators construct CN devices
separately. All CN devices are connected to the same RNC and share the
RAN resources.
− Gateway Core Network (GWCN)
Figure 2-13 Networking under GWCN Network Sharing
Radio Access Network
Operator X
Shared
MSC/SGSN
Shared
MSC/SGSN
Shared
MSC/SGSN
RNC
Iu
CN
Operator A
CN
Operator B
CN
Operator C
RNC RNC
In this network sharing mode, the operators share the same CN network (such
as MGW, MSC server, and SGSN) as the network gateways and connect to
their respective HLR, GGSN, GMSC, GMGW, and billing & accounting
system.

ZTE UTRAN supports flexible UTRAN sharing deployment. Part of RNS could be set not
shared or shared by different operators from other parts. Iu Flex also can be activated to
MSCs of one or several operators.
Introduced Version
U9.1&Before
Enhanced Function
No
2.8.2 ZWF21-30-101 RAN Sharing with Dedicated Carrier
Benefits
This feature enables operators to use their own frequency when they share the UTRAN
network. It can prevent the capacity competition of radio resources among several
operators.
Description
If different operators have their own frequency resources, the ZTE RAN equipment
enables the operators to share the UTRAN network with their respective frequencies. All
the UTRAN equipment and resources will be shared except the frequency. The
frequencies of different operators can be deployed in one Node B, sharing the cabinet,
power, and baseband processing boards. According to the operator’s requirements,
these operators can share the FR devices (power amplifier, feeders, and antenna), or
deploy them separately. The frequencies of different operators can also be deployed in
different Node Bs and connected to the same RNC through the Iub interface. Different
operators can share the RNC cabinet, power source, and processing boards in the
control plane and user plane.

Figure 2-14 Dedicated Frequency Sharing Network
Frequency one
Frequency two
Shared RNC
Frequency one
Frequency two
Shared Node B
MNC
one
MNC
two
Operator one
Operator two
The frequencies of different operators can be distinguished according to the PLMN code
in the broadcasted system information. Through the broadcasted information of each
carrier, UE can identify the networks of different operators, camping on and accessing to
carriers with its home PLMN or authorized PLMN, and displaying the logo of the operator.
According to the access frequency of the UE, RNC routes signaling connection and
service to the respective CN. RAN sharing with dedicated carrier is transparent to UE
and UE needn’t know whether the cells of various PLMNs use the shared resources.
Therefore, the UEs of all protocol versions can access the shared network and enjoy
respective services provided by the operators.
When ZTE RNC works in dedicated carrier sharing situation, a physical RNC can be
regarded as several virtual logical RNCs, and each logical RNC belongs to an operator.
The shared RNC can connect to not only shared Node Bs or shared RNCs, but
non-shared Node Bs or non-shared RNCs as well. When the shared RNC connects to
different operators’ CN, each operator also can deploy Iu flex for MSC/SGSN pooling
purpose.
When ZTE RNC works in dedicated carrier sharing situation, it distinguishes subscribers
from each operator by the cell they are connected with in shared or non-shared Node Bs
controlled by itself or other shared RNCs or non-shared RNCs. RNC ensures that users
can only access their own operator’s cells and user’s service continuity among those
cells.
RAN sharing with dedicated carrier is applied to both MOCN and GWCN modes.
Introduced Version
U9.1&Before

Enhanced Function
No
2.8.3 ZWF21-30-102 Shared Networks Access Control
Benefits
This feature provides admission control for the UE which is in the DCH status and is in
the shared network or on the boundary of the shared network and unshared network,
according to the subscription relation with the operator. It ensures the user to enjoy the
service of the authorized network during moving.
Description
ZTE RAN supports the access control in Shared Network Area (SNA). Each SNA is
identified by an SNAC. The SNAC is unique in a PLMN. One SNA may contain one or
more location areas (LA), and one LA may belong to several SNAs.
The serving area for user is configured in the CN. From the CN, RNC can get the SNAC
of each LA under the RNC, and the SNA authorized to each user. In the case of Iur
interface handover, SRNC can get the SNA of each DRNC cell through the Iur interface.
The RNC retains the SNAC of each user and configures the adjacent cell list of
intra-frequency measurement, inter-frequency measurement, and inter-system
measurement according to the SNAC. Only the authorized SNAs cell can be included
into the new adjacent cell list (for measurement control) so that the UE can only hand
over within the authorized cells.
Each cell is labeled with some authorized PLMN IDs in ZTE RNC, which means
subscribers belonging to those PLMNs will be able to access in the cell. If there is no
SNA information from CN, ZTE RNC will filter target cells for a user during its handover
based on authorized PLMN IDs of each neighboring cell. Therefore, the user will not
move to cells not belonging to its authorized network.
Introduced Version
U9.1&Before

Enhanced Function
No
2.8.4 ZWF21-30-116 Operator Specific Function Control
Benefits
Operators of the shared RAN can purchase optional features separately and can
configure some key features operation parameter separately.
Description
Most optional features can be switched on/off based on PLMN ID. Also dozens of
operating parameters related to HSPA, MBMS, Handover and etc. can be configured
based on PLMN ID to realize the differentiated service strategy for operators using the
shared equipment. This feature is realized through license control.
ZTE RAN equipment supports many optional features which could be purchased and
activated based on network deployment strategy. Those features could be categorized
into three groups, each with different management methods in network sharing scenario.
− RNC Level functions applied to single subscriber
Most of those functions can be configured in RNC level based on PLMN and
differentiated applied to different subscribers belong to different operators. Still few
RNC level optional functions only support same configuration to all operators and
cannot be purchased separately.
− Cell Level functions applied to all subscribers in each cell
All of those functions are configured in cell level and can be applied to different
subscribers belong to different operators in dedicated carrier network sharing
scenario, which means if different operators have different frequencies then those
functions can be purchased and configured separately.
− Other functions applied to a physical equipment
All of those functions are applied to physical equipment but not to single subscriber,

like transmission function. Since physical equipments are shared when network
shared, those functions are shared as well and cannot be purchased and
configured separately.
Operator specific function control is implemented via license control mechanism of ZTE
RAN. Different operators can purchase different licenses in shared RAN, activating and
operating optional features separately.
Introduced Version
U11.1
Enhanced Function
No
2.8.5 ZWF21-30-117 Operator QoS Priority
Benefits
QoS priority can be configured based on PLMN so that each operator can have individual
QoS strategy.
Description
PLMN based QoS priority configuration is introduced. And the QoS priority will be
implemented in the RRM algorithm including access control, congestion control and
overload control. The QoS priority also will be effective in HSPA packet scheduling and
transmission resource allocation. Therefore, more system resource will be able to be
allocated to subscribers and services of operator with priority. For each operator, QoS
priority of subscribers and services still can be defined separately as descript in the
feature of “ZWF21-05-003 Differentiated Service”.
Introduced Version
U11.1
Enhanced Function

No
2.8.6 ZWF21-30-118 Operator Specific Iub/Iur Transmission
Benefits
Operators of the shared RAN can flexibly deploy transmission network.
Description
The feature supports transmission reservation for different operators to ensure their
usage.
For Iu and Iur interface, transmission network can be deployed separately to different
operators and signaling flow and media data flow can be handled separately. Multiple
signaling points and IP addresses are supported by ZTE RNC, which could be used to
connect with different UMTS nodes, e.g. RNCs, MSCs and SGSNs, in different
transmission networks belong to different operates.
For Iur and Iub interface, transport links between shared RNCs or Node Bs also can be
divided into logical transport paths, which could be occupied by different operators for
separation and reservation of transmission resource. Logical transport paths can be
mapped to both logical and physical transport links.
Figure 2-15 Four operators shared Iub interface
RNC Node B
ANI+Path+PLMN1
ANI+Path1+PLMN2
ANI+Path1+PLMN3
ANI+Path1+PLMN4
ANI+Path+PLMN1
ANI+Path1+PLMN2
PathGroup
ANI+Path1+PLMN3
ANI+Path1+PLMN4
ANI+Path+PLMN_MIX ANI+Path+PLMN_MIX
Transmission resource of logical transport paths among different operators can be
completely reserved to ensure usage of each operator or dynamically shared to improve
transmission efficiency, or combination of partitioning and sharing. For shared

transmission resource, QoS differentiation can be implemented as the feature of
“ZWF21-30-117 Operator QoS Priority”.
Introduced Version
U11.1
Enhanced Function
No
2.8.7 ZWF21-30-119 Operator Specific RNC Resource
Benefits
Capacity can be logically separated in shared RNC equipment and purchased by
operators who share the RAN.
Description
Processing resource can be logically separated in ZTE RNC, which means RNC capacity
of CS traffic volume and PS throughputs can be separated and reserved to different
operators.
Introduced Version
U11.1
Enhanced Function
No
2.8.8 ZWF21-30-120 Operator Specific FM/PM/CM
Benefits
This feature provides the cell-level FM (Fault Management)/PM (Performance
Management)/CM (Configuration Management) for specific operator
Description

This feature enables operator to independently manage the cell-level FM/PM/ CM, that
is:
− Independent CM
In dedicated carrier network sharing scenario, different operators can
independently configure the parameters related to the cell which belongs to
only one operator. For example, different operators own dedicated SW
(software) function and feature differentiation can be embodied in cell-level
configuration. In shared carrier network sharing scenario, part of RNC level
parameters also can be configurable for each operator.
− Independent PM
For those counters related to cells, performance statistics can be done based
on operator. The operator dedicated results of performance statistics can only
be accessed by their own PM Managers, for example, differentiate the
counters related to the network’s KPI from different operators, and
independently manage their own measurement objects. Not all but only some
KPI related counters can be differentiated among operators in shared carrier
network sharing scenario.
− Independent FM
Fault management can differentiate the cell-level alarms for different operators.
The fault alarm corresponds to only one operator so it can only be accessed
and processed by their own FM managers.
Introduced Version
U9.2
Enhanced Function
No
2.8.9 ZWF21-30-121 Operator Specific CE Resource
Benefits

The feature provides baseband CE resources sharing by different operators when they
sharing RAN. And the proportion occupied by each operator is configured by OMC. This
feature can make the Node B hardware utilized sufficiently, reducing the CAPEX and
OPEX of operators.
Description
There are two ways to realize CE resources sharing by multi-operators: one is
multi-operators sharing CE resources in the same baseband pools, the other one is
multi-operators occupy different baseband pool independent in the same BBU. ZTE’s
RAN support both the two ways.
ZTE support at most 6 cells in one baseband pool, and one baseband pool includes 1 to
5 baseband boards, and one baseband board only belongs to one baseband pool. The
CE proportion belongs to each operator can be configured by OMC when cells of
multi-operators configured in the same baseband pool or in different baseband pools.
And then the division of CE resources between operators by proportion can be realized.
In the shared carrier scenario, there must be a master operator, who pays for the whole
CE capacity of the network. Other operators rent the CE capacity from the master
operator. Thus this is a different CE configuration requirement from the dedicated carrier
sharing scenario. Only the total number of CE in Node B is controlled by the license,
partitioning of CE is done in RNC.
This feature doesn’t support the deployment of both dedicated carrier and shared carrier
UTRAN sharing in the same Node B. But for the RNC, it supports that part of Node Bs
are in dedicated carrier UTRAN sharing mode, part of node Bs are in shared carrier
UTRAN sharing mode, and part of Node B are not shared.
Node B level configurable parameters are added to allocate the dedicated CE resource
percentage for each operator dedicated carrier RAN sharing mode and unallocated CE
resource could be shared by all operators. In the shared carrier mode, the whole Node B
carriers constitute a frequency pool and CE resource percentage for each operator is
configured in the RNC. For the reason that the CE resource can only be shared inside
one local cell group in ZTE Node B and cannot be shared across local cell groups, CE
usage percentage configured for one Node B in the RNC will be applied to all local cell
groups in the Node B.

Introduced Version
U9.2
Enhanced Function
No
2.8.10 ZWF21-30-122 Extended GSM Neighboring Cells
Benefits
Configuration of more number of GSM neighboring cells is possible in RAN sharing
scenario for better supporting of inter- RAT mobility.
Description
Operators who share a 3G radio network usually have their own GSM network as well.
So comparing with UMTS neighboring cell, including intra-frequency and inter-frequency,
more number of GSM neighboring cells of different operators could exist. ZTE RNC
supports configuration of up to 96 GSM neighboring cells for better supporting of inter-
RAT mobility from shared UTRAN network to different operators’ GSM network.
Information of maximum 32 inter-RAT neighboring cells can be sent to UE according to
3GPP protocols. ZTE RNC can filter no more than 32 inter-RAT neighboring cells for UE
mobility function based on PLMN and neighbor cell priority. In the UE idle state, only
the neighbor cells with higher priority are selected to send to the UE, due to the lack of
authorization information of the UE. In the UE connected state, SNAC based neighbor
cell selection is applied.
Introduced Version
U11.1
Enhanced Function
No

2.8.11 ZWF21-30-200 Multi PLMN Support
Benefits
This feature supports the configuration of multiple PLMNs to a UTRAN, which is used in
the following scenarios:
− If an operator owns several PLMNs, by using this feature he can deploy
different cells with different PLMNs at the airports, piers, coach terminals and
tourist spots where many inter-operator roaming users enter, hence the
probability of the network to be selected by the roaming users will get higher,
which means to attract more roaming users to reside in the network and to
increase the operators’ revenue.
− If a UTRAN is shared by different operators, different PLMNs can be used to
distinguish from different operators.
Description
ZTE RAN supports the configuration of different PLMNs to different cells. If a UTRAN is
shared by different operators, different PLMNs can be used to distinguish from different
operators.
If an operator owns several PLMNs, it can deploy different cells with different PLMNs at
the airports, piers, coach terminals and tourist spots where many inter-operator roaming
users enter. In the roaming area of a non-HPLMN coverage area, the UE will select a
new PLMN to register when it powers on. The PLMN belongs to a roaming partner
operator. During the process, the UE may automatically select a cell with the best access
radio quality, or the UE may indicate to the user a list of available PLMNs whose cell
radio quality is good enough to access and the user then makes the selection.
Configuration of more PLMNs is beneficial to increase the probability of network to be
selected by roaming users. Meanwhile, the RAN device of ZTE also supports the mobility
management among different PLMNs so that after a user selects a PLMN of the operator,
he may then switch over to a cell with another PLMN of the same operator to continue
the service.
Introduced Version

U9.1&Before
Enhanced Function
No
2.9 RAN Sharing Enhanced Features
2.9.1 ZWF21-30-103 RAN Sharing with Shared Carrier
Benefits
This feature provides the possibility for multi-operator to share the same 5MHz UMTS
carrier to build a shared UTRAN. It is useful when the UMTS frequency license is not
enough or different operators want to pool their frequency license to increase spectrum
efficiency.
Description
ZTE RAN equipment supports the broadcasting of multi-PLMN IDs in one cell. UEs with
3GPP R6 capability will be able to read system information of the shared carrier cell to
choose a right PLMN to register.
In scenario of RAN sharing with shared carrier, ZTE RNC supports bellowing methods to
route a UE signaling and service access to its right CN nodes.
− For UEs with 3GPP R6 RAN sharing capability, ZTE RNC routes them to CN
nodes with the same PLMN ID indicated in RRC connection request message
sent from those UEs.
− For UEs without 3GPP R6 RAN sharing capability, PLMN ID cannot be
indicated by UEs themselves. ZTE RNC choose CN nodes from different
operators based on following criteria:
If UE is identified by TMSI with specific NRI, ZTE RNC will route this UE’s
connection to one CN node with the same NRI.
If UE is identified by TMSI with unspecific NRI, ZTE RNC will try to use

Zte utran ur11.1 optional feature description

Zte utran ur11.1 optional feature description

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to Zte utran ur11.1 optional feature description

Similar to Zte utran ur11.1 optional feature description (20)

Recently uploaded

Recently uploaded (20)

Zte utran ur11.1 optional feature description