Feature Description
Feature Description
UTRAN UR1
UTRAN UR11.2 Optional Featur
1.2 Optional Feature Description
e Description
VersionVersion DateDate Author Author Reviewer Reviewer NotesNotes
V1.20
V1.20 2012/04/24 2012/04/24 ZTE ZTE Not Not open open to to the the third third partyparty
2012 ZTE Corporation. All rights reserved. 2012 ZTE Corporation. All rights reserved.
ZTE CONFIDENTIAL: This document contains proprietary information of ZTE and is not to be disclosed or used ZTE CONFIDENTIAL: This document contains proprietary information of ZTE and is not to be disclosed or used without the prior written permission of ZTE.
without the prior written permission of ZTE.
Due to update and improvement of ZTE products and technologies, information in this document is subjected to Due to update and improvement of ZTE products and technologies, information in this document is subjected to change without notice.
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 ... ... ... 471
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
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
1.2.2
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
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 j ust like the CS service inter-RAT handover. The message fl ow 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 ndover 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 NodeB RNC PSCN 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)
Figure 1-2 Handover from GERAN to UMTS RANAP RANAP Relocation Request BSSMAP BSSMAP RANAP RANAP BSSMAP BSSMAP PS Handover Required Ack BSSMAP BSSMAP
BSSMAP Clear CompleteBSSMAP
RANAP RANAP Relocation Complete UE NodeB RNC PSCN 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 Enhancement No
1.2.4
ZWF21-03-024 DTM Handover
BenefitsThis feature guarantees the CS service continuity combined with PS service during Inter-RAT moving. It improves user experience.
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 Release Complete BSSMAP RANAP RANAP UE RNC CSCN PSCN BSC RRC RRC RR RR RANAP RANAP Iu Release Command RANAP RANAP Relocation Required Relocation Required BSSMAP BSSMAP BSSMAP 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 h andover Command)
Relocation Command Handover from UTRAN Command
( DTM h andover Command)
BSSMAP Handover Detect BSSMAP
BSSMAP Handover Detect
7 . Handover Complete
BSSMAP
BSSMAP Handover Complete
PS Handover Complete BSSMAP BSSMAP RANAP Iu Release Complete RANAP RANAP Iu Release Command RANAP BSSMAP Relocation
Figure 1-4 Handover from GSM to UMTS BSSMAP BSSMAP PS Handover Required RANAP RANAP Relocation Request Ack. BSSMAP BSSMAP PS Handover Required Ack
RANAPRelocation Complete RANAP
RRC Handover to UTRAN Complete RR C RR DTM Handover Command RR RANAP RANAP Relocation Detect
BSSMAP Handover Required BSSMAP
RANAPRelocation Request RANAP
RANAP Relocation Request RANAP
RANAP R ANAP
Relocation Request Ack.
BSSMAP Handover Command BSSMAP
RANAP RANAP
Relocation Detect
RANAPRelocation Complete RANAP
UE RNC CSCN PSCN 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
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
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 request voice 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 Connection
Voice Call Establishment Fallback to UMT S
(Reselect UMT S cell)
Paging paging
Figure 1-6 Procedure of CS Fallback to UMTS via redirection for RRC CONNECTED state
UE MME
Redirect to UMTS
Voice Service Request eNodeB
CS Fallback Indicator
RNC MSC
Voice Service Request or Paging response Data Service Ongoing
RRC C onnection
Voice Call Establishment CS Paging Notification
Case: Mobile Ter minal
Fallback to UM TS (Reselect UMT S 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.
Figure 1-7 Procedure of CS Fallback to UMTS via PS Handover
UE MME
Voice Service Request eNodeB
Handover from E-UTRAN to E-UTRAN
RNC SGSN
Voice Service Request or Paging response Data Service Ongoing
Handover Complete
Voice Call Establishment Fallback to UMTS
(Establish SRB and PS Traffic RB)
CS Paging Notification Case: Mobile Terminal
MSC
Handover Prepare
Handover Complete
Data Service Ongoing
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
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
UE eNodeBTarget
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 1-9 E-UTRAN to UTRAN Inter RAT HO
UE TargetRNC
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 acce ss 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.
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
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 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 codin g rates which can be adjusted by the RNC must bel ong 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.
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 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 NodeB Serving RNS Serving RNC CN RRC
RRC 7. DCCH : Radio Bearer Reconfiguration Complete
NBAP NBAP 4. Radio Link Reconfiguration Ready
NBAP NBAP 5. Radio Link Reconfigurat ion Commit
RRC
RRC 6. DCCH : Radio Bearer Reconfiguration
RANAP RANAP 8. RAB Assignment Response RANAP RANAP 2. RAB Assignment Request [Modification] NBAP
NBAP 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.
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 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
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.
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
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.
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
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 g roup of Node Bs connects to the same backup RNC. Different groups of Node Bs connect to different backup RNC. Each RNC in the pool co uld 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 RNC 1 RNC n RNC 2 RNC in Pool Node B Group 1 Node B Group 2 Node B Group 3 Core Network
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 data transport 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.
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.
The configuration of the static route can be configured manually by OMCR based on IP UNNUMBER technology which does not require the network interface to bind the IP address, but use an existing network interface IP to generate the route. This configuration of static route is applicable only to the P2P links. Its main advantage is to save IP address resources. Therefore, it is very applicable for IP over ATM and IP over E1/T1 of lub interface.
ZTE RAN equipment can configure different priority for each next-hop path. The load sharing of IP path is fulfilled based on priority between more next hops while packets are sent by route. Introduced Version U9.1&Before Enhancement No
2.1.3
ZWF22-03-003 DHCP
BenefitsThis feature supports all-IP networking mode with the IP address of Node B dynamically assigned through DHCP protocol, manual configuration of static IP address no longer essential, which reduces the workload of operation & maintenance.
Description
For IP transmission over Ethernet between RNC and Node B, or IP transmission over E1/T1 through PPP/MLPP, the RNC needs to dynamically assign IP address through the DHCP while Node B starts, which can be used to transfer both operation & maintenance data and the control plane and user plane data on Iub interface.
ZTE RAN equipment supports the DHCP procedure following the definition in the RFC2131 and RFC1542, which can be divided into three principal parts: Server, Client (defined in the RFC2131) and Relay (defined in the RFC1542). DHCP Server is used to allocate IP address of DHCP Client and configure local equipment. If DHCP Server and
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
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 scantling data 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
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 CN VLAN3 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 CN2 VLAN3 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
2.1.6
ZWF22-03-011 VLAN for Node B
Benefits
This feature supports dividing Node Bs and other equipments in the same physical network 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
CRC DA SA Type Data Standard Ethernet Frame Priority (4bits) TCI TCI
DA SA tag Type Data
TPID (0x8100) CFI (1bit) VLAN ID (12bits) TCI TCI
Ethernet Frame with IEEE802.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
− 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
BenefitsThis 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.
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
BenefitsThis feature provides differentiated handling priority for different service classes, to ensure the QoS of different service classes.
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
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
BenefitsThis 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.
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.
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 tunneling technology. 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
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 E1 HDLC PPP HDLC PPP MLPPP/MCPPP HDLC PPP
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
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
BenefitsThis 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
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
BenefitsThis 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 netw ork, 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
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 <= 20ms
− Transport delay variation <=7ms
− Frame loss rate <=0.05%
ZTE also supports clock synchronization from the switch via IEEE 1588 protocol. The switch serves as Master that provides high #precision clock; the Node B serves as Slave
that extracts the clock information and performs the clock synchronization to avoid the delay and the jitter generated by the complex transport network. The typical network architecture is shown below.
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
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.
Table 3-1 HSDPA UE Category Supported by ZTE current version Category Max. No. of HS-DSCH Codes Min. Inter-TTI Interval Supported Modulations Supported carrier Number MIMO Operation MAC Layer Peak Bit Rate 1 5 3 QPSK/16QAM 1 N/a 1.2Mbps 2 5 3 QPSK/16QAM 1 N/a 1.2Mbps 3 5 2 QPSK/16QAM 1 N/a 1.8Mbps 4 5 2 QPSK/16QAM 1 N/a 1.8Mbps 5 5 1 QPSK/16QAM 1 N/a 3.6Mbps 6 5 1 QPSK/16QAM 1 N/a 3.6Mbps 7 10 1 QPSK/16QAM 1 N/a 7.2Mbps 8 10 1 QPSK/16QAM 1 N/a 7.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 16 15 1 QPSK/16QAM 1 Activated 27.9Mbps 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 20 15 1 QPSK/16QAM/64QAM 1 Activated 42.2Mbps 21 15 1 QPSK/16QAM 2 N/a 23.4Mbps 22 15 1 QPSK/16QAM 2 N/a 28.0Mbps 23 15 1 QPSK/16QAM/64QAM 2 N/a 35.3Mbps 24 15 1 QPSK/16QAM/64QAM 2 N/a 42.2Mbps 25 15 1 QPSK/16QAM 2 Activated 46.7Mbps 26 15 1 QPSK/16QAM 2 Activated 56.0Mbps
Category Max. No. of HS-DSCH Codes Min. Inter-TTI Interval Supported Modulations Supported carrier Number MIMO Operation MAC Layer Peak Bit Rate 27 15 1 QPSK/16QAM/64QAM 2 Activated 70.6Mbps 28 15 1 QPSK/16QAM/64QAM 2 Activated 84.4Mbps
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.
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.
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 RAN
equipments 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.
