zte optional feature description

8/10/2019 ZTE Optional Feature Description

1/136

UTRAN UR11.2 OptionalFeature Description

PDF !"# "pdfFactory Pro" $#%&'( www.fineprint.cn
http://www.fineprint.cn/http://www.fineprint.cn/http://www.fineprint.cn/


2/136PDF !"# "pdfFactory Pro" $#%&'( www.fineprint.cn


3/136

UTRAN UR11.2 Optional Feature Description

UTRAN UR11.2 Optional Feature Description Version Date Author Reviewer Notes

V1.20 2012/04/24 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.



4/136




5/136


FIGURES

Figure 2-3 Handover from UMTS to GERAN .......... ............ ............. ............ ........... ............. 8

Figure 2-4 Handover from GERAN to UMTS .......... ............ ............. ............ ........... ............. 9

Figure 2-5 Handover from UMTS to GSM .......... ............ .............. ........... ............ ............. .. 10

Figure 2-6 Handover from GSM to UMTS ............. .............. .......... ............. ............. .......... . 11

Figure 2-7 Procedure of CS Fallback to UMTS via redirection for RRC IDLE state .......... .. 13

Figure 2-8 Procedure of CS Fallback to UMTS via redirection for RRC CONNECTED state............................................................................................................................................. 14

Figure 2-9 Procedure of CS Fallback to UMTS via PS Handover................... .......... .......... 15

Figure 2-10 UTRAN to E-UTRAN Inter RAT HO ............ .............. ........... ............ ............. .. 16

Figure 2-11 E-UTRAN to UTRAN Inter RAT HO .......... ........... .............. ............ ........... ...... 17

Figure 2-13 Video Call Fall-Back to Voice ........... ........... .............. ........... ............ ............. .. 21

Figure 2-14 Protocol structure for Iu-pc interface ........... ............. .......... .............. ............ ... 23

Figure 2-15 Networking diagram of Iu-pc connection .......... ........... ............ ............. ........... 24

Figure 2-17 RNC in Pool for Node Redundancy .......... ........... .............. ............ ........... ...... 27

Figure 3-6 Interfaces Isolation of IP port ........... ............. ............ ........... .............. ........... .... 33

Figure 3-7 Operators Isolation of IP port ........... ............. .......... ............. .............. .......... ..... 33

Figure 3-8 VLAN Tag ........... ........... ............. ............. .......... ............. ............. .......... ........... 34

Figure 3-9 PPP/MLPPP Protocol Stack ............ ............. ........... ............ .............. .......... ..... 41

Figure 3-10 Application of IEEE 1588 Clock Synchronization .......... .......... ............. ........... 45

Figure 4-1 16 QAM Constellation Graph ........... ............ .......... .............. ............ ........... ...... 57

Figure 7-1 Basic Principle of 2 ! 2 MIMO Technical Solution ............. ........... ............ ......... 113

Figure 7-2 VAM Option with MIMO .......... ............. ............ ........... .............. ............ .......... 115

TABLES

Table 4-1 HSDPA UE Category Supported by ZTE current version ........... ............. .......... . 47



6/136


Table 6-1 HSUPA UE Category Supported by ZTE ............ ............ ........... ............. ........... 83



7/136


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

Enhancement

No



8/136


1.2 Mobility Management

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

Enhancement

No



9/136


1.2.2 ZWF21-03-021 Hierarchical Cell Structures

Benefits

This feature supports building hierarchical cell coverage in areas with high subscriberdensity 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



10/136


Enhancement

No

1.2.3 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 1-1 Handover from UMTS to GERAN

BSSMAP BSSMAP

PS Ha ndoverRequest ACK

RANAP RANAP

Iu ReleaseComplete

BSSMAP BSSMAP

PS HandoverRequest

RANAP RANAP

RelocationCommand

BSSMAP BSSMAP

PS HandoverComplete

RANAP RANAP

RelocationRequired

UE Node B RNC PS CN BSC

RRC

Handover from UTRANCommand RRC

RANAP RANAP

Iu ReleaseCommand

First correctly receivedRLC/MAC block

(XID Resp., RAU req.or Cell Update)

) PS handover *



11/136


Figure 1-2 Handover from GERAN to UMTS

RANAP RANAPRelocationRequest BSSMAP BSSMAP

RANAP RANAP

BSSMAP BSSMAP

PS HandoverRequired Ack

BSSMAP BSSMAP

BSSMAP BSSMAPClear Complete

RANAP RANAP

RelocationComplete

UE Node B RNC PS CN BSC

RRC Handover to

UTRAN Complete RRC

RR RR

RANAP RANAP

RelocationDetect

PS HandoverRequired

RelocationRequest 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

Enhancement

No

1.2.4 ZWF21-03-024 DTM Handover

Benefits

This feature guarantees the CS service continuity combined with PS service duringInter-RAT moving. It improves user experience.

Description



12/136


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 1-3 Handover from UMTS to GSM

BSSMAP BSSMAP

RANAP RANAP

Iu ReleaseComplete

BSSMAP

RANAP RANAP

UE RNC CS CN PS CN BSC

RRC RRC

RR RR

RANAP RANAP

Iu ReleaseCommand

RANAP RANAP

RelocationRequired

RelocationRequired

BSSMAP BSSMAP

BSSMAP

PS HandoverRequest

BSSMAP BSSMAP

HandoverRequest Ack

Handover Request

PS HandoverRequest Ack

RANAP RANAP

RANAP RANAP

( L3 information: DTM handover Command)

Command

(Target BSS to Source BSS Transpatent container: DTM h andover Command)

Relocation CommandHandover from UTRAN Command

( DTM h andover Command)

BSSMAP BSSMAPHandover Detect

BSSMAPHandover Detect

7 . Handover Complete

BSSMAPBSSMAPHandover Complete

PS HandoverCompleteBSSMAP BSSMAP

RANAP

Iu ReleaseComplete

RANAP RANAP

Iu ReleaseCommand

RANAP

BSSMAP

Relocation



13/136


Figure 1-4 Handover from GSM to UMTS

BSSMAP BSSMAP

PS Handover Required

RANAP RANAP

RelocationRequest Ack.

BSSMAP BSSMAPPS Handover

Required Ack

RANAP RANAPRelocation Complete

RRC

Handover toUTRAN Complete

RR C

RR DTM Handover Command

RR

RANAP RANAP

RelocationDetect

BSSMAPBSSMAP

Handover Required

RANAP RANAPRelocation Request

RANAP RANAPRelocation Request

RANAP RANAP

RelocationRequest Ack.

BSSMAP BSSMAPHandover Command

RANAP RANAPRelocationDetect

RANAP RANAPRelocation 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

Enhancement

No

1.2.5 ZWF21-03-026 Target cell Load based inter-RAT HO

Benefits



14/136


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

Enhancement

None

1.2.6 ZWF21-03-101 CS Fallback from LTE support

Benefits

Voice is a basic service in mobile network. However IP Multimedia Subsystem (IMS) is

required for LTE network to provide voice. It is impossible to deploy IMS and LTE



15/136


network simultaneously for all operators. When LTE network is incapable of voice, voice

call is still provided to user camping in LTE network via CS Fallback.

Description

CS Fallback to UMTS is to provide voice service via UMTS network for user camping in

LTE network without voice capability.

There are two ways for E-UTRAN triggering a UE to perform CS Fallback to UMTS.

One is redirection. When UE originates or terminals a voice call in LTE network,

E-UTRAN notes the UE redirect to UMTS in RRC Release message. Then UE should

back to RRC IDLE state and perform cell reselection to UMTS carrier indicated in RRC

Release message. When UE selects a UMTS cell and camps successfully, UE requestvoice call connection with UMTS network. In order to accelerate UE reselection to UMTS

and reduce duration of voice call establishment, system information of UMTS cell, which

is the target during CS Fallback, can be included in RRC Release message by E-UTRAN

in 3GPP R9. It requires UTRAN support providing system information to E-UTRAN via

core network. Both UE in RRC IDLE state and UE in RRC CONNECTED are allowed to

be Fallback to UMTS via redirection.

Figure 1-5 Procedure of CS Fallback to UMTS via redirection for RRC IDLE state

UE MME

Redirect to UMTS

Voice Service Request

eNodeB

CS Fallback Indicator

RNC MSC

Voice Service Request or Paging Response

RRC Connection

RRC Connec tion

Voice Call Establishment

Fallback to UMT S(Reselect UMTS cell)

Paging

paging

Case: Mobile Terminal



16/136


Figure 1-6 Procedure of CS Fallback to UMTS via redirection for RRC CONNECTED

state

UE MME

Redirect to UMTS


eNodeB

CS Fallback Indicator

RNC MSC

Voice Service Request or Paging response

Data Service Ongoing

RRC C onnection


CS Paging Notification

Case: Mobile Ter minal

Fallback to UM TS(Reselect UMTS cell)

Another is PS handover. If UE has established a data connection, it can be fallback to

UMTS via PS handover. It means in case of such UE request voice call , E-UTRAN sends

handover request for data to core network. It triggers UTRAN allocates resource for the

data. After E-UTRAN receives successful response from core network, it sends

Handover from E-UTRAN Command in air to UE. When UE access to UTRAN via PS

connection, it initials voice connection request.



17/136


Figure 1-7 Procedure of CS Fallback to UMTS via PS Handover

UE MME


eNodeB

Handover from E-UTRAN to UTRAN

RNC SGSN

Voice Service Request or Paging response


Handover Complete


Fallback to UMTS(Establish SRB and

PS Traffic RB)

CS Paging Notification

Case: Mobile Terminal

MSC

Handover Prepare

Handover Complete


Only when both UE and network supporting data service handover from E-UTRAN and

UTRAN, UE with data service connection in E-UTRAN is handover to UTRAN during CS

Fallback. Otherwise, UE is required to release RRC connection by E-UTRAN, and back

to IDLE, then reselects to UTRAN.

CS Fallback also requires UE, core network, and E-UTRAN supporting it. During CS

Fallback, user does not aware of the procedure.

Introduced Version

UR11.2

Enhancement

No.

1.2.7 ZWF21-03-110 Handover with LTE

Benefits



18/136


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 1-8 UTRAN to E-UTRAN Inter RAT HO

UETarget

eNodeB

Forward RelocationRequest

Handover from UTRANCommand

Relocation Required

SourceRNC

Handover request

Handover Request Acknowledge

SourceSGSN

TargetMME

Handover Initiation

Forward RelocationResponse

Relocation Command

E-UTRAN access procedure

Handover to E-UTRAN Complete

Handover Notify

Forward RelocationComplete Notification

Forward RelocationComplete Acknowledge

Iu Release Command

Iu Release Complete



19/136


Signal flow for PS service handover form E-UTRAN to UTRAN is shown in the figures

below.

Figure 1-9 E-UTRAN to UTRAN Inter RAT HO

UETargetRNC

Forward RelocationRequest

Handover from E-UTRANCommand

Handover Required

SourceeNodeB

Relocation Request

Relocation Request Acknowledge

SourceMME

TargetSGSN

Handover Initiation

Forward RelocationResponse

Handover Command

UTRAN acce ss procedure

Handover to UTRAN Complete

Relocation Complete

Forward RelocationComplete Notification

Forward RelocationComplete Acknowledge

Release Resource

This feature includes dual direction handover between UMTS and LTE, and it is applied

in only PS service scenario.

When Both TDD LTE coverage and FDD LTE coverage are exist in same area, UTRAN

filters E-UTRAN neighbor cell of measurement in dedicated mode according to UE

capability, for example just FDD E-UTRAN carrier is sent for UE with only FDD LTE

capability.

Introduced Version

UR11. 2



20/136


1.3 Radio Resource Management

1.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 aresult, 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 certainthreshold, 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



21/136


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

Enhancement

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.



22/136


1.4 QoS Guarantee

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

Enhancement

No

1.4.2 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



23/136


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 1-10 Video Call Fall-Back to Voice

UE Node BServing RNS

ServingRNC

CN

RRCRRC7. DCCH : Radio Bearer Reconfiguration Complete

NBAP NBAP4. Radio Link Reconfiguration Ready

NBAP NBAP 5. Radio Link Reconfigurat ion Commit

RRCRRC6. DCCH : Radio Bearer Reconfiguration

RANAP RANAP

8. RAB AssignmentResponse

RANAP RANAP

2. RAB AssignmentRequest

[Modification]

NBAP NBAP3. Radio Link Reconfiguration Prepare

RANAP RANAP

1. RAB ModificationRequest

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



24/136


U9.1&Before

Enhancement

No

1.5 Location Service

1.5.1 ZWF21-10-003 Emergency Call Re-direct to GSM

Benefits

If location service is not provided in UMTS system, or accuracy of location service inUMTS 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



25/136


Enhancement

No

1.5.2 ZWF21-10-008 Iu-pc Support

Benefits

A SAS (Stand-Along SMLC) can be connected to RNC with Iu-pc interface. It enables

LCS deployment and maintains in entire network without depending on a single RNC.

Description

Iu-pc interface is a standard interface specification in 3GPP. The protocol structure of

Iu-pc is showing in figure below.

Figure 1-11 Protocol structure for Iu-pc interface

PCAP

Transport Network

Layer

Physical Layer

User Transport Network

Plane

Radio

Network

Layer

SSCF-NNI

SSCOP

MTP3-B

IP

SSCF-NNI

AAL5

SCTP

SCCP

M3UA M3UA

SCTP

IP

ATM Data Link

SSCF-NNI

Iu-pc interface is used to connect a RNC to a SAS (Stand-Along SMLC), as the following

figure showing.



26/136


Figure 1-12 Networking diagram of Iu-pc connection

When ZTE RNC is connected to a SAS with Iu-pc interface, LCS is working in

SAS-centric mode. The method for location, GPS assistant data providing and location

calculating is in SAS. RNC transmits location request and offer LCS measurement report

to SAS, as well as transfers location data to CN.

In SAS-centric mode, RNC supports Cell ID with/without RTT and AGPS methods. It

means RNC is able to initial measurement for these LCS methods.

Introduced Version

UR11.2

Enhancement

No

1.6 RAN Management

1.6.1 ZWF21-20-017 Intelligent Carrier Power Off/On

Benefits



27/136


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.

With Intelligent Carrier Power off/on feature, RAN monitors traffic status. When the traffic

volume of a carrier is relatively low, the RAN can automatically close it. There are two

methods to evaluate traffic volume.

One is based on user number in connected mode. If the number of user in connected

mode in a carrier is below a pre-defined threshold, the carrier could be closed. Another is

to taken service QoS into account. If all online service of a carrier can be borne in other

carriers in the same sector, then the carrier could be closed. In this case, GBR for

real-time service and a minimal bit rate for non real-time service are considered when

RAN checks the resource allocation in other carrier.

Applicable time period of this function could be defined, only when carrier could be

powered off intelligently.

If RAN finds that the traffic volume increases to such a threshold that the current working

carrier frequencies cannot handle the extra services, it open the closed carrier

frequencies.

When the traffic volume is very low and it is necessary to close some carriers, RAN

gradually reduce the maximum transmitting power of a cell until the RF units on the

redundant carrier frequencies are switched off. In this way, online service in the cell

being switched off can be handover to neighboring inter-frequency cells or neighboring

intra-frequency cells.



28/136


Introduced Version

U9.1&Before

Enhancement

In release UR11.2, traffic volume is evaluated to make decision of intelligent carrier

power off or power on.

1.7 Enhanced RAN Functionality

1.7.1 ZWF21-30-206 RNC in Pool for Node Redundancy

Benefits

This feature provides RNC level backup to avoid single node failure problem in

network and improve whole network reliability.

Description

A number of ZTE RNCs are able to compose a pool. When one RNC breaks down due to

some reasons, for example disaster or power outage, and cannot recover for a certain

period, Node Bs controlled by this RNC could be switched to other RNCs in the pool.

Pooling protection rather than one to one protection can save a lot of cost of reserved

backup hardware. Normally when dimensioning of RNC capacity, some margin hardware

processing resource should be considered for potential burst traffic in network even

higher than estimated peak. Actually the margin process capability also could be used for

RNC level node backup purpose if this feature is applied.

From Node B point of view, each Node B connects to two RNCs. One is primary RNC

who provides management and service connection in normal state. Another is backup

RNC who only provides management and service connection in abnormal situation of

primary RNC. Each RNC has necessary parameters of this Node B. Each Node B keeps

monitoring connection status to its primary RNC. If the connection breaks down for a

certain time, while network services also are not available, Node B considers its primary



29/136


RNC faulty and automatically switches connection to its backup RNC. After switching,

Node B will be able to provide service again.

Figure 1-13 RNC in Pool for Node Redundancy

All Node Bs controlled by a RNC can be divided into several groups. A group of Node Bs

connects to the same backup RNC. Different groups of Node Bs connect to different

backup RNC. Each RNC in the pool could be as the role of backup RNC of other RNCs in

the pool. Therefore capacity of one RNC can be distributed to other RNCs. All RNCs

together protect failure of any one RNC among them.

This feature needs all IP transmission on mobile backhaul. And parameters in backup

RNCs for Node Bs of other RNCs should be prepared ready in advance. For reduction of

complexity of network planning, not all but some groups of Node Bs in priority area could

be picked out to be protected with connection to two RNCs.

Introduced Version

UR11.2, only two RNCs can be in one pool.

Enhancement

No

RNC1

RNCnRNC

2

RNC in Pool

Node BGroup 1 Node B

Group 2Node BGroup 3

Core Network



30/136


2 Transport Network Functionality

2.1 ZWF22-03-A IP UTRAN PACKAGE

2.1.1 ZWF22-03-001 IP Transmission Stack

Benefits

Instead of ATM, IP is used as the transmission protocol inside the UTRAN or between

the UTRAN and the CN, to meet the rapid increasing requirements on traffic because of

the introduction of HSPA and rapid development of data service.

Description

The IP can be deployed as the replacement of ATM transmission protocol in UTRAN

network in the 3GPP R5 standard. To ensure the reliable transmission of No. 7 signaling

in IP network with the QoS guarantee, 3GPP recommends that the transport layer of

radio network control plane adopts Sigtran protocol cluster. The Sigtran protocol cluster

referred in IP UTRAN includes the Stream Control Transport Protocol (SCTP) and MTP3

User Adaptation layer (M3UA). In the transport layer of radio network user plane, for

Iu-PS interface data transport adopts GTP-U protocol over UDP, for Iu-CS interface datatransport adopts RTP/RTCP protocol, while only SR of RTCP is used to cooperate with

peering CN for the purpose of RTP transmission monitoring, for Iub and Iur interface data

transport adopts UDP protocol directly.

ZTE RAN equipment supports the full IP protocol stack on Iub, Iur, IuCS and IuPS

interfaces. IP transmission can be deployed independently on each kind of interface.

For planning of IP address of radio layer, ZTE RNC usually use different IP for control

plane and use plane. While in control plane or user plane, the same IP could be used for

Iu, Iur and Iub interface to save IP address resource if necessary, or different IP could be

used for different interface to adapt transmission strategy, which is the insulation of

convergence layer and access layer or different domain. Either same or different IP could

be used in ZTE Node B for control plane and use plane of Iub interface.



31/136


Introduced Version

U9.1&Before

Enhancement

In U9.3, ZTE RNC support to set different IP for Iu, Iur and Iub interfaces in user plane.

In U9.3, ZTE RNC supports MTU up to 1620, including MAC and PPP.

2.1.2 ZWF22-03-002 Static Route

Benefits

This feature supports configuring IP route information of the UTRAN by OMC.

Description

The static route is the route information configured by the network administrator manually.

When the network topology structure is changed, the network administrator should

modify the related static route information in the route table manually. The static route

information is private by default, and will not be sent to other routers. In the planning of IP

RAN network, the network topology is usually simple and the static route is sufficient to

meet the requirements.

The static route modes which ZTE supports are as follows:

Direct route generated automatically by interface IP address

If the IP address and mask are configured for IP interface board of RNC

equipment, the system will generate automatically a direct route for the

corresponding sub-net of the interface IP.

Static route based on next-hop IP address

The static route of next-hop IP address can be configured manually by OMCR.

Each static route supports several next hops.

Static route based on IP UNNUMBER



32/136


33/136


Client are not in the same subnet, DHCP Relay is needed to transfer messages between

Server and Client.

Node B is always used as DHCP Client when DHCP is applied in UNRAN, then DHCP

Server may be other PC or RNC which supports it. If Node B and PC or RNC used as

DHCP Server are not in the same subnet, the router in the transmission network is

needed to support DHCP Server function.

For IP transmission over E1/T1 which is low rate link through PPP/MLPP, ZTE RNC

equipment can be used as DHCP Server to dynamically allocate IP address of Node B.

When Ethernet is used for IP transmission between RNC and Node B, ZTE RNC

supports DHCP Server function to allocate IP address for Node B, or acts as DHCP relay

to aggregate L2 physical link in front of DHCP server.

Introduced Version

U9.1&Before

Enhancement

In U9.2, RNC supports DHCP Server and DHCP Relay function when Ethernet is used

for IP transmission.

2.1.4 ZWF22-03-005 IP Traffic Shaping

Benefits

When service throughput of one interface or port is overabundant, IP traffic shaping can

be used to shape the different services of this interface or port to protect it from

congestion, which helps to improve network utilization rate, system efficiency and QoS.

Description

When IP UTRAN is adopted in RNC, there is data transmission from Iub to Iu and from Iu

to Iub, also including Iur interface; besides, there may be synchronously transmitted data,

signaling and O&M information, which should be differentiated. When IP packets from

one interface or one port are overabundant and they cannot be transmitted from the

other interface or port, RNC is required to control the service QoS by definite congestion



34/136


control algorithm. This function provides IP traffic shaping based on priority queue

mechanism.

Provide IP traffic shaping to different service of IP ports in transmission, mainly provide

excellent priority-based queue forwarding mechanism, and realize fair Weighted Round

Robin (WRR) scheduling, which enables the traffic with higher weight to have more

chances to be scheduled than lower-weight traffic, thus providing different control to

different services.

Introduced Version

U9.3

Enhancement

None

2.1.5 ZWF22-03-006 IP Routing and Forwarding

Benefits

This feature provides flexible IP networking capability with high security to isolate Iu, Iub

and Iur interfaces or to isolate these interfaces belonging to different operators in RAN

sharing scenario.

Description

ZTE RNC equipment is based on all-IP switching platform, which is related to the feature

of ZWF22-01-001 IP Switching Platform. This all-IP switching platform is able to not only

transfer traffic date from Iu, Iub and Iur interfaces, but also compose all IP interface

boards of one RNC into one routing domain and share a global routing table which is

either static configuration in RNC or dynamically derived from OSPF function. Therefore

RNC can work as a whole L3 IP router. So that RNC can be used to transfer scantlingdata to other network nodes, for example O&M data from Node B to OMC server or Abis

interfaces from BTS to BSC, via Iub transmission.

VRF, Virtual Routing and Forwarding, is also provided by ZTE RNC for flexible IP

networking with security. VRF is a technology that allows multiple instances of a routing



35/136


table to co-exist within the same router at the same time, differentiated by VPN ID.

Because the routing instances are independent, the same IP port can be divided to

different logical ports connecting to different IP networks.

Figure 2-1 Interfaces Isolation of IP port

Node B

Router RNC

VPN2

VPN3

VLAN2

CNVLAN3

UP+CP

UP+CP

VRF is useful when different interfaces share the same physical IP interface ports but

with L3 isolation among different interfaces.

Figure 2-2 Operators Isolation of IP port

CN1

Router RNC

VPN2

VPN3

VLAN2

CN2VLAN3

UP+CP

UP+CP

Operator A Network

Operator B Network

VRF is also useful when different operators share the same physical IP interface ports

but with L3 isolation among different operators.

Introduced Version

UR11.2

Enhancement

No



36/136


2.1.6 ZWF22-03-011 VLAN for Node B

Benefits

This feature supports dividing Node Bs and other equipments in the same physicalnetwork into different logic network (Virtual Local Area Network, VLAN). In this way, the

packet is restricted to save transmission bandwidth, and the system security is

enhanced.

Description

ZTE Node B supports VLAN function which complies with IEEE 802.1Q standards. The

common Ethernet frame can become the Ethernet frame supporting 802.1Q by adding 4

bytes, which is as follows:

Figure 2-3 VLAN Tag

CRCDA SA Type Data

StandardEthernet Frame

Priority(4bits)

TCITCI

DA SA Type Datatag

TPID(0x8100)

CFI(1bit)

VLAN ID(12bits)

TCITCI

Ethernet Frame with IEEE 802.1Q T ag

CRC

l Tag Protocol Identifier (TPID), 802.1Q tag identifier, with a value of 0x8100

l Tag Control Information (TCI), including:

VLAN Identified (VLAN ID): 12 bit ID which indicates the VLAN to which each

packet belongs.

Canonical Format Indicator (CFI):1bit which partitions the frame structure

when the bus Ethernet exchanges data with FDDI or token ring network.



37/136


Priority: 3bits, meets the COS definition in IEEE 802.1P criterion; the higher

the value is, the higher the priority of the frame is. 0 indicates the lowest

priority.

The different VLANs can be divided by VLAN tag in the same physical network; the

interconnection between VLANs is available only by routing or other means, instead of

direct interconnection. In this way, the broadcast packet is restricted in VLAN domain, the

bandwidth is saved, and the domain security is enhanced.

Introduced Version

U9.1&Before

Enhancement

No

2.1.7 ZWF22-03-012 VLAN for RNC

Benefits

This feature supports dividing RNCs and other equipments in the same physical network

into different logic network (Virtual Local Area Network, VLAN). In this way, the packets

are restricted to save transmission bandwidth, and the system security is enhanced.

Description

The ZTE RNC supports division of VLANs in compliance with the IEEE 802.1Q and

802.1P.

Each Ethernet interface of RNC can have multiple sub-interfaces, with each

sub-interface corresponding to a VLAN. When receiving a packet with VLAN tag, RNC

can identify the sub-interface to which the packet belongs according to the VLAN ID.

When sending a packet, it identifies the ID of the sub-interface of the peer end NE

through route query, marking the VLAN ID corresponding to the sub-interface, puts

packets in a transmission queue according to the COS in the header of the packet. The

packet with the highest priority will be transmitted first.

Introduced Version



38/136


U9.1&Before

Enhancement

No

2.1.8 ZWF22-03-014 IP Header Compression

Benefits

This feature can be used to reduce the consumption of IP headers and improve the

utilization ratio of transmission bandwidth.

Description

In IP transmission, the user plane data between NEs are mainly carried in UDP packets.

Each user plane data packet will include the overheads of network layer, herein referred

to as the overheads of IP and UDP headers with a total of 28 bytes (20 bytes for the IP

header, 8 bytes for the UDP header). These overheads will do harm to the transmission

efficiency of the link with the low rate packet (such as the IP over E1).

ZTE RAN equipment supports an IP header compression method defined in RFC2507,

efficiently reducing the IP and UDP header overheads of each packet and improving the

transmission efficiency.

Introduced Version

U9.1&Before

Enhancement

No

2.1.9 ZWF22-03-015 DiffServ

Benefits

This feature provides differentiated handling priority for different service classes, to

ensure the QoS of different service classes.



39/136


Description

ZTE RAN equipment supports the DiffServ (Differentiated Services) technology defined

in IETF RFC2474 and RFC2475. Messages of different service on Iu/Iur/Iub interface

have been marked with different DSCP values in IP header, which can provide the QoS

guaranteed and the priority differentiation. DSCP (Differential Service Code Point) has 6

bits, redefining the TOS field of IPV4, it is renamed DS and carries the information

required by IP packet service. Technically, it is a three layer technology without low-layer

transmission technology involved.

DiffServ categorizes QoS service requirements by two mechanisms: DS mark and

Per-Hop-Behavior (PHB). Some different service levels are generated by processing

different marks of a packet DS field and PHB definition based on DS fields. ZTE RAN

equipment configures each service with corresponding DSCP value on OMCR based on

its type, the metering, packet loss, and shaping functions are implemented by queuing

and scheduling mechanism based on the DSCP service hierarchy, so the definition of the

QoS classes in wireless network layer can be mapped to the transmission network layer.

ZTE RAN equipment marks the DSCP of each service in the bearing IP packet. Network

elements, such as a router with MPLS function, examines the value of the DSCP field

along the transmission path and classifies the service levels. So the IP QoS function

based on DiffServ is accomplished together with the IP bearer network and the UTRAN

architecture.

Introduced Version

U9.1&Before

Enhancement

No

2.1.10 ZWF22-03-017 QoS based Route

Benefits



40/136


This feature supports setting different IP transmission paths for different services based

on service type. For different services, different QoS levels are provided, and the

transmission cost is saved.

Description

For all-IP networking, taking the transmission network cost as well as provided QoS level

into account, the operator can set different transmission paths for different services. ZTE

supports three QoS-based IP route transmission scenarios:

Real-time services are carried by IP over E1, while the non-real-time services

are carried by Ethernet.

Different services use different GE/FE ports and pass through different

transport networks.

Services are isolated by setting VLANs with different priorities for different

services.

The data service with the requirement of low real-time and high transport bandwidth is

carried on the transmission network with low QoS and lower cost. The service with high

real-time requirement such as voice is carried on the higher cost transmission network

with guaranteed QoS. In this way, the transmission cost can be minimized.

Introduced Version

U9.1&Before

Enhancement

No

2.1.11 ZWF22-03-018 IP Fast Reroute

Benefits

This feature provides the functions including the rapid detection and the protection of IP

route, decreasing the influence on real-time service (such as the voice service) due to IP

transmission failure and handover.



41/136


Description

The IP network does not have intermittent fault recovery function for the sub-second level,

while the traditional route structure has limited fault detection capability on the real-time

applications (such as the voice service). The requirements on fast fault detection and

correction function are getting stricter due to the application of the IP voice and other

real-time services. It is critical to prevent the route network from long-time interruption.

ZTE RAN equipment supports BFD (Bidirectional Forwarding Detection) technology,

which makes it possible to detect errors in forwarding path in a very short period and

trigger the switch to standby route or transmission channel by monitoring the availability

of transmission paths which correspond to each next-hop in the static route in real time.

So the troubleshooting time can be reduced to less than a second.

ZTE RAN equipment also supports IP route fault detection and switching based on ICMP

and 802.3ah, which will be useful if BFD cannot be applied because of some limit of

backhaul.

Introduced Version

U9.1&Before

Enhancement

Node B supports BFD based IP fast reroute in UR11.1 release.

In UR11.2, new methods of IP route fault detection and switching based on ICMP and

802.3ah are supported.

2.1.12 ZWF22-03-021 Transmission SLA Monitoring

Benefits

This feature enables to diagnosis and test IP transmission network to get to know the

QoS indexes ,such as time delay, jittering, and response time.

Description



42/136


ZTE RNC supports the SLA detection function. By exchanging the ECHO and REPLY

packets of the SLA between base stations, ZTE RNC can detect the performance

indexes (time delay, jittering, packet loss rate, bandwidth, and throughput) of the IP

transmission channel in Iub, Iur and Iu interfaces. The SLA detection adopts a tunnelingtechnology. ZTE RNC can encapsulate the detection packets into the ICMP or UDP

packets (depending on the attributes of the device in the commercial network).

It supports SLA test between ZTE RNC and ZTE Node B, and it adopts UDP

packets and ICMP packets.

It supports SLA test between ZTE RNC and other manufacturers " CN, RNC

and Node B, and it adopts ICMP packets.

ZTE RNC supports SLA test between intermediate routers, and adopts ICMP

packets.

The SLA detection of ZTE RNC supports instant test and performance test. Through the

instant test, ZTE RNC can conduct a single SLA test for a specified object (the IP

address of a Node B); through the performance test, ZTE RNC can configure a test task

and conduct consecutive SLA tests for a specified object.

In the instant test, ZTE RNC can configure the SLA message forwarding rate and packet

length through the test task and test the transmission bandwidth of the IP channel.However, the test is destructive and may cause loss of normal service data. Therefore,

the measurement parameters must be configured carefully.

Introduced Version

U9.1&Before

Enhancement

No



43/136


2.2 Optional Transmission Interfaces

2.2.1 ZWF22-03-051 IP over E1

Benefits

This feature supports IP over E1, conveniently fulfilling all-IP networking of UTRAN with

existing low rate E1 link.

Description

The E1 physical interface complies with ITU-T G.703 standard. The allowed jitter of the

physical interface complies with ITU-T G.823 standard. The structure of the frame which

is transferred over the E1 interface complies with the ITU-T G.704 standard. The E1 has

32 timeslots numbered 0 to 31. Where, timeslot 0 is used to carry the synchronization

information of the clock, and timeslot 16 for carrying the control signals (also transferring

information signals if necessary). If out-of-band common channel signaling (CCS) is

adopted, the timeslot 16 don "t need to transfer signaling, it can also carry data. Other

timeslots can carry data. ZTE uses the 31 timeslots to transfer data. An E1 supports the

physical bandwidth of 1984 kbps.

Figure 2-4 PPP/MLPPP Protocol Stack

IP

E1HDLC

PPPHDLC

PPPMLPPP/MCPPP

HDLCPPP

ZTE RAN equipment supports IP over E1 by PPP and ML/MC-PPP protocol, the protocol

stacks are described in Figure 3-11. PPP protocol processing complies with RFC1661

and RFC1332 criterion, MLPPP processing complies with the RFC1990 criterion, and the

MCPPP processing complies with the RFC 2686 criterion.

MLPPP can integrate multiple PPP low rate links into one high rate link. MCPPP

supports up to 4 classes of priority (0~3, class 0 is the highest priority and class 3 is the



44/136


lowest one). MCPPP can guarantee the preferential processing for high priority service in

narrowband link.

When there are many low rate links, no matter PPP or MLPPP, the protocol can be set at

the OMC. In MLPPP mode, which links to group an MLPPP can be set at the OMC as

well. If some links fail when many low rate links grouped with MLPPP, the transmission

bandwidth of whole MLPPP group is influenced, but other links still guarantee that the

MLPPP group can serve the upper layer.

Introduced Version

U9.1&Before

Enhancement

No

2.2.2 ZWF22-03-055 IP over Optical GE

Benefits

This feature supports IP over optical GE, providing higher transmission bandwidth and

farther transmission distance by optical fiber.

Description

Optical GE transmission supported by ZTE RAN equipment complies with IEEE 802.3z

standards. The transmission media include long-wave single-mode or multi-mode fiber

(meets 1000Base-LX criterion), short-wave multi-mode fiber (meets 1000Base-SX

criterion), the data rate can reach 1000Mbps.

ZTE RAN equipment supports GE mode, IEEE 802.3 standard Ethernet frame structure

and VLAN frame structure which meets IEEE802.1Q and 802.1P criterions.

Introduced Version

U9.1&Before

Enhancement



45/136


No

2.2.3 ZWF22-03-056 IP over Optical FE

Benefits

This feature supports IP over optical FE in Node B, providing higher transmission

bandwidth and farther transmission distance by optical fiber.

Description

Optical FE transmission supported by ZTE Node B complies with IEEE 802.3 standards.

The transmission media includes single-mode or multi-mode fiber (meets 100Base-FX

criterion), the data rate can reach 100Mbps.

ZTE Node B equipment supports FE fiber mode, IEEE 802.3 standard Ethernet frame

structure and VLAN frame structure which meets IEEE802.1Q and 802.1P criterions.

Introduce Version

U9.1&Before

Enhancement

No

2.2.4 ZWF22-03-010 IEEE 1588

Benefits

This feature supports synchronizing Node B from IP transmission network via IEEE 1588

V2 protocol. It solves the problem that the Node B cannot synchronize to BITS clock

source or transmission line as well as avoiding the high investment on GPS.

Description

As an asynchronous network, the clock synchronization between RNC and Node B isn "t

needed in UMTS. But the frequency deviation may be out of scope after long time

running because the high-precision clock can "t be provided in the Node B, and the UE



46/136


handover between different Node Bs may be influenced. So the Node B should be

synchronized to the high-precision clock to guarantee network KPI. The accuracy of

frequency synchronized is 0.05ppm.

ZTE supports IEEE1588 network time synchronization protocol (also called Precision

Time Protocol), which synchronizes clock to a distributed system consisting of one or

more nodes by network communication. This protocol adopts the master-slave

synchronization mode. The slave port can obtain synchronization information from the

master port to implement high-precision clock synchronization.

IEEE 1588 clocks can be used for clock synchronization when FE or GE transmission is

used on the Iub interface. The IEEE 1588 clock synchronization function is completed by

RNC and Node B together. The RNC serves as Master that provides exact clock source.

The Node B serves as Slave that extracts the clock information and performs the clock

synchronization. The clock precision may be influenced by the delay and the jitter of the

network if the IP network between RNC and Node B is complex and the number of

middle nodes is numerous. The clock source can also be set at a certain transmission

node from which Node B can obtain the clock synchronization by IEEE 1588.

To fulfill clock precision defined by 3GPP specification, there are some requirements on

the transmission link between the IEEE 1588 clock source and the Node B:

One trip transport delay


47/136


Figure 2-5 Application of IEEE 1588 Clock Synchronization

Introduced Version

U11.2

Enhancement

2.3 Other TN Related Functionality

2.3.1 ZWF22-01-010 IP/ATM Hybrid Transmission

Benefits

This feature supports ATM and IP protocol which are simultaneously used as the

transmission on Iub interface. For operator, the benefits brought by hybrid transmission

are as follows:

Adequately utilize the existing TDM transmission network, carry real-time

traffic (such as voice) on ATM to guarantee the QoS, and save the cost of

upgrade to the high quality IP network carrying all services.

Carry PS traffic with high data rate and lower QoS requirement by low cost IP

network.

Node B Master

RNC

RNC Master

Slave

Node B

Switch

Switch

Slave

GPS Network



48/136


Description

ZTE supports ATM and IP on Iub interface simultaneously, and allocates different bearer

for different service types. Generally, for those data services with relaxed real time but

higher bandwidth requirement, IP transmission can be used. For signaling in control

plane, voice service, and other real time data services, ATM transmission can be used.

The RNC automatically allocates transmission bearer for service based on its type while

service is built, and fulfills hybrid transmission.

Introduced Version

U9.1&Before

Enhancement

No

3 HSDPA

3.1 ZWF23-01-A HSDPA Introduction Package

3.1.1 ZWF23-01-003 HSDPA UE Category Support

Benefits

This feature supports different HSDPA UE categories. Different UE categories are

defined to support different data rate capability.

Description

ZTE RAN equipment supports all HSDPA UE categories defined in 3GPP TS 25.306

which describes the terminal capability for HSDPA. HS-DSCH physical layer categories.

See " # $ % & ' ( ) .



49/136


Table 3-1 HSDPA UE Category Supported by ZTE current version

Category

Max. No.

of

HS-DSCHCodes

Min.

Inter-TTI

Interval

Supported

Modulations

Supported

carrier

Number

MIMO

Operation

MAC

Layer

Peak BitRate

1 5 3 QPSK/16QAM 1 N/a 1.2Mbps








9 15 1 QPSK/16QAM 1 N/a 10Mbps

10 15 1 QPSK/16QAM 1 N/a 13.9Mbps

11 5 2 QPSK 1 N/a 0.9Mbps

12 5 1 QPSK 1 N/a 1.8Mbps

13 15 1 QPSK/16QAM/64QAM 1 N/a 17.6Mbps

14 15 1 QPSK/16QAM/64QAM 1 N/a 21Mbps

15 15 1 QPSK/16QAM 1 Activated 23.3Mbps


17 15 1 QPSK/16QAM/64QAM 1 Inactivated 17.6Mbps

QPSK/16QAM 1 Activated 23.3Mbps

18 15 1 QPSK/16QAM/64QAM 1 Inactivated 21Mbps

QPSK/16QAM 1 Activated 27.9Mbps

19 15 1 QPSK/16QAM/64QAM 1 Activated 35.3Mbps


21 15 1 QPSK/16QAM 2 N/a 23.4Mbps

22 15 1 QPSK/16QAM 2 N/a 28.0Mbps







50/136


Category

Max. No.

of

HS-DSCH

Codes

Min.

Inter-TTI

Interval

Supported

Modulations

Supported

carrier

Number

MIMO

Operation

MAC

Layer

Peak Bit

Rate



ZTE RAN equipment supports automatically recognize and activate corresponding

HSPA+ functions based on UE category.

Introduced Version

U9.1&Before supports UE with all HS-DSCH physical layer categories below 14. UEs of

Category 13 and Category 14 support 64QAM but not MIMO.

Enhancement

In U9.2, UE with HS-DSCH physical layer categories 15, 16, 17 and 18 are supported.

UEs of Category 15 and Category 16 support MIMO but not 64QAM. UEs of Category 17

and Category 18 support 64QAM and MIMO, but the two technologies cannot be used

simultaneously.

In U9.3, UE with HS-DSCH physical layer categories 21, 22, 23 and 24 are supported.

UEs of Category 21 and Category 22 support DC-HSDPA, but do not support 64QAM.

UEs of Category 23 and Category 24 support the combination of DC-HSDPA and

64QAM.

In UR11.1, UE with HS-DSCH physical layer categories 19, 20, 27 and 28 are supported.

UEs of Category 19 and Category 20 support combination of MIMO and 64QAM. UEs of

Category 23 and Category 24 support the combination of DC-HSDPA, MIMO and

64QAM, while the peak bit rate can be reached only if the network could activate the

combination of those three functions.

In UR11.2, UE with HS-DSCH physical layer categories 25, 26 are supported. For

Category 27 and 28, the combination of DC-HSDPA, 64QAM and MIMO is available.



51/136


3.1.2 ZWF23-01-004 Flexible HSDPA Deployment

Benefits

This feature supports flexible deployment of dedicated HSDPA carrier or R99 and

HSDPA in the same carrier.

Deployment of R99 and HSDPA in the same carrier will use the spare resources of R99

for high data speed services. The HSDPA can make full use of the remaining resources

in cells to improve resource utilization and reduce the OPEX.

Deployment of dedicated HSDPA carrier supports higher downlink peak rate and cell

throughout of PS service on HSDPA dedicated carrier.

Description

The HSDPA deployment supports two ways:

One carrier supports R99 and HSDPA simultaneously.

Dedicated carrier constructs a HSDPA network.

If an operator has limited frequency resources but has to provide the R99 services,

sharing the carrier frequency of R99 and HSDPA allows the operator to provide R99

services and HSDPA services at the same time and profitably develop high-speed data

services through the residual resources of R99. Common resources (including

channelized codes, Node B transmit power, and Iub interface transmission bandwidth) of

the cell can be allocated between R99 services and HSDPA services.

However, the peak rate and throughput provided by the cell are reduced and the

experience of data service users is affected when the R99 services occupy

resources.ZTE RAN equipments support both R99 and HSDPA services simultaneously

in one cell. ZTE RRM algorithm will guarantee appropriate cell common resources

allocation between these two services.

If the operator has more frequency resources than required by the R99 services, a

dedicated carrier frequency can be deployed to provide the HSDPA services. Comparing

with the DCH, HS-DSCH has higher spectrum utilization to get higher peak rate and cell

throughput, improving the subscriber experience of the mobile data service and reducing

the unit cost of the high-speed data service. Normally, the third or above carrier can be

used as HSDPA dedicated carrier to provide data services in hotspot coverage.



52/136


The cell can be configured as HSDPA dedicated carrier or HSDPA and R99 hybrid

carrier. The R99 services can not be initiated on HSDPA dedicated carrier. Besides

HSDPA dedicated carrier frequency, R99 capable carrier should also be deployed so as

to support the traditional CS service and low-speed PS service (on DCH). ZTE "s RANequipments provide different kinds of carriers for users according to services types.

Introduced Version

In UR11.1, this function takes place of features of ZWF23-01-001 HSDPA Common

Carrier with R99 and ZWF23-01-002 HSDPA Dedicated Carrier previously in U9.3

release.

Enhancement

No

3.1.3 ZWF23-01-011 HSDPA Adaptive Modulation and Coding

Benefits

This feature provides a link adaptation technology which can realize real time balance of

the link according to the change of the fading channel to increase system capacity and

improve communication quality.

Description

AMC works on the following principle: Node B in network side selects the optimal

downlink modulation mode, coding method and the number of HS-DSCH Channel

according to the radio channel quality status (CQI report) reported by UE and the

utilization of network resources so as to determine the rate of data transmission, raise

the data throughput of the UE, and reduce transmission delay in condition of radio quality

permission. AMC will increase system capacity and improve communication quality

according to the fading channel modification to implement link real-time balance.

ZTE can support two types of link adaptation technologies (AMC), including inner-loop

link adaptation and outer-loop link adaptation.



53/136


Inner-loop link adaptation should be based on the CQI (Channel Quality Indication). The

core principle is that Node B selects the modulation and coding mode and size of the

transmission block according to the CQI. When the UE is at a favorable communication

point (for example, the UE is close to Node B or a direct ray path is available), ahigh-order modulation and high-rate channel coding mode (for example, 16QAM and 3/4

coding rate) can be selected to transmit subscriber data accordingly to obtain the higher

transmission rate. When the UE is at a far point of the cell, or in a high-fading or shadow

area, a low-order modulation and low-rate channel coding mode (for example, QPSK and

1/4 coding rate) can be selected to ensure communication quality.

Outer-loop link adaptation is based on the ACK/NACK/DTX feedback by HS-DPCCH.

The CQI has the disadvantages of delay and measurement error. Therefore, the

inner-loop link adaptation only will be insufficient to control the downlink BLER in order tomeet target value under any circumstance. In this case, outer-loop link adaptation is

required.

Introduced Version

U9.1&Before

Enhancement

No

3.1.4 ZWF23-01-012 HSDPA Multiplex

Benefits

This feature supports HS-PDSCH code division multiplexing and time division to share

HSPA channel and improve the channel utilization to the largest extent.

Description

The HS-PDSCH is shared by all HSDPA users in the cell. Node B will divide the

resources to different UEs. ZTE RAN equipments can support the following multiplexing

methods:

Code Division Multiplexing



54/136


ZTE UMTS Node B allows up to four UEs to be scheduled within a 2ms TTI in

a cell. However, the number of channelized codes allocated to a UE is limited

by UE HSDPA category.

Time Division Multiplexing

The same HS-DSCH channel can be allocated to the different HSDPA users

according to 2ms TTI.

During code division multiplexing, all available HS-DSCH channel codes can be divided

into several subsets, which are allocated to different users. This mode can support not

only the transmission of a small amount of data (in this case, the transmitted data needs

only some channelized codes of the HS-DSCH in the cell), but also the resource

allocation for the UEs with different HSDPA categories.

Time division can realize the fast scheduling on HS-DSCH channel in a 2ms period and

allocate the cell throughput according to different user "s requirements of services.

Introduced Version

U9.1&Before

Enhancement

No

3.1.5 ZWF23-01-013 HSDPA Fast Scheduling

Benefits

This feature can provide many kinds of scheduling algorithm. It will use a 2ms period to

schedule terminal channel and service. It will implement the fast scheduling on radio

resources among different users to improve the throughput of the whole cell.

Description

HSDPA introduces a new functional entity MAC-hs which is moved from RNC to NodeB

to finish the data scheduling. Based on the channel quality information, terminal



55/136


capability, QoS category and the current available NodeB power/code resources, NodeB

will implement the fast scheduling with a 2ms period for the terminal data services.

ZTE RAN equipments support Proportional Fair (PF) scheduling algorithms. NodeB

schedule should consider the channel quality and history flow of user. The cell

throughput and the user fairness should be considered simultaneously.

The PF algorithm can help realize larger throughput rates and better service fairness.

ZTE RAN equipments can support the following Enhanced Functions based on PF

scheduling algorithm.

l Support configurable Fair Factor

By configuration of different fair factors, the PF algorithm will approach to fairservice time algorithm (more and more fair) or Max C/I (less and less fair, but will

gain the highest c

zte optional feature description

Documents