eLTE3.1.x Broadband Trunking Solution Feature Description
Issue 03
Date 2014/06/19
HUAWEI TECHNOLOGIES CO., LTD.
Copyright © Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: [email protected]
Contents
Contents
Contents ....................................................................................................................................... ii
1 Introduction .............................................................................................................................. 1
2 Description ................................................................................................................................ 2
2.1 TTRFD0101 Private Call ....................................................................................................................................... 2
2.2 TTRFD0102 12.2k AMR Voice .............................................................................................................................. 3
2.3 TTRFD0103 4.75k AMR Voice .............................................................................................................................. 4
2.4 TTRFD0110 Point to Point Video Call ................................................................................................................... 4
2.5 TTRFD0201 Trunking Group Call ......................................................................................................................... 5
2.6 TTRFD0202 Emergency Call................................................................................................................................. 6
2.7 TTRFD0121 Ultra-High-Speed Uplink PS Service ................................................................................................. 7
2.8 TTRFD0122 Ultra-High-Speed Downlink PS Service ............................................................................................ 8
2.9 TTRFD0123 High-Speed PS Service ..................................................................................................................... 8
2.10 TTRFD0131 Internet Access Service.................................................................................................................... 9
2.11 TTRFD0124 Short Data Service ..........................................................................................................................10
2.12 TTRFD0125 Video Surveillance ......................................................................................................................... 11
2.13 TTRFD0126 Portable Terminal Video Sending ....................................................................................................12
2.14 TTRFD0127 Video Projection .............................................................................................................................12
2.15 TTRFD0128 Video Distribution ..........................................................................................................................13
2.16 TTRFD0129 Combined Services Collaboration ...................................................................................................13
2.17 TTRFD0130 GIS Service ....................................................................................................................................14
2.18 TTRFD0132 Status Message ...............................................................................................................................15
2.19 TTRFD0141 Video Enhancement........................................................................................................................16
2.19.1 TTRFD014101 Video Transcoding ...................................................................................................................16
2.20 TTRFD0181 Simultaneous Transmission of PS Services and Group Call .............................................................17
2.21 TTRFD0182 Simultaneous Transmission of PS Services and Point-to-Point Call .................................................17
2.22 TTRFD0211 Group Call Scanning ......................................................................................................................18
2.23 TTRFD0212 Call Floor Release ..........................................................................................................................19
2.24 TTRFD0213 Floor Pre-emption ..........................................................................................................................19
2.25 TTRFD0215 Later Entry .....................................................................................................................................20
2.26 TTRFD0216 Forced Release ...............................................................................................................................21
2.27 TTRFD0217 Time-Limited Call ..........................................................................................................................21
2.28 TTRFD0218 Group and User Status Display .......................................................................................................22
Contents
2.29 TTRFD0219 Alias Display of Group and User ....................................................................................................23
2.30 TTRFD0220 Broadcast Call ................................................................................................................................24
2.31 TTRFD0221 Dynamic Regrouping .....................................................................................................................25
2.32 TTRFD0222 Call Forwarding .............................................................................................................................25
2.33 TTRFD0223 Call Data Record ............................................................................................................................26
2.34 TTRFD0225 Temporary Group Call ....................................................................................................................27
2.35 TTRFD0226 Talking Party Identification ............................................................................................................28
2.36 TTRFD0227 Forced Preemption .........................................................................................................................29
2.37 TTRFD0241 Barring of Incoming and Outgoing Calls.........................................................................................30
2.38 TTRFD0271 Discreet Listening ..........................................................................................................................31
2.39 TTRFD0291 Remotely Enable/Disable Terminal .................................................................................................32
2.40 TTRFD0301 Operating Bandwidth .....................................................................................................................32
2.40.1 TTRFD030101 5M/10M/20M System Bandwidth ............................................................................................32
2.40.2 TTRFD030102 3 MHz System Bandwidth .......................................................................................................33
2.41 TTRFD0302 Modulation Mode ...........................................................................................................................34
2.41.1 TTRFD030201 DL/UL QPSK ..........................................................................................................................34
2.41.2 TTRFD030202 DL/UL 16QAM .......................................................................................................................34
2.41.3 TTRFD030203 DL 64QAM .............................................................................................................................35
2.41.4 TTRFD030204UL 64QAM ..............................................................................................................................36
2.41.5 TTRFD030205AMC ........................................................................................................................................36
2.42 TTRFD0308 MIMO ...........................................................................................................................................37
2.43 TTRFD0310 TTI Bundling .................................................................................................................................38
2.44 TTRFD0321 Idle Resource Management ............................................................................................................39
2.45 TTRFD0322 Dynamic Group Resource Allocation and Release ...........................................................................40
2.46 TTRFD0324 Admission Control .........................................................................................................................41
2.47 TTRFD0325 Power Control ................................................................................................................................42
2.48 TTRFD0326 Load Control ..................................................................................................................................44
2.49 TTRFD0327 Mobility Management ....................................................................................................................45
2.49.1 TTRFD032701 Coverage-based Intra-Frequency Handover ..............................................................................45
2.49.2 TTRFD032702 Coverage-based Inter-Frequency Handover ..............................................................................47
2.49.3 TTRFD032703 Cell Selection and Reselection .................................................................................................48
2.50 TTRFD0328 High Velocity Algorithm ................................................................................................................48
2.51 TTRFD0341 QoS Management ...........................................................................................................................49
2.52 TTRFD0342 High QoS Management ..................................................................................................................54
2.53 TTRFD0361 Interference Control .......................................................................................................................57
2.53.1 TTRFD036101 IRC .........................................................................................................................................57
2.53.2 TTRFD036103 ICIC ........................................................................................................................................58
2.53.3 TTRFD036104 Inter-RAT Interference Avoiding ..............................................................................................59
2.54 TTRFD0370 BeamForming ................................................................................................................................59
2.55 TTRFD0371 TDD Ultra-long-distance Coverage ..............................................................................................61
2.56 TTRFD0381 RRU Topology ...............................................................................................................................62
2.56.1 TTRFD038101 RRU Star Topology .................................................................................................................62
Contents
2.56.2 TTRFD038102 RRU Chain Topology ..............................................................................................................63
2.57 TTRFD0382 RRU Combination..........................................................................................................................64
2.57.1 TTRFD038201Multi-RRU Combination ..........................................................................................................64
2.57.2 TTRFD038202 Multi-RRU Combination in an Indoor Distributed System ........................................................65
2.58 TTRFD0383 Remotely Installed RRU .................................................................................................................66
2.59 TTRFD0385 VPN...............................................................................................................................................67
2.59.1 TTRFD038501 Voice Service VPN ..................................................................................................................67
2.59.2 TTRFD038502 Packet Service VPN.................................................................................................................68
2.60 TTRFD0386 Hierarchical Networking ................................................................................................................69
2.61 TTRFD0387 Routing Behind MS........................................................................................................................72
2.62 TTRFD0401 Audio and Video Recording ............................................................................................................73
2.63 TTRFD0402 Charging ........................................................................................................................................74
2.63.1 TTRFD040201 PS Charging ............................................................................................................................74
2.64 TTRFD0403 Roaming ........................................................................................................................................75
2.64.1 TTRFD040301 PS Roaming ............................................................................................................................75
2.65 TTRFD0404 Service Identification by SPI ..........................................................................................................76
2.66 TTRFD0501 Interworking with PSTN ................................................................................................................77
2.67 TTRFD0502 Interworking with TETRA..............................................................................................................78
2.68 TTRFD0503 Interworking with PLMN ...............................................................................................................78
2.69 TTRFD0504 Interworking with USW/SW Radio Station and 350 MHz MPT1327 Users .....................................79
2.70 TTRFD0505 SIP Interface ..................................................................................................................................80
2.71 TTRFD0601 Communication From Immobility...................................................................................................80
2.72 TTRFD0602 Communication on the Move..........................................................................................................81
2.73 TTRFD0603 Switch Between Communication From Immobility and Communication on the Move by One Click 82
2.74 TTRFD0651 Dispatching Console API SDK .......................................................................................................82
2.75 TTRFD0652 Terminal Further Development based Portable Handset ...................................................................83
2.76 TTRFD0653 Terminal Further Development based EM350 .................................................................................85
2.77 TTRFD0701 IP Transmission ..............................................................................................................................86
2.78 TTRFD0801 Authentication ................................................................................................................................87
2.79 TTRFD0802 Air Interface Data Encryption .........................................................................................................89
2.80 TTRFD0803 End-to-End Encryption ...................................................................................................................89
2.80.1 TTRFD080301 Group call Encryption..............................................................................................................89
2.80.2 TTRFD080302 Point to Point Call Encryption..................................................................................................90
2.80.3 TTRFD080303 Short Data Service Encryption .................................................................................................91
2.81 TTRFD0804 Integrity Protection.........................................................................................................................91
2.82 TTRFD0901 FlowControl ...................................................................................................................................93
2.83 TTRFD0903 CN Reliability ................................................................................................................................93
2.83.1 TTRFD090301 CN Board Redundancy ............................................................................................................93
2.83.2 TTRFD090302 S1-flex ....................................................................................................................................95
2.83.3 TTRFD090303 CN Geographical Redundancy .................................................................................................96
2.84 TTRFD0904 NodeB Reliability ..........................................................................................................................98
2.84.1 TTRFD090401 Single RRU Cold Ring Backup ................................................................................................98
Contents
2.84.2 TTRFD090402 NodeB board Redundancy .......................................................................................................99
2.84.3 TTRFD090403 Fallback Mode ....................................................................................................................... 100
2.85 TTRFD0905 Direct Mode Operation(DMO) ..................................................................................................... 102
2.85.1 TTRFD090501 Analog DMO ......................................................................................................................... 102
2.86 TTRFD0906 System Antivirus .......................................................................................................................... 104
2.87 TTRFD0907 OMC Geographical Redundancy .................................................................................................. 104
2.88 TTRFD0908 Dispatching System Geographical Redundancy ............................................................................ 105
2.89 TTRFD1001 BWA-based Terminal Management............................................................................................... 106
2.89.1 System Function ............................................................................................................................................ 107
2.89.2 Automatic Terminal Detection and Network Access ........................................................................................ 108
2.89.3 Terminal Topology Displayed in a Table ......................................................................................................... 109
2.89.4 Full-Configuration Delivery Management ...................................................................................................... 110
2.89.5 Command Delivery in Online Mode ............................................................................................................... 110
2.89.6 Software Upgrade in Batches ......................................................................................................................... 111
2.89.7 Remote Restart in Batches ............................................................................................................................. 112
2.89.8 Factory Defaults Restore in Batches ............................................................................................................... 112
2.89.9 Remote Commissioning in Batches ................................................................................................................ 113
2.89.10 Terminal Log Collection .............................................................................................................................. 113
2.90 TTRFD1002 Portable Terminal Management .................................................................................................... 114
2.90.1 Software Package, Configuration File Package Management .......................................................................... 114
2.90.2 Software Package Download .......................................................................................................................... 115
2.90.3 Configuration File Package Download ........................................................................................................... 116
2.90.4 OTA-based Download Report Query .............................................................................................................. 117
2.91 TTRFD1003 Performance Management ............................................................................................................ 118
2.92 TTRFD1004 Alarm Management ...................................................................................................................... 121
2.93 TTRFD1005 Configuration Management .......................................................................................................... 122
2.94 TTRFD1006 Call Tracing ................................................................................................................................. 122
2.95 TTRFD1007 Log Management ......................................................................................................................... 127
2.96 TTRFD1008 Software Management .................................................................................................................. 127
2.97 TTRFD1009 Network Preventive Maintenance ................................................................................................. 128
2.98 TTRFD1010 Remote Maintenance Information Collection ................................................................................ 130
2.99 TTRFD1021 Subscriber Subscription Data Management ................................................................................... 131
2.100 TTRFD1022 Remote Management on Subscription Data ................................................................................. 132
2.101 TTRFD1031 Multi-Language.......................................................................................................................... 133
2.101.1 TTRFD103101 Chinese and English Support ............................................................................................... 133
2.101.2 TTRFD103102 Other Languages Support besides Chinese&English .......................................................... 134
2.102 TTRFD1041 Driving Test ............................................................................................................................... 134
2.103 TTRFD2001 400MHz OffLine Frequency Scan .............................................................................................. 135
2.104 TTRFD2002 WIFI Console ............................................................................................................................. 136
A Acronyms and Abbreviations ............................................................................................ 137
1 Introduction
This document describes the features supported in eLTE 3.1.x.
It is intended for customers and Huawei technical support engineers and can be referenced for
ES, services, and solution tests.
2
2 Description
2.1 TTRFD0101 Private Call
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables private calls (also called one-to-one selective calls or P2P calls) between
trunking users or between trunking users and dispatching console users. Private calls are in
point-to-point full-duplex mode, which ensures that only the two parties in a private call can
hear each other.
Benefits
With this feature in the broadband multi-media trunking system, multiple users on the
network can make private calls with each other.
Description
This feature is enabled for registered users by default.
The calling party can dial the number of another user to make a full-duplex call. The system
administrator can enable or disable private calls for users.
P2P voice users support voice calls in full-duplex mode, and therefore trunking users and
dispatching console users can easily initiate private calls. When a call is answered, the system
allocates radio resources for this call.
This feature applies to the following scenarios:
Emergency calls. The user can call the dispatch person without the need to dial the
number.
Voice intercom. P2P voice calls can be made between the dispatch person and common users, or between common users.
Enhancement
None
3
Dependencies
None
2.2 TTRFD0102 12.2k AMR Voice
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature uses the AMR three-substream policy for transmission over the air interface, and
VoIP for transmission between the network side (eNodeB and EPC) and scheduler. AMR is
short for Adaptive Multirate.
The RTP/UDP/IP bearer is used for transmission on the network side, and VoIP is used for
transmission between the eNodeB and other switching gateways. During transmission, the
dispatching console must convert the voice coding format. RTP is short for Real-Time
Transport Protocol, and UDP is short for User Datagram Protocol.
RTP terminates on the eNodeB and scheduler. At layer 2, the eNodeB implements some RTP
functions such as packet loss detection, buffer, and jitter cancellation.
Benefits
This feature increases the air interface resource utilization, enhances the group quantity and
capacity in a group, and therefore improves competitiveness.
Description
The eNodeB processes VoIP packets and AMR three-substream packets as follows:
In the uplink, the eNodeB removes the headers of PDCP packets, adds RTP headers using the
PDCP serial numbers, packs the PDCP packets into the GTP-U packets, and then sends them
to the EPC. In this way, sequential transmission of uplink voice packets is guaranteed. PDCP
is short for Packet Data Convergence Protocol. GTP-U is short for GPRS Tunneling
Protocol-User Plane.
In the downlink, the eNodeB obtains AMR+RTP from GTP-U packets sent by the EPC,
implements packet loss detection, buffer, and jitter cancellation based on RTP, packs AMR
into the PDCP packets and then sends them at an interval of 20 ms. In this way, the eNodeB
can guarantee data transmission sequence and prevent jitter over the air interface.
Enhancement
None
Dependencies
This feature requires that UEs support AMR packets.
4
2.3 TTRFD0103 4.75k AMR Voice
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports AMR three-substream transmission at 4.75 kbit/s.
The RTP/UDP/IP bearer is used for transmission between the network side and scheduler.
Benefits
This feature increases the air interface resource utilization, enhances the group and P2P call
quantities and coverage of eNodeBs, and therefore improves competitiveness.
Description
Different voice rates apply to different voice packet header fields. To process uplink data, the
eNodeB fills in the voice header field for the speaker in a P2P call based on the service type.
To process downlink data, the eNodeB removes the headers of RTP voice packets, and sends
AMR three-substream packets with bytes aligned.
The following details the procedure:
In the uplink, the eNodeB removes the headers of PDCP packets, adds RTP headers using the
PDCP serial numbers, packs the PDCP packets into the GTP-U packets, and then sends them
to the EPC. In this way, sequential transmission of uplink voice packets is guaranteed.
In the downlink, the eNodeB obtains AMR+RTP from GTP-U packets sent by the EPC,
implements packet loss detection, buffer, and jitter cancellation based on RTP, packs AMR
into the PDCP packets and then sends them at an interval of 20 ms. In this way, the eNodeB
can guarantee data transmission sequence and prevent jitter over the air interface.
Enhancement
None
Dependencies
This feature requires that the UE, eNodeB, EPC, and scheduler support 4.75 kbit/s AMR
voice packets.
2.4 TTRFD0110 Point to Point Video Call
Availability
This feature was introduced in eLTE 3.1.1.
5
Summary
This feature supports video calls between handset terminals.
Benefits
This feature meets requirements for video calls.
Description
The two parties can engage in video calls.
Enhancement
None
Dependencies
None
2.5 TTRFD0201 Trunking Group Call
Availability
This feature was introduced in eLTE 3.1.1.
Summary
A group call is point-to-multipoint call between a UE and multiple independent dispatching
consoles. The working mode is half-duplex without pickup, and the EPC authenticates the
floor to users. In most cases, the group calling party has the floor. If a user attempts to
preempt the floor, the EPC checks the priority first. If the priority is low, the EPC rejects the
attempt. During a group call, only dispatching console or originator can terminate the call.
Benefits
This feature covers the basic functions of trunking communication.
Description
This feature includes the following basic functions:
Group establishment
− An enterprise user presses the push to talk (PTT) button on the terminal to initiate
group establishment. Then, the eCNS210 or eSCN230 allocates resources to this
group and notifies all the users in this group. The originator can initiate a call; the
other users can listen to this group and preempt the floor.
− The dispatching console can also initiate group establishment. In this situation, the dispatching console functions as a group terminal.
Although the dispatching console has more rights, the functions involved in this feature are the same.
6
Floor application
After a group is established, the users in this group can press the PTT button on the
terminal to apply for the floor. High-priority users can preferentially obtain the floor.
User priorities are classified into 0 to 15, among which 0 indicates the highest priority. User priorities 1 to 15 are configurable and user priority 0 is not configurable.
Floor release
A user uses the floor with a time limit. The floor is released in the following scenarios:
The user actively releases the floor.
The speaker is unconditionally terminated when the call duration is beyond the specified limit.
A low-priority user has the floor and a high-priority user initiates floor preemption.
Group joining
A user can subscribe to multiple groups but can listen to only one group or act as the
speaker only in one group. Before listening to or using a group, the user must join the
group. Then, the EPC dynamically allocates resources for the user.
Each group has its priority. Group priorities are classified into 0 to 15, among which 0
indicates the highest priority. When a higher-priority group is established and it has been
added to the scan list of a user, the user automatically joins this group to ensure
transmission of higher-priority messages. If all groups have the same priority, the user has the rights to join the favorite group.
Group closing
A group is closed when the call duration is beyond the specified limit or when the
dispatching console requires group closing. In this way, the EPC guarantees smoothness
of group establishment and running, and the minimal delay. A group can also be closed
by the originator.
Enhancement
None
Dependencies
None
2.6 TTRFD0202 Emergency Call
Availability
This feature was introduced in eLTE 3.1.1 and was enhanced in eLTE 3.1.1.
Summary
Emergency calls have the highest priority. With this feature, information is reported to
predefined users promptly.
Benefits
This feature facilitates command and dispatch in emergencies.
7
Description
The major functions involved in this feature are as follows:
When configuring a group list, the system can also configure an emergency call type and emergency call number.
− If the emergency call type is P2P, the emergency call number corresponds to a called terminal or dispatching console.
− If the emergency call type is group, the emergency call number corresponds to a
group that the user subscribes to. The emergency group call is not displayed on the
terminal interface. If there is no emergency call number, the emergency group call is the active group.
P2P emergency call from the terminal to the dispatch person: The user directly calls the dispatch person to report the emergency.
P2P emergency call between users: The user directly calls the specified user to report the
emergency.
Emergency call in a specified subscription group: The user initiates group establishment by making an emergency call that has the highest priority (0) on the RAN.
Floor preemption: The user originating an emergency call preempts the floor when the emergency group call is active.
Enhancement
In eLTE 3.1.1, this feature was enhanced as follows:
Supports emergency calls in an active group.
Supports preemption of emergency P2P calls which can interrupt common voice services
on the called party.
Dependencies
This feature requires TTRFD0101 Private Call and TTRFD0201 Trunking Group.
2.7 TTRFD0121 Ultra-High-Speed Uplink PS Service
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports an uplink rate of 2 Mbit/s or higher for single users and provides high
definition (HD) video transmission.
Benefits
Users can enjoy ultra-high-speed uplink PS services such as HD video transmission.
8
Description
An uplink rate of 2 Mbit/s or higher is allowed for single users, and ultra-high-speed uplink
transmission is supported.
Enhancement
None
Dependencies
None
2.8 TTRFD0122 Ultra-High-Speed Downlink PS Service
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports a downlink rate higher than 2 Mbit/s for single users and provides HD
video transmission.
Benefits
Users can enjoy ultra-high-speed downlink PS services such as HD video transmission.
Description
A downlink rate higher than 2 Mbit/s is allowed for single users, and ultra-high-speed
downlink transmission is supported.
Enhancement
None
Dependencies
None
2.9 TTRFD0123 High-Speed PS Service
Availability
This feature was introduced in eLTE 3.1.1.
9
Summary
This feature enables the data rates between 512 kbit/s and 2 Mbit/s.
Benefits
This feature meets requirements for rate-sensitive multimedia services such as transmission of
videos, large-size images, and music.
Description
A rate between 512 kbit/s and 2 Mbit/s is allowed for single users in the uplink and downlink.
Enhancement
None
Dependencies
None
2.10 TTRFD0131 Internet Access Service
Availability
This feature was introduced in eLTE 3.1.1
Summary
The eOMC/eAPP can serve as a DNS server. The CN provides configurations of the DNS server and sends the configurations to UEs initiating network access through signaling messages.
Benefits
During the access, a UE can automatically obtain the DNS server IP address configured on the CN. This provides support for OTA domain name access.
Description
The IP addresses of the primary and secondary DNS servers are configured on the CN side.
The eOMC/eAPP provides the DNS server function to implement local resolution of private domain names and DNS forwarding for non-local domain names.
The UE includes the DNS server request in the protocol configuration option (PCO) in
the access signaling, and the CN sends the UE the DNS server IP address through a
response signaling message.
If the DNS server IP address configured on the CN is that of the eOMC/eAPP, the UE can visit the network using the private OTA domain name or external domain names.
10
Enhancement
None
Dependencies
None
2.11 TTRFD0124 Short Data Service
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports short messages (SMs) and multimedia messages between enterprise
users.
Benefits
This feature meets requirements for SMs and multimedia messages between enterprise users.
Description SM services
a. P2P and point-to-group SMs are supported between terminals, between the
dispatching console and terminals, and between dispatching consoles.
The size of an SM is 1000 bytes. A maximum of 900 English letters can be entered and 300 non-English letters can be entered.
b. The dispatching console can save and export all messages that have been sent and
received. When the total SM size reaches the storage limit, a message will be displayed, indicating that the memory is full.
c. Offline SMs are supported and can be stored for 48 hours. The server buffers the
offline SMs and automatically sends them once the handset terminal gets online.
d. The dispatching console and terminal support a maximum of 100 preset SMs, which are editable.
e. Predefined and emergency SMs are supported.
Multimedia services
a. P2P and point-to-group multimedia messages are supported between terminals,
between the dispatching console and terminals, and between dispatching consoles.
Multimedia messages can be images, voice, text,vedio chip or file.
The size of a multimedia message attachment is no more than 2 M Bytes.
b. The dispatching console can save and export all multimedia messages that have
been sent and received. When the total multimedia message size reaches the storage
limit, a message will be displayed, indicating that the memory is full.
11
c. Offline multimedia messages are supported and can be stored for 48 hours. The
server buffers the offline multimedia messages and automatically sends them once the handset terminal gets online.
Enhancement
None
Dependencies
None
2.12 TTRFD0125 Video Surveillance
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports fixed video surveillance and mobile video surveillance.
Benefits
The dispatching console can use a camera to perform fixed video surveillance while users can
use handset terminals to perform mobile video surveillance on a wireless network.
Description
This feature provides the following functions for the dispatching console and handset
terminals:
Video surveillance and check on fixed cameras or other types of terminal
Voice surveillance on voice equipment to which the fixed cameras are attached or bound
Audio monitoring on other types of terminal
Enhancement
None
Dependencies
None
12
2.13 TTRFD0126 Portable Terminal Video Sending
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports video Feedback on a handset terminal.
Benefits
This feature meets requirements for real-time video Feedback.
Description
Videos can be transmitted to the dispatching console from the handset terminal through a backhaul over the LTE wireless network. Only handset terminal can initiate
video Feedback, and sound can be enabled or disabled based on customer requirements.
Enhancement
None
Dependencies
None
2.14 TTRFD0127 Video Projection
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports video display on Screen.
Benefits
The feature has a large screen, optimum resolution and wide visual range.
Description
The dispatching console can enable this feature for active video Feedback services.
Enhancement
None
13
Dependencies
None
2.15 TTRFD0128 Video Distribution
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports video distribution by the dispatching console to a specified terminal.
Benefits
This feature meets requirements for video content scheduling.
Description
The dispatching console can send one line of video to one or multiple specified terminals
(including various display entities such as dispatching console, handset terminal). The user
can play the received video and choose to enable or disable sound.
Enhancement
None
Dependencies
None
2.16 TTRFD0129 Combined Services Collaboration
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports concurrence of video services and voice services.
Benefits
Concurrence of voice calls and videos significantly enhances user experience.
14
Description Video P2P calls cannot be concurrent with other types of calls (including voice P2P calls,
group calls, and non-video P2P calls).
Video Feedback, video distribution, video surveillance can be concurrent with non-video calls (including voice P2P calls and group calls).
All video services (including video Feedback, distribution, surveillance, and P2P calls) cannot be concurrent.
Enhancement
None
Dependencies
None
2.17 TTRFD0130 GIS Service
Availability
This feature was introduced in eLTE 3.1.1.
Summary
With this feature, mobile terminals can report real-time geographic information system (GIS)
location data on a trunking enterprise network, and the dispatching console can display the
GIS location data.
Benefits
This feature meets requirements for real-time GIS location and GIS-location-based scheduling
for enterprise users.
Description
Functions on handset terminals:
1. A handset terminal can enable or disable GPS location according to the command from the dispatching console.
2. A handset terminal can report GPS data triggered by specific events (such as emergency calls). If this function is used, the handset terminal automatically enables GPS location.
3. If GPS satellite searching fails, the handset terminal reports the fault to the dispatching
console.
GIS service:
4. On the e-map, the handset terminal status can be displayed when:
GPS data reporting is enabled.
Satellite searching fails.
GPS data reporting is disabled.
15
NO register
5. If satellite searching fails or GPS data reporting is disabled, the e-map will display the
latest GPS location and update time.
6. A handset terminal can be located on the e-map, including the status, location, and direction.
7. For the devices without a GPS module (such as cameras), users can manually configure GPS data.
8. The e-map can display the location of a camera.
9. The e-map supports layer control. Users can choose objects to display on the e-map.
10. Users can set the period of reporting GPS location updates to 1s, 2s,5s, 15s, 30s, or 60s. The default period is 30s.
E-map-based service correlation:
The other functions supported on the e-map are handset terminal-triggered video surveillance,
video distribution, P2P video calls, P2P voice calls, and SMs.
Enhancement
None
Dependencies
This feature requires TTRFD0124 Short Data Service.
2.18 TTRFD0132 Status Message
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables handset terminals to report their own status (busy, idle, etc…) to network.
Benefits
With this feature, terminal users can deliver their own status to the network, and the network
can send the status message to dispatch console to present more precise user status on GUI.
Interface.
Description
Status message configuration can be flexibly customized by network
Status message configuration can be pushed to all terminal users and dispatching consoles.
Status message configuration can be fetched from network, when a terminal or dispatching console starts up.
16
Terminal binds each key buttons with different status message. When user press specific
terminal button, the corresponding status message will be sent to the network.
Enhancement
None
Dependencies
TTRFD0124 Short Data Service.
2.19 TTRFD0141 Video Enhancement
2.19.1 TTRFD014101 Video Transcoding
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature transcodes video streams from high resolution to low resolution in real time.
Benefits
This feature enables users to watch real-time videos with a handset terminal, reduces
requirements for radio bandwidth, and increases radio resource efficiency.
Description
This feature can transcode videos from formats of 1080P, 720P, and D1 to the CIF format in
real time, including the videos uploaded from a handset terminal and those captured from a
fixed video camera.
This feature can transcode videos from formats of 1080P, 720P, and D1 to the CIF format in
real time, including the videos uploaded from a handset terminal and those captured from a
fixed video camera. During video distribution, the dispatching person can transcode the video
streams to be distributed to reduce consumption of the air interface bandwidth.
The encoding and decoding format is H.264.
Enhancement
None
Dependencies
This feature requires TTRFD0128 Video Distribution.
17
2.20 TTRFD0181 Simultaneous Transmission of PS Services and Group Call
Availability
This feature was introduced in eLTE 3.1.1 and enhanced in eLTE 3.1.1.
Summary
This feature enables packet switched (PS) services and group services to be transmitted
simultaneously.
Benefits
This feature enables users to simultaneously perform PS services and group services.
Description
This feature enables PS services and group services to be transmitted simultaneously. A
maximum of eleven bearers can be set up for a single UE: one default bearer and ten
dedicated bearers. The default bearer is a data bearer.
Enhancement
None
Dependencies
None
2.21 TTRFD0182 Simultaneous Transmission of PS Services and Point-to-Point Call
Availability
This feature was introduced in eLTE 3.1.1 and enhanced in eLTE 3.1.1.
Summary
This feature enables PS services and point-to-point (PTP) CS services to be transmitted
simultaneously.
Benefits
This feature enables users to simultaneously perform PS services and PTP CS services.
18
Description
This feature enables PS services and PTP CS services to be transmitted simultaneously. A
maximum of eleven bearers can be set up for a single UE: one default bearer and ten
dedicated bearers. The default bearer is a data bearer.
Enhancement
None
Dependencies
None
2.22 TTRFD0211 Group Call Scanning
Availability
This feature was introduced in eLTE 3.1.1.
Summary
With this feature, users can expand the scope of groups to be listened to.
Benefits
This feature enables users to listen to calls in its own group and other groups.
Description A maximum of 20 scanning groups can be configured on a UE.
If a group that is disabled does not have the lowest priority, the UEs in the group will select and then listen to the group with the highest priority in the remaining groups.
The UE can only scan the groups in which it is registered.
During the scanning, groups with higher priorities can preempt resources of groups with lower priorities.
The scanning function can be enabled or disabled on the UE.
The UE can receive calls only from the specified groups if the scanning function is not
enabled.
Enhancement
None
Dependencies
This feature requires TTRFD0201 Trunking Group.
19
2.23 TTRFD0212 Call Floor Release
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables the speaker to initiate a floor release in a group call.
Benefits
This feature enables the speaker to initiate a floor release.
Description
This feature enables the speaker to initiate a floor release in a group call. To release the floor,
the UE sends a non-access stratum (NAS) message to the network to request the dispatching
system to release the floor. After the dispatching system receives the message, it informs the
network to release the floor. The network then releases the UL voice resources allocated to the
speaker.
After the floor is released, the floor becomes idle.
Enhancement
None
Dependencies
This feature requires TTRFD0201 Trunking Group.
2.24 TTRFD0213 Floor Pre-emption
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables UEs to preempt the floor based on their priorities.
Benefits
This feature enables UEs to preempt the floor based on their priorities.
Description
This basic enables UEs to preempt the floor based on their priorities after a group call is set
up.
20
When a UE applies for the floor but the speaker already exists, the dispatching system
compares the priority of the UE applying for the floor with that of the speaker.
If the speaker has a lower priority, the dispatching system releases the floor and allocates it to
the UE applying for the floor. If the speaker has a higher priority, the dispatching system does
not release the floor. During the floor release, the UL voice resources of the former speaker
are also released. The former speaker then becomes a listener.
Enhancement
None
Dependencies
This feature requires TTRFD0201 Trunking Group.
2.25 TTRFD0215 Later Entry
Availability
This feature was introduced in eLTE 3.1.1.
Summary
When a group call is being set up, some UEs cannot join the group call due to certain reasons.
This feature enables these UEs to join the group call within a short period after the group call
is set up.
Benefits
UEs that do not join a group call when the call is being set up can join the group call within a
short period after the group call is set up.
Description
When the group call is being set up, some UEs cannot join the group call due to the following
causes:
The UEs are not powered on.
The UEs are in another group call with the same or higher priority.
The UEs are in an area where signals are fading.
During a group call is active, the eNodeB periodically sends messages containing group IDs
to UEs that have enabled the group call function on the paging channel. When a UE that did
not join the group call detects the messages, it joins the group call through the corresponding
service channel so late entry is realized.
Enhancement
None
21
Dependencies
This feature requires TTRFD0201 Trunking Group.
2.26 TTRFD0216 Forced Release
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables an authorized dispatching console to release a PTP call.
Benefits
With this feature, resources can be temporarily released and emergency calls can be
performed.
Description This feature enables an authorized dispatching console to release a PTP call.
A group call can be released manually by using the dispatching console.
An authorized dispatching console can forcibly join a PTP call to preempt resources of an UE and release the resources allocated to the UE.
Enhancement
None
Dependencies
This feature requires TTRFD0101 Private Call and TTRFD0201 Trunking Group.
2.27 TTRFD0217 Time-Limited Call
Availability
This feature was introduced in eLTE 3.1.1.
Summary
With this feature, the call duration of the speaker in a group call, a private call, and call
interconnection can be configured. When duration reaches the limit, the call will be
interrupted.
The call duration of the speaker in each group call can be configured on UEs. The call
duration of each UE in private call or call interconnection services is globally configured on the entire network.
22
When the call duration exceeds the limit, the floor is released. The procedure is as follows:
1. The call durations of group calls, private calls, and interconnection calls are configured
2. When the call duration exceeds the limit, the floor is released.
Benefits
Call duration can be controlled.
Description Time-controlled group calls
The call duration of the speaker in each group call can be configured on UEs.
When a group call is set up and the speaker obtains the floor, the call duration begins. If
the call duration of the speaker exceeds the limit, the floor is forcibly released. After the
call duration of the speaker exceeds the limit, the group call is still in the active state and other users in the group call can perform operations.
Time-controlled PTP calls
The call duration can be configured for PTP private calls and PSTN call interconnection services.
When the call duration exceeds the limit, the call is forcibly released. When the
time-controlled PTP call function is enabled, users can still initiate a PTP call or a group call.
Enhancement
None
Dependencies
Time-controlled group calls require TTRFD0201 Trunking Group.
Time-controlled PTP calls require TTRFD0101 Private Call.
2.28 TTRFD0218 Group and User Status Display
Availability
This feature was introduced in eLTE 3.1.1.
Summary
With this feature, the dispatch person can check whether a UE is online, in the idle state, in a
PTP call, in the listening state, or in the speaking state.
Benefits
This feature is used to identify whether a UE is listening by querying its status.
23
Description
The dispatch person can select a UE to query its online status and the status of the group to
which the UE belongs.
Enhancement
None
Dependencies
This feature requires TTRFD0201 Trunking Group.
2.29 TTRFD0219 Alias Display of Group and User
Availability
This feature was introduced in eLTE 3.1.1.
Summary
With this feature, UEs can check the group name and the speaker name during a call.
Benefits
In a group call, the group name and speaker name are displayed, making the group call
function easy to use.
Description Group name display
The group name is displayed on the UE when a group call is being set up and during the group call.
Speaker name display
When a group call is being set up, the floor changes, or the duration of the floor exceeds
the limit, a floor indication procedure is triggered to inform all group members of the following information:
− Call start time
− Floor status (idle or busy)
− Speaker ID
− UE priorities for preempting the floor
The floor status is sent periodically and the timer is configured on the dispatching
console. The name of the dispatch person is displayed as the dispatch person on all UEs instead of its specific name.
Enhancement
None
24
Dependencies
This feature requires TTRFD0201 Trunking Group.
2.30 TTRFD0220 Broadcast Call
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Broadcast call is a point-to-multipoint (P2MP) call initiated by the dispatching console.
Broadcast group calls include networkwide broadcast groups (the members in the group calls
are UEs in the system) and area-specific broadcast groups (the members in the group calls are
UEs in a specified area). Subscription is not required for a UE to join a broadcast group call.
All UEs in a specified area can receive broadcast calls.
Benefits
The dispatch person can call all UEs in the system or in a specified area.
Description
Broadcast groups include networkwide broadcast groups and area-specific broadcast groups.
A networkwide broadcast group includes all UEs in the network. There is only one network broadcast group in a network.
An area-specific broadcast group includes all UEs in a specified area. The area is
specified based on the eNodeB list. In the subscription information of an area-specific broadcast group, the area is specified based on the eNodeB name or eNodeB ID.
There are multiple area broadcast groups whose areas cannot be overlapped.
When a broadcast call is set up, the UEs that meet the following requirements are added to the
broadcast group call:
UEs in idle state
UEs in a group that has lower priority than the broadcast group call
Only the dispatch person can initiate a broadcast call and the floor cannot be preempted.
The broadcast group is not displayed on UEs and UEs cannot initiate a broadcast call. The
broadcast call is displayed on UEs only when the dispatch person initiates a broadcast call.
After a broadcast call is set up, the push to talk (PTT) button on a UE is disabled and the floor
cannot be preempted.
Enhancement
None
25
Dependencies
None
2.31 TTRFD0221 Dynamic Regrouping
Availability
This feature is introduced in eLTE 3.1.1.
Summary
During dynamic grouping, all messages are sent to the UE through air interfaces. With this
feature, the system administrator can dynamically group the group calls or users in the
dispatching console, and one or multiple UEs can be added to or removed from a group call.
During a dynamic grouping, the system sends the command to a UE only once and waits for
the response from the UE.
Benefits
The dispatch person can set up a dynamic group call which can be saved or removed after the
call ends.
Description
With this feature, the dispatcher can combine multiple UEs with multiple static group calls
that have been registered on the eOMC to form a new dynamic group call and set up the call.
When setting up a dynamic group, the dispatcher receives a list of UEs that do not receive the
call setup command. The dispatcher can create, remove, or query the dynamic group call on
the dispatch console. When setting up a dynamic group call, a new group call number is
added to UEs in a trunking network over the air interface. After the UE receives the dynamic
grouping command, it sends a message to the dispatch console to inform that it has received
the command and updates the subscription group. When a dynamic group is set up, the UE
automatically listens to the group call based on service priorities. UEs support setting up and
removing a dynamic group.
Enhancement
None
Dependencies
This feature requires TTRFD0201 Trunking Group.
2.32 TTRFD0222 Call Forwarding
Availability
This feature was introduced in eLTE 3.1.1.
26
Summary
This feature transfers a P2P call for a UE to another telephone number before the UE answers
the call.
Benefits
This feature helps transfer a call to another telephone number when the user cannot or is
unwilling to answer the call.
Description
Call transfer applies to PTP calls and eLTE 3.1.1 supports call forwarding unconditional
services. The system administrator can set one telephone number for call transfer on the web
UI of the dispatching console. If a user subscribes to call forwarding unconditional services,
the dispatching console will transfer all incoming calls to the preset telephone number for call
transfer, regardless of the state of the phone. If the system administrator deletes the preset
number for call transfer from the web UI of the dispatching console, the user can normally
receive the call.
Dependencies
This feature requires TTRFD0101 Private Call.
2.33 TTRFD0223 Call Data Record
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature generates a call detail record (CDR) on various services, including voice group
calls, voice P2P calls, video P2P calls, video uploading, and video distribution. The CDR
includes details about these services, such as the call number, called number, and call duration,
which facilitate analysis and statistics on billing and service usage.
Benefits
This feature satisfies the requirements of customers for billing or service analysis.
Description
When a wireless UE, dispatching console, or exterior gateway user performs voice or video
services in an enterprise network, the eAPP records the service information.
A CDR file is exported when a user performs a voice group call, voice P2P call, video P2P
call, video uploading service, or video distribution service. The CDR file contains the calling
number, called number, group number, service start time, service end time, service status,
service type, and call duration. The service status can be success or failure. The service type
can be group, voice PTP, video PTP, video upload, or video distribution. The call duration is
27
recorded depending on the voice or video service. No CDR file is exported when GIS services,
short messages, or multimedia messages are initiated.
The CDR file is saved in the eAPP in the .CSV format and can be obtained throughput the
FTP interface. It can be opened using Microsoft Office Excel.
Enhancement
None
Dependencies
None
2.34 TTRFD0225 Temporary Group Call
Availability
This feature is introduced in eLTE 3.1.1.
Summary
With this feature, the dispatch person can initiate a temporary call on multiple UEs or static
groups. After the temporary call is terminated, all UEs and NEs automatically delete the
configuration of this temporary call.
Benefits
The dispatch person can initiate a temporary group call on multiple UEs or static groups.
After the call is terminated, the temporary group is automatically dismissed.
Description
This feature provides the following functions:
Temporary group call establishment
The dispatch person can select multiple UEs or groups to build a temporary group call on
the dispatching console, and the call priority of the temporary group call is that of the
dispatch person who builds the temporary group call. Same as the call priorities of the
static group and dynamic group, the call priorities of the temporary group call is
classified into 0 to 15, among which 0 indicates the highest priority. Upon receiving a
temporary group call, the UE compares the call priority carried in the paging message
with the call priorities of the static group call, dynamic group call, and P2P call and joins
a group with the highest priority call priority. If two or more groups have the same
highest priority, the UE picks up the first incoming one.
Floor request
A user joining the temporary group call can preempt the floor by pressing the PTT key,
and the dispatcher performs temporary group call preemption based on the user registration priorities.
Floor release
The floor release process is the same as that for a common group call.
28
Later entry to the temporary group call
After a temporary group call is established, the offline members can join the call after
power-on, and online members joining other groups can also join the call after existing the corresponding groups.
Temporary group call close
A temporary group call can be closed by the dispatch person or released after the group
idle timer of the dispatcher expires. After a temporary group call is terminated,
information about the temporary group call is automatically deleted from the UEs and NEs.
Enhancement
None
Dependencies
None
2.35 TTRFD0226 Talking Party Identification
Availability
This feature is introduced in eLTE 3.1.1.
Summary
The caller ID is displayed on a dispatching console or a terminal when a group or private call
is made, or when a short or multimedia message is sent to the dispatching console or the
terminal.
Benefits
The callee can be informed of the speaker in a group call, the caller of a private call, or the
phone number from which a short or multimedia message is sent, to facilitate following
processing.
Description
The user receiving a private call can see the number of the caller before answering the call.
The user receiving a group call can see the number of the speaker in the group.
The user receiving a short or multimedia message can see the number from which the short or
multimedia message is sent.
29
However, only the gateway number of a PSTN or PLMN user is visible to a user in an
enterprise network when a call is made from the PSTN or PLMN user to the enterprise
network user.
Enhancement
None
Dependencies
This feature requires TTRFD0101 Private Call, TTRFD0201 Trunking Group and
TTRFD0124 Short Data Service.
2.36 TTRFD0227 Forced Preemption
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature enables an authorized dispatching console to release resources of one party of a
PTP call, and join a new PTP call between the other party of the original PTP call and
dispatching console.
Benefits
With this feature, resources can be temporarily released, so that specific subscriber can be
quickly be contacted by dispatching console.
Description
An authorized dispatching console can forcibly join a PTP call to preempt resources of an UE and release the resources allocated to the UE.
Enhancement
None
Dependencies
This feature requires TTRFD0101 Private Call.
30
2.37 TTRFD0241 Barring of Incoming and Outgoing Calls
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature applies only to PTP private calls. There are no restrictions on incoming and
outgoing PTP emergency calls.
With this feature, each UE can be restricted to call a specified number, a range of numbers, or
any number.
Each UE can restrict incoming calls from a specified number, a range of numbers, or any
number.
Benefits
The administrator can configure the limitation on incoming and outgoing calls and the range
of numbers that are restricted.
Description
An authorized administrator can configure the limitation on the following items for a UE:
Specified outgoing call number, the range of outgoing call numbers, or all outgoing call
numbers
Specified incoming call number, the range of incoming call numbers, or all incoming call numbers
When a UE initiates a private call, the dispatching system checks whether the UE is restricted
from initiating calls. If so, the system informs the UE that call origination is restricted.
When the dispatching system receives a request for calling a UE, it checks whether the called
UE is restricted from incoming calls. If so, the system informs the calling UE that the called
UE is restricted from incoming calls.
Restrictions on incoming and outgoing calls take effect when the next call is set up and do not
take effect on the UEs with ongoing private calls.
Enhancement
None
Dependencies
This feature requires TTRFD0101 Private Call.
31
2.38 TTRFD0271 Discreet Listening
Availability
This feature was introduced in eLTE 3.1.1 and is enhanced in eLTE 3.1.1.
Summary
With this feature, the dispatch person can supervise the call services of a UE in real time
without being perceived. In eLTE 3.1.1, imperceptible supervision can be performed on group
calls. In eLTE 3.1.1, imperceptible supervision can be performed on PTP calls.
Benefits
The dispatch person can supervise a group call without joining the group.
Description
In eLTE 3.1.1 imperceptible supervision is performed in the following scenarios:
The dispatch person is in the group to be monitored.
In this scenario, the dispatch person is added to the group during group call setup. If the
group call has been set up, the dispatch person is added to the group later.
The dispatch person is not in the group to be monitored.
In this scenario, the dispatching system sets up a call to transmit the data of the group being supervised to the dispatch person.
Enhancement
In eLTE 3.1.1, the imperceptible supervision procedure on PTP calls is as follows:
Step 1 During a PTP call between UEs A and B, a dispatch person with supervision rights issues an
imperceptible supervision command to the dispatcher.
Step 2 Upon receiving the imperceptible supervision command, the dispatcher determines whether
the command is valid, and if yes, initiates a call invitation to the dispatching console. The
dispatching console can perform imperceptible supervision after joining the call.
Step 3 The dispatcher performs audio mixing on the data streams from UEs A and B and then sends
data to the dispatching console.
----End
Multiple dispatching consoles can perform imperceptible supervision on a PTP call. Other
dispatch persons cannot perform imperceptible monitoring on the mixed data streams sent to
the dispatch person during imperceptible monitoring.
Dependencies
This feature requires TTRFD0101 Private Call and TTRFD0201 Group Call.
32
2.39 TTRFD0291 Remotely Enable/Disable Terminal
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature can remotely deactivate or activate a UE in a private network. A UE can no
longer access the network immediately after it is deactivated. The network can identify
whether a deactivation has taken effect.
Benefits
When a UE in a private network is lost, the services of the UE can be forbidden or the UE can
be forbidden to access the network.
Description
Remote deactivation: The network can remotely disable services of the UE. With this
feature, a UE can be barred from accessing the network temporarily or permanently. For
permanent remote deactivation the UE is barred from accessing the network. For
temporary remote deactivation the service of the UE is limited, only services related to
mobility management can be performed to facilitate future remote activation and location tracing.
Remote activation: The network can remotely activate a UE that was deactivated temporarily earlier. After a UE is remotely activated, its services recover.
Enhancement
None
Dependencies
None
2.40 TTRFD0301 Operating Bandwidth
2.40.1 TTRFD030101 5M/10M/20M System Bandwidth
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The bandwidths of 5 MHz, 10 MHz, and 20 MHz are supported.
33
Benefits A high bandwidth provides higher throughput and better user experience.
Flexible bandwidth configuration enables enterprise users to use different frequency
bands.
Description
The bandwidths of 5 MHz, 10 MHz, and 20 MHz are supported.
Enhancement
None
Dependencies
UEs must support the same bandwidth as the eNodeB.
2.40.2 TTRFD030102 3 MHz System Bandwidth
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature supports 3 MHz channel bandwidth on the 400 MHz frequency band.
Benefits
Due to insufficient spectrum resources on the 400 MHz frequency band, customers can hardly
obtain authorized frequency band resources of 5 MHz or higher. With this feature, LTE TDD
networks can be deployed on the 400 frequency band.
Description
The 3 MHz channel bandwidth becomes available on the 400 MHz frequency band.
Enhancement
None
Dependencies
The eRRU and UE support the 3 MHz bandwidth.
Currently, only eRRU3255 that operates at the 400 MHz frequency band supports the 3 MHz
bandwidth.
The LBBPd board must be configured.
34
2.41 TTRFD0302 Modulation Mode
2.41.1 TTRFD030201 DL/UL QPSK
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables eNodeBs and UEs to support DL/UL quadrature phase shift keying
(QPSK).
Benefits
With this feature, UL or DL QPSK is selected based on channel quality. When channel quality
is poor, QPSK is used to improve the reliability of data transmission.
Description
DL/UL QPSK has the following characteristics:
Two bits in each symbol can be modulated.
eNodeBs and UEs can select the optimum modulation scheme based on the current
channel quality. In this way, a tradeoff between the data rate and frame error rate can be achieved.
For example, when the radio environment of a UE is poor, QPSK with a low order can be used to transmit UL data to meet call quality requirements.
Enhancement
None
Dependencies
Both eNodeBs and UEs must support this feature.
2.41.2 TTRFD030202 DL/UL 16QAM
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables eNodeBs and UEs to support DL/UL 16QAM. QAM is short for
quadrature amplitude modulation.
Benefits
With this feature, UL or DL 16QAM is selected based on channel quality.
35
Description
UL/DL 16QAM has the following characteristics:
Four bits in each symbol can be modulated.
eNodeBs and UEs can select the optimum modulation scheme based on the current
channel quality. In this way, a tradeoff between the data rate and frame error rate can be achieved.
Enhancement
None
Dependencies
Both eNodeBs and UEs must support this feature.
2.41.3 TTRFD030203 DL 64QAM
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables eNodeBs and UEs to support DL 64QAM.
Benefits
With this feature, UL or DL 64QAM is selected based on channel quality. When channel
quality is good, a high-order modulation scheme, such as 64QAM, provides a higher data rate,
improving system throughput and spectral efficiency.
Description
DL 64QAM has the following characteristics:
Six bits in each symbol can be modulated.
eNodeBs and UEs can select the optimum modulation scheme based on the current
channel quality. In this way, a tradeoff between the data rate and frame error rate can be
achieved.
Better channel quality is required.
For example, when a UE is in a good radio environment, the eNodeB can use a
high-order QAM modulation scheme, such as 64QAM, to transmit DL data at a high data rate.
Enhancement
None
36
Dependencies
Both eNodeBs and UEs must support this feature.
2.41.4 TTRFD030204UL 64QAM
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature provides UL 64QAM supported by UEs and eNodeBs. UL 64QAM is applicable
only to LTE TDD.
Benefits
Under good channel conditions, this feature helps achieve a higher data rate, thereby
improving system throughput and spectrum efficiency.
Description
This feature allows an eNodeB and UE to select UL 64QAM based on the current channel
condition.
Enhancement
None
Dependencies
UL 64QAM has the following requirements:
Both the eNodeB and UE support UL 64QAM.
The Category 4* UE is supported.
2.41.5 TTRFD030205AMC
Availability
This feature was introduced in eLTE 3.1.1.
Summary
AMC allows an eNodeB to select an optimal modulation and coding scheme (MCS) based on
the channel condition. This improves the spectrum efficiency under a premise of fixed system
resource and transmit power, thereby maximizing throughput and satisfying QoS
requirements.
Benefits
This feature offers the following benefits:
37
Selects the optimal MCS, thereby maximizing system throughput.
Selects the optimal MCS to satisfy QoS requirements, thereby achieving a tradeoff
between the data rate and block error rate (BLER).
Description
In the uplink, the eNodeB selects the initial MCS based on the measured signal to interference
plus noise ratio (SINR) of the uplink reference signal (RS). Then, the eNodeB adjusts the
MCS based on the received uplink sounding reference signal (SRS) or demodulation
reference signal (DMRS) or based on whether control signals are involved in uplink
transmission. Note that a low-order MCS is required for control signals to ensure reliable
transmission.
In the downlink, the eNodeB selects the MCS for each UE based on the UE-reported CQI and
power assigned to the UE. Then, the eNodeB adjusts the CQI based on the BLER. This
maximizes utilization of radio resources.
Enhancement
None
Dependencies
None
2.42 TTRFD0308 MIMO
Availability
This feature was introduced in eLTE 3.1.1.
Summary
In eLTE2.2, the eBBU can use downlink 2x2 multiple-input multiple-output (MIMO),
2-antenna transmit diversity, and adaptive switching between MIMO modes to improve
downlink system performance.
Benefits
This feature improves downlink throughput and coverage performance.
Description
Downlink 2x2 MIMO improves system performance, such as the data transmission rate.
eNodeBs support the following downlink 2x2 MIMO modes:
Transmit diversity
Open-loop spatial multiplexing
Closed-loop spatial multiplexing
Closed-loop rank 1 precoding
38
If an eNodeB is configured with two transmit antennas, the eNodeB can adaptively select a
MIMO mode based on UE rates and downlink channel quality. Among these MIMO modes,
transmit diversity and closed-loop rank 1 precoding help prevent signal fading and
interference.
Spatial diversity provides several types of signal branches with independent variable signal
levels, thereby increasing the robustness of radio links, because the probability that all signal
branches are experiencing deep fading is extremely low.
Spatial multiplexing is classified into open-loop and closed-loop spatial multiplexing. This
function enables an eNodeB to transmit independent and separately encoded data signals,
known as streams, from each of the transmit antennas, bringing spatial multiplexing gains. If
Ntx antennas are configured on the transmit side and Nrx antennas on the receive side, the
maximum spatial multiplexing order Ns is calculated using the following formula:
Ns = min (Ntx, Nrx)
If spatial channels are independent from each other and different data streams are transmitted
on different spatial channels, spatial multiplexing increases the spectral efficiency or system
capacity by Ns folds.
Enhancement
None
Dependencies
Downlink 2x2 MIMO has the following requirements:
Each sector is configured with two transmit channels and two antennas.
Each UE is equipped with two or more receive antennas.
2.43 TTRFD0310 TTI Bundling
Availability
This feature is introduced in eLTE 3.1.1.
Summary
TTI Bundling expands uplink coverage of an LTE cell. With this feature, a cell edge user
(CEU) with a poor uplink SINR can transmit the same data in multiple consecutive subframes.
This feature applies to PTT speakers and PTP calls only in LTE TDD networks in weak
coverage or single cell scenarios.
Benefits
This feature improves uplink coverage for voice services.
Description
This feature repeatedly transmits the same TB by fully using the retransmission combination
gains of the HARQ mechanism, which reduces the RTT time and expands uplink coverage.
39
With this feature, a high-order MCS is adopted to support a great number of small-packet
delay-sensitive voice services under weak edge coverage. This reduces the voice data packet
fragmentation and header load and ensures short transmission delay and correctness, thereby
improving uplink edge coverage for voice services.
Enhancement
None
Dependencies
This feature has the following requirements:
The UE supports TTI bundling.
This feature cannot be used together with semi-persistent scheduling and supports only uplink and downlink subframe configurations 0 and 1.
2.44 TTRFD0321 Idle Resource Management
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature enables cell-specific management for idle group resources.
Benefits
The system resource efficiency improves.
Description
Idle resource management is classified into the following types:
EPS-specific idle resource management
If no group members are scheduled for the floor for a specified time, the EPS closes the
group and releases all related resources. The group must be reestablished to continue the
conference.
Cell-specific idle resource management
The EPS counts online members within each group in a cell when any of the following
conditions are true:
A UE exits the group in the serving cell and joins another group.
The UE is handed over to another cell.
A tracking area update (TAU) occurs when the UE moves to another tracking area (TA).
The UE detaches from the network.
The UE is remotely barred from network access.
40
If a group has no member in the cell, the EPS releases resources related to this group of this
cell.
Enhancement
None
Dependencies
None
2.45 TTRFD0322 Dynamic Group Resource Allocation and Release
Availability
This feature was introduced in eLTE 3.1.1.
Summary
While a group call is ongoing, the EPS allocates user-plane resources only to the eNodeBs or
cells that have active group members.
Benefits
The amount of resources used by group services decreases and the trunking system capacity
increases.
Description
The eCNS210 or eSCN230 counts speakers and listening UEs within each group in each cell.
When groups in a TA or on an eNodeB have no listening UE for a specified time, the
eCNS210 or eSCN230 releases user-plane resources allocated to the TA or eNodeB. If there
are active speakers or listening UEs, the eCNS210 or eSCN230 allocates user-plane resources
to the TA or eNodeB.
Enhancement
None
Dependencies
This feature requires TTRFD0323 Dynamic eNodeB Allocation.
41
2.46 TTRFD0324 Admission Control
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The admission control feature controls connection setup based on resource availability while
ensuring that quality of service (QoS) requirements are met. This feature helps ensure system
stability and QoS performance.
Benefits Services become stable in the cells.
The optimal tradeoff between the resource efficiency and QoS is achieved.
Description
Admission control is cell specific and used for radio resource management (RRM). This
feature determines whether to accept an incoming call or handover request, applicable to both
the uplink and downlink. In eLTE2.2, admission control is implemented based on system
resource availability and QoS satisfaction.
When the EPS receives an incoming call or handover request, it performs the following
operations:
Step 1 Checks transmission bandwidths, hardware usage, and system overload indication to
determine whether system resources are sufficient.
If system resources are insufficient, the EPS rejects the request.
If system resources are sufficient, the EPS performs operations in Step 2.
Step 2 Checks whether the resource block (RB) usage is low or the transmit power headroom is
limited.
If the RB usage is low and the transmit power headroom is not limited, the EPS accepts the request.
If the RB usage exceeds the upper limit or the transmit power headroom is limited, the EPS performs operations in Step 3.
Step 3 Checks the QoS satisfaction based on the QoS class identifier (QCI).
QCIs are defined for conversational voice, buffered streaming, IP multimedia subsystem (IMS)
signaling, guaranteed bit rate (GBR), and non-GBR services.
If the QoS satisfaction is greater than the predefined admission threshold, the EPS accepts the
request.
If the QoS satisfaction is lower than or equal to the predefined admission threshold, the EPS
rejects the request.
Incoming handover requests have higher priorities than incoming call requests, and admission control is preferentially implemented on handover requests.
NOTE
42
Gold, silver, and copper services are assigned different admission control thresholds based on
allocation/retention priority (ARP) values. ARP values are configured on the EPC.
In eLTE2.2, group services are subject to admission control based on the number of groups in
each cell. When the number of groups in a cell reaches the specified admission control
threshold, the EPS bars new group services from accessing the cell.
----End
Enhancement
None
Dependencies
None
2.47 TTRFD0325 Power Control
Availability
This feature was introduced in eLTE 3.1.1.
Summary
In LTE systems, different power control mechanisms are used in the uplink and downlink:
Uplink power control: In the uplink, the eNodeB controls the transmit power of the UE
in the uplink, therefore mitigating interference to neighboring cells and increasing
system throughput. Uplink power control applies to the physical uplink shared channel
(PUSCH), physical uplink control channel (PUCCH), SRS, and physical random access channel (PRACH) data.
Dynamic downlink power allocation: The eNodeB dynamically adjusts its transmit
power in the downlink based on the radio channel quality, minimizing the eNodeB power consumption.
Benefits Uplink power control brings the following benefits:
− Enables eNodeBs to fine-tune UEs' transmit power.
− Mitigates interference to neighboring cells and increases the overall system throughput.
− Reduces the BLER and improves service quality.
− Reduces the UE power consumption.
Dynamic downlink power allocation improves downlink channel quality, CEU throughput, and transmit power efficiency.
Description
Uplink power control applies to PUSCH, PUCCH, SRS, and PRACH.
43
For PUSCH, dynamic scheduling and semi-persistent scheduling are used.
Dynamic scheduling
− The eNodeB dynamically adjusts the PUSCH transmit power based on the difference between SINRTarget and the measured SINR.
− If the measured SINR is greater than SINRTarget, the eNodeB delivers a transmit
power command (TPC), instructing the UE to reduce the PUSCH transmit power.
If the measured SINR is less than SINRTarget, the eNodeB delivers a traffic
parameter control (TPC) command, instructing the UE to increase the PUSCH transmit power.
− The eNodeB adjusts the UE transmit power spectral density (PSD) based on the
overload information (OI) of neighboring cells, UE power headroom, and the number
of allocated RBs. In this way, UE throughput becomes stable and system throughput improves.
Semi-persistent scheduling
− In semi-persistent scheduling mode, the eNodeB adjusts the PUSCH transmit power
based on the difference between IBLERTarget and the measured initial block error
rate (IBLER).
− If the measured IBLER is greater than IBLERTarget, the eNodeB delivers a traffic
parameter control (TPC) command, instructing the UE to increase the PUSCH transmit power.
− If the measured IBLER is less than IBLERTarget, the eNodeB delivers a traffic
parameter control (TPC) command, instructing the UE to reduce the PUSCH transmit power.
− For voice over IP (VoIP) services, the eNodeB delivers the PUSCH TPC command of
downlink control information (DCI) format 3/3A to multiple UEs for power control, reducing physical downlink control channel (PDCCH) overheads.
PUCCH data is subject to the same power control mechanism as PUSCH data, except that
different parameters are used, such as SINRTarget for outer-loop power control.
SRS data is subject to the same power control mechanism and parameters as PUSCH data.
The initial SRS transmit power is calculated in the same way as the initial PUSCH transmit
power, except that the calculation of the initial SRS transmit power also involves the power
offset related to radio resource control (RRC) connections.
For PRACH data, the UE calculates the initial transmit power of random access preambles
based on the estimated downlink path loss and the UE's expected receive power received on
the eNodeB. The UE obtains the expected power received by the eNodeB from broadcast
channels. If random access fails due to no response from the eNodeB, the UE increases the
transmit power of the random access preambles based on RRC parameters.
In the downlink, dynamic power allocation applies to physical downlink shared channel
(PDSCH), PDCCH, physical HARQ indicator channel (PHICH), physical broadcast channel
(PBCH), and physical control format indicator channel (PCFICH) data.
For cell-specific reference signal (CRS), synchronization signals, PBCH, and PCFICH data,
the transmit power must ensure the downlink cell coverage and users can set the transmit
power to fixed values based on channel quality. The rule also applies to the PDCCH and
PDSCH that are used to bear common cell information.
For PDCCH used to bear dedicated control information, the eNodeB periodically adjusts the
transmit power based on the difference between the measured BLER and BLERTarget. If the measured BLER is greater than BLERTarget, the eNodeB increases the PDCCH transmit power.
44
If the measured BLER is less than BLERTarget, the eNodeB decreases the PDCCH transmit
power. The fixed transmit power is also supported for such PDCCH data.
In dynamic scheduling, the PDSCH transmit power depends on PA and is adjusted by
changing PA. When an eNodeB receives a channel quality indicator (CQI) reported by the UE,
the eNodeB compares the newly received CQI value with the previous value. If the new value
significantly differs from the previous value, the eNodeB instructs the UE to calculate PA for
power adjustment.
In semi-persistent scheduling, the eNodeB periodically adjusts the PDSCH transmit power
based on the difference between the measured IBLER and IBLERTarget.
If the measured IBLER is less than IBLERTarget, the eNodeB decreases the PDSCH transmit power.
If the measured IBLER is greater than IBLERTarget, the eNodeB increases the PDSCH
transmit power.
The eNodeB periodically adjusts the PHICH transmit power based on the difference between
the SINRRS in the CQI report and SINRTarget.
If SINRRS is less than SINRTarget, the eNodeB increases the PHICH transmit power.
If the SINRRS is greater than SINRTarget, the eNodeB decreases the PHICH transmit
power.
Enhancement
None
Dependencies
None
2.48 TTRFD0326 Load Control
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature adjusts the system load if the EPS is congested or QoS requirements cannot be
met.
This feature is used to guarantee QoS for the admitted services while maximizing resource
efficiency.
Benefits This feature prevents system instability caused by system overloading.
This feature ensures QoS satisfaction.
45
Description
With this feature, the EPS remains stable and QoS requirements are met when this EPS is
congested.
When this feature is enabled, the EPS measures the power, available physical resource blocks
(PRBs) over the air interface, and transmission resource efficiency over the S1-U interface.
In eLTE2.2, either of the following operations can be performed on the eBBU for load
control:
Releasing low-priority services. The service priority depends on the assigned QCI.
Slightly reducing the GBR of all GBR services. Ensure that the GBR is greater than the
minimum bit rate. In this way, the EPS improves the overall QoS satisfaction by slightly
compromising the GBR service quality. GBR services can be classified into gold, silver,
and copper services. Different types of service are configured with different ARP
thresholds. If a system congestion occurs, the GBR of copper services is preferentially reduced.
Among VoIP services in persistent-persistent scheduling, low-priority VoIP services are
preferentially released if the EPS is overloaded or QoS requirements cannot be met.
Enhancement
None
Dependencies
None
2.49 TTRFD0327 Mobility Management
2.49.1 TTRFD032701 Coverage-based Intra-Frequency Handover
Availability
This feature was introduced in eLTE 3.1.1.
Summary
In wireless cellular networks, handovers are used to ensure service continuity for the moving
UEs. It helps reduce the communication delay and improve network coverage and system
performance.
The intra-frequency handover feature enables a UE in connected mode to run services
continuously when the UE moves between intra-frequency cells.
Benefits
On an intra-frequency LTE network, the coverage-based intra-frequency handover feature
enables intra-frequency cells to provide supplemental coverage for each other and ensures
seamless coverage. It decreases the service drop rate and improves network performance.
46
Description
On an intra-frequency LTE network, the coverage-based intra-frequency handover feature
enables intra-frequency cells to provide supplemental coverage for each other and ensures
seamless coverage. It decreases the service drop rate and improves network performance.
Intra-frequency handovers are performed between intra-frequency cells and can be triggered
by the predefined coverage- or load-based threshold. In eLTE2.2, the eBBU supports
coverage-based intra-frequency handover.
An intra-frequency handover process consists of three phases: measurement, decision, and
execution. The intra-frequency handover process differs for UEs in connected mode and for
listening UEs in idle mode.
UEs in connected mode
The eNodeB delivers the measurement configuration to a UE using an RRC Connection
Reconfiguration message. Based on the received measurement configuration, the UE
measures the reference signal received power (RSRP) or reference signal received
quality (RSRQ) for an intra-frequency handover.
Upon receiving the measurement report from the UE, the eNodeB determines whether to
perform an intra-frequency handover. If the intra-frequency handover criteria are met,
the eNodeB hands over the UE from the source cell to the target cell. In eLTE2.2, the
eBBU performs intra-frequency handovers according to 3GPP TS 36.300.
Listening UEs in RRC_IDLE mode
The eNodeB delivers the measurement configuration to a UE using SIB20. Based on the
received measurement configuration, the UE measures the RSRP or RSRQ for an intra-frequency handover.
Before the UE is to send a measurement report to the eNodeB, it sends an RRC
connection setup request to the eNodeB. After an RRC connection is set up, the UE
enters RRC_CONNECTED mode and then sends the measurement report to the eNodeB on the DCCH.
Upon receiving the measurement report from the UE, the eNodeB determines whether to
perform an intra-frequency handover. If the intra-frequency handover criteria are met,
the eNodeB hands over the UE from the source cell to the target cell. In eLTE2.2, the eBBU performs intra-frequency handovers according to 3GPP TS 36.300.
Intra-frequency handovers apply to the following scenarios:
The source and target cells belong to the same eNodeB.
The source and target cells belong to different eNodeBs between which no X2 interface
is available. In this situation, the source eNodeB sends a Handover Required message to the UE over the S1 interface.
Enhancement
None
Dependencies
None
47
2.49.2 TTRFD032702 Coverage-based Inter-Frequency Handover
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The inter-frequency handover feature enables a UE in RRC_CONNECTED mode to run
services continuously when the UE moves between inter-frequency cells.
Benefits
On an inter-frequency LTE network, the coverage-based inter-frequency handover feature
enables inter-frequency cells to provide supplemental coverage for each other and ensures
seamless coverage. It decreases the service drop rate and improves network performance.
Description
The inter-frequency handover feature enables a UE in RRC_CONNECTED mode to run
services continuously when the UE moves between inter-frequency cells.
Each intra-frequency handover process consists of four phases: measurement triggering,
handover measurement, handover decision, and handover execution.
In an inter-frequency measurement, the UE equipped with one RF receiver measures the
RSRP or RSRQ for the neighboring cells in gap-assisted mode. The inter-frequency
measurement is triggered by event A2 and stopped by event A1.
When the measured RSRP or RSRQ meets the inter-frequency handover criteria specified in
the measurement configuration, the UE sends a measurement report to the eNodeB.
Upon receiving the measurement report from the UE, the eNodeB determines whether to
perform an inter-frequency handover. If the measurement results meet the handover criteria,
the eNodeB performs an inter-frequency handover according to 3GPP TS 36.300.
Inter-frequency handovers apply to the following scenarios:
The source and target cells belong to the same eNodeB.
The source and target cells belong to different eNodeBs between which no X2 interface
is available. In this situation, the source eNodeB sends a Handover Required message to
the UE over the S1 interface.
Enhancement
None
Dependencies
None
48
2.49.3 TTRFD032703 Cell Selection and Reselection
Availability
This feature was introduced in eLTE 3.1.1.
Summary
With this feature, a UE in idle mode selects or reselects the best cell for camping so that the
UE can experience best service quality when a session is set up.
Benefits
This feature improves service quality by enabling UEs to camp on appropriate cells.
Description
When a UE registers with a PLMN or switches from RRC_CONNECTED to RRC_IDLE, the
UE selects an appropriate cell for camping based on measurement results and cell selection
criteria.
After a UE camps on a cell, the UE regularly searches for a better cell based on the cell
reselection criteria, and reselects a better cell if available.
The eNodeB sends information about the absolute priorities of different E-UTRAN
frequencies to the UE using system information or an RRC Connection Release message.
Enhancement
None
Dependencies
None
2.50 TTRFD0328 High Velocity Algorithm
Availability
This feature is introduced in eLTE 3.1.1.
Summary
With the high-velocity algorithm, the eNodeB ensures the continuity of uplink and downlink
services of UEs moving at a speed of 120 km/h or higher. This feature applies only to LTE
FDD.
Benefits
This feature ensures normal voice and data services of high-speed and ultra-high-speed UEs.
49
Description
In high-velocity scenarios, the eNodeB uses automatic frequency control to adjust the
scheduling mode based on UEs' frequency offset to satisfy performance requirements for
high-velocity movement. This feature ensures good user experiences in the following two
scenarios:
UEs moving at a speed of 120 km/h in high-velocity scenarios
UEs moving at a speed of 350 km/h to 450 km/h at the frequency band not higher than 1
GHz in ultra-high-speed scenarios. Performance of UEs in ultra-high-speed scenarios will become better if there is no barriers between the UEs and eNodeB.
Enhancement
None
Dependencies
None
2.51 TTRFD0341 QoS Management
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The eCNS, eSCN, and eNodeB support bearer-level QoS control.
Benefits
This feature ensures end-to-end (E2E) QoS on an TD-LTE network.
Description
Figure 2-1 shows the QoS management architecture.
50
Figure 2-1 QoS management architecture
eCNS/eSCN eNodeB
Radio network
layer
Transport network
layer
QoS service request
QoS service provisioning
Backhaul
QoS service request
QoS service provisioning
Control-plane QoS
management
User-plane QoS management
Load control
Admission control
Congestion control
Preemption control
Overload control
QoS monitoring
Stream classification/tag
Mapped to the transport resource
· Service QoS
· Bearer network QoS
· Control-plane resource management
· User-plane resource management
·Classification/Tag
·CAR
·Congestion control
·Service scheduling and shaping: PQ, WFQ
·Classification/Tag
·CAR
·Congestion control
·Service scheduling and shaping: PQ, WFQ
Control-plane QoS
management
User-plane QoS management
Load control
Service flow control
Stream classification/tag
Mapped to the transport resource
The eCNS and eSCN perform QoS management effectively, involving:
Admission control, congestion control, preemption control, overload control, and data flow control
QoS management based on user-plane data flow type. That is, layer 3 QoS management
is performed for differentiated services based on DSCP values and layer 2 QoS management is performed based on IEEE 802.1p/Q.
QoS management based on queue types, which include the strict priority (SP) queue,
weighted round robin (WRR) queue, and weighted fair queuing (WFQ) queue
QoS management based on requirements for the delay, jitter, and packet loss on the bearer
Figure 2-2 QoS mapping
eCNS/eNodeB
QoS mapping
Radio
network layer
Transport layer
IP layer
Data link layer
Physical layer
Application layer
QoS: 3GPP service classification (conversational, buffered,
interactive, and background services), OM, signaling, and others
Mapping
· Ethernet QoS: IEEE 802.1p/Q
· Scheduling: PQ, WRR
IP layer
IP QoS: DiffServ, DSCP tag
Mapping
QoS mapping involves:
Mapping from service types to DSCP values
Mapping from DSCP values to VLAN priorities
The bearer context stored on the eCNS and eSCN contains bearer-level QoS parameters,
including GBR, MBR, ARP, QCI, APN-AMBR, and UE-AMBR.
Table 2-1 describes these bearer-level QoS parameters.
51
Table 2-1 Bearer-level QoS parameters
QoS Parameter Description
QCI 3GPP specifications define nine QoS class identifiers (QCIs) for
different services based on QoS requirements. The QCIs are
standardized QoS requirements and the evolved packet system (EPS)
implements QoS management based on QCIs. Each QCI specifies a
set of requirements for the resource type, priority, delay, and packet
loss rate of a service type. QCIs are transmitted among the EPS
nodes, thereby eliminating the need for negotiation and delivery of a
large number of QoS parameters.
Service data flows (SDFs) with different QCIs are mapped to
different EPS bearers.
ARP An allocation/retention priority (ARP) indicates the relative
importance for resource allocation and retention on an EPS bearer
compared to other EPS bearers. Based on the ARP, the eNodeB
decides whether to accept or reject a bearer establishment or
modification request if resources are insufficient. Once congestion
occurs, the eNodeB determines which bear or bearers are to be released based on the ARP.
GBR
MBR
A guaranteed bit rate (GBR) indicates the guaranteed bit rate that is
expected to be provided for a GBR bearer, and a maximum bit rate
(MBR) indicates the maximum bit rate that can be provided for a GBR bearer.
GBR and MBR are used to manage the bandwidths for GBR bearers.
The EPS admits all SDFs whose bit rates are less than or equal to the
GBR by reserving resources and discards all SDFs whose bit rates are
higher than the MBR. If the bit rates of SDFs are greater than the
GBR but less than the MBR, the EPS discards the SDFs when the
network is congested or admits the SDFs when the network is not congested.
UE-AMBR
APN-AMBR
An aggregate maximum bit rate (AMBR) sets the limit for the total of
bit rates that can be provided across all non-GBR bearers. An AMBR
can be applied to multiple EPS bearers. AMBRs are categorized as
follows:
APN-AMBR: sets the limit for the aggregate maximum bit rate
per APN. Bandwidth management based on APN-AMBR limits
the total of bit rates that can be provided across all non-GBR
bearers for a UE under an access point name (APN).
UE-AMBR: sets the limit for the aggregate maximum bit rate per
UE. Bandwidth management based on UE-AMBR limits the total
of bit rates that can be provided across all non-GBR bearers for a UE.
52
Table 2-2 ARP parameters
Parameter Description
PVI Specifies whether resources for a service can be preempted by another
service with a higher priority when resources are insufficient. The
parameter value can be 0 or 1. Value 0 indicates that resources for a service can be preempted.
PL Specifies the admission priority of a service. According to 3GPP TS
29.212, eight priority levels are recommended and the recommended
parameter value ranges from 1 to 8. Value 1 indicates the highest priority level.
PCI Specifies whether a service can preempt the resources from another
service with a lower priority when resources are insufficient. The
parameter value can be 0 to 1. Value 0 indicates that a service can
preempt resources from other services.
Table 2-3 QCI-DSCP mapping
QCI DSCP DSCP Value Description Example Service
1 EF 101110 GBR Conversational voice
2 AF31 11010 Conversational video (live
streaming)
3 AF31 11010 Non-conversational video
(buffered streaming)
4 AF41 100010 Real-time gaming
5 EF 101110 Non-GBR IMS signaling
6 AF21 10010 Voice, video (live streaming)
interactive gaming
7 AF21 10010 Video (buffered streaming)
TCP-based (for example, www,
e-mail, chat, ftp, p2p file sharing, progressive video)
8 AF11 1010
9 BE 0
53
The QoS Management feature involves radio resource processing over the air interface, and
provides dynamic scheduling, semi-persistent scheduling, and adaptive modulation and
coding (AMC). Features described in this document, such as admission control and load
control, are also related to QoS management.
Dynamic scheduling ensures the QoS of users and achieves efficient resource utilization.
In addition, dynamic scheduling considers the fairness among different UEs. Dynamic
scheduling applies to GBR and non-GBR services.
Semi-persistent scheduling ensures that resources are allocated effectively when a radio
network experiences traffic bursts. Within a predefined period of time, semi-persistent
scheduling takes effect if a large amount of data is to be transmitted. On the trunking
enterprise network, semi-persistent scheduling is preferentially used for downlink group
services, uplink host services, and uplink and downlink point-to-point services.
To ensure the QoS for group services, the semi-persistent scheduling algorithm is
enabled, which requires that the bit rate, transmit power, and modulation scheme be fixed.
AMC enables an eNodeB to adaptively select the optimal MCS based on channel
conditions. When the system resources and transmit power are fixed, AMC improves the
spectral efficiency, thereby maximizing throughput and meeting the QoS requirements.
Channel quality indicator (CQI) adjustment is an enhancement to AMC. The optimal
MCS is selected to satisfy QoS requirements, thereby a tradeoff between the data rate and block error rate (BLER) is achieved.
The scheduling function improves resource utilization on shared channels. On an LTE
network, the scheduler allocates resources to UEs every 1 ms or transmission time interval
(TTI). The scheduling algorithm must meet QoS requirements of different services and
achieve an optimal tradeoff between priority-based service differentiation and user fairness.
3GPP specifications define nine QCIs for GBR and non-GBR services. The scheduling
scheme must ensure the bit rate of GBR services and increase the AMBR of non-GBR
services. The minimum bit rate is designed for non-GBR services to guarantee QoS in the
event of resource insufficiency.
The uplink scheduler uses the token bucket algorithm to achieve rate control for GBR and
non-GBR services. The proportional fair (PF) algorithm ensures scheduling priorities (based
on QCI) among different services. High priorities are assigned to IMS signaling and GBR
services. Semi-persistent scheduling can be used for VoIP services to ensure voice quality.
When receiving the congestion indicator from the load control algorithm, the uplink scheduler
may reduce the guaranteed data rate for GBR services. The uplink scheduler may also
consider the information delivered from UL ICIC to reduce interference.
On an LTE TDD network of eRAN2.1, the uplink scheduler assigns logical channel groups
(LCGs) to services based on operator configurations. One LCG is assigned to VoIP services
and two LCGs are assigned to non-GBR services so that QoS is guaranteed for high-priority
non-GBR services during uplink scheduling. Different from the minimum bit rate, the
prioritized bit rate (PBR) is specific to services running on the trunking enterprise network.
The downlink scheduler employs an enhanced scheduling policy, which requires that the
scheduler ensures the GBR and AMBR for all services within a specified time window. For
GBR services, the downlink scheduler considers the user channel quality and service packet
delay when calculating the priority. For non-GBR services, the downlink scheduler considers
the user channel quality and scheduled service throughput when calculating the priority. Note
that VoIP services still use semi-persistent scheduling. Therefore, the scheduler does not
adjust the bandwidth that has been allocated to VoIP services. The enhanced downlink
scheduler can achieve an optimal tradeoff among throughput, fairness, and QoS. Similarly, the
54
downlink scheduler also considers the input from downlink ICIC to reduce the inter-cell
interference.
This feature improves service quality of CS services. Group calls and point-to-point calls are
implemented in voice over LTE (VoLTE) mode, not CS fallback mode. VoLTE can use the
semi-persistent scheduling function to improve voice quality.
Group calls and point-to-point calls are real-time services. Their data packets are small and
have fixed length and arrival time. CS traffic bursts with fixed packet length and arrival time
are generated by AMR transcoding. In VoLTE mode, data packets can be transmitted in the
talk spurts and silent periods. In a talk spurt, the AMR voice packets are transmitted every 20
ms. In a silent period, the silence indicator (SID) packets are transmitted every 160 ms.
During call setup, semi-persistent scheduling allocates a specified number of RBs to CS
services. During semi-persistent scheduling, no uplink or downlink signaling messages are
exchanged before the call terminates or resources are released. Additionally, resources are
preserved during semi-persistent scheduling, which greatly reduces the overhead on the
physical downlink control channel (PDCCH) and guarantees QoS for AMR voice services.
The AMC function allows an eNodeB to adaptively select the optimal MCS according to the
channel conditions. This improves the spectrum efficiency when the system resource and
transmit power are fixed, thereby maximizing throughput and meeting the QoS requirements.
In the uplink, the eNodeB selects the initial MCS based on the SINR of the measured uplink
RS. Then, the eNodeB may adjust the MCS based on the received SRS or DMRS; the
eNodeB can also adjust the MCS when the uplink transmission signals include control
information. Control information may require a low-order MCS to ensure transmission
reliability.
In the downlink, the eNodeB first selects the MCS for each UE based on the CQI reported
from the UE and assigned power for the UE. Then, the eNodeB adjusts the CQI to impact
MCS based on the BLER, maximizing the radio resource utilization.
Enhancement
None
Dependencies
None
2.52 TTRFD0342 High QoS Management
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The High QoS Management primarily applies to services that are highly sensitive to delay.
On an LTE network, the scheduler allocates resources to UEs every 1 ms or TTI. The
scheduling algorithm must meet QoS requirements of different services and achieve an
optimal tradeoff between priority-based service differentiation and user fairness.
55
Benefits
On an LTE network, the scheduling feature guarantees QoS.
The eBBU scheduling scheme in eLTE3.0:
Guarantees QoS for GBR and non-GBR services.
Achieves an optimal tradeoff among throughput, fairness, and QoS.
The AMC function:
Maximizes system throughput by selecting the optimal MCS.
Meets the QoS requirements (such as the packet loss rate) by selecting the optimal MCS to achieve the tradeoff between data rates and BLERs.
Different QCI bearers can be used for different service types of services to meet different QoS
requirements of services. For example, bearers with QCIs of 5 are used to carry services that
are highly sensitive to delay and packet loss, such as train control information; GBR bearers
are used to carry voice and video services.
Description
3GPP specifications define nine QCIs for GBR and non-GBR services. The scheduling
scheme must ensure the bit rate of GBR services and increase the AMBR of non-GBR
services. The minimum bit rate is designed for non-GBR services to guarantee QoS in the
event of resource insufficiency.
QCI is one of the most important QoS parameters for EPS bearers. It is a quantitative degree,
representing the QoS feature provided by an EPS to a service data flow (SDF). Each SDF is
associated with only one QCI. If multiple SDFs that correspond to the same IP-CAN session
have the same QCI and ARP, these SDFs can be processed as a separate aggregate of services,
that is, an SDF aggregate.
QCI Resource Type
Priority Delay Packet Loss Rate
Typical Service
1 GBR 2 100 ms 10-2 Conversational
voice
2 4 150 ms 10-3 Conversational
video (live)
3 3 50 ms 10-3 Real-time game
4 5 300 ms 10-6 Non-conversational
video (buffer
stream)
5 Non-GBR 1 100 ms 10-6 IMS signaling
56
QCI Resource Type
Priority Delay Packet Loss Rate
Typical Service
6 6 300 ms 10-6 Voice (buffer
stream) and
TCP-based services
(such as www,
e-mail, chat, FTP,
P2P file sharing, and
progressive video)
7 7 100 ms 10-3 Voice, video (live
stream), and
interactive gaming
8 8 300 ms 10-6 Voice (buffer
stream) and
TCP-based services
(such as www,
e-mail, chat, FTP,
P2P file sharing, and
progressive video)
9 9
The above standard QCI attributes describe the features of packet transmission corresponding
to an SDF aggregate:
Resource type: determines whether private network resources related to services or
bearer-level GBRs are consistently allocated. GBR SDF aggregates require dynamic Policy
and Charging Control (PCC) and non-GBR SDF aggregates require only static PCC. Priority: distinguishes SDF aggregates of the same UE or SDF aggregate of different UEs.
Each QCI is associated with a priority and priority 1 represents the highest priority level. PDB: indicates the possible delay of packets between a UE and a PDN-GW. PDB is intended
to support configurations of time sequences and link-layer functions. For the same QCI, PDBs
are the same in the downlink and uplink. Packet loss rate (PLR): indicates the proportion of packets that have been processed by the
transmit end at the link layer but fail to be transmitted to the upper-layer SDU by the receive
end. Therefore, PLR represents the upper limit of packet loss rates in non-congestion
conditions. For the same QCI, PLRs are the same in the uplink and downlink.
The uplink scheduler uses the token bucket algorithm to achieve rate control for GBR and
non-GBR services. The proportional fair (PF) algorithm ensures scheduling priorities (based
on QCI) among different services.
The downlink scheduler employs an enhanced scheduling policy, which requires that the
scheduler ensures the GBR and AMBR for all services within a specified time window. For
GBR services, the downlink scheduler considers the user channel quality and service packet
delay when calculating the priority. For non-GBR services, the downlink scheduler considers
the user channel quality and scheduled service throughput when calculating the priority. The
enhanced downlink scheduler can achieve an optimal tradeoff among throughput, fairness,
and QoS.
57
Enhancement
None
Dependencies
None
2.53 TTRFD0361 Interference Control
2.53.1 TTRFD036101 IRC
Availability
This feature was introduced in eLTE 3.1.1.
Summary
In eLTE 3.1.1, the interference rejection combining (IRC) algorithm is used to mitigate
interference.
Benefits
UL receive gains and throughput increase. Coverage in the UL expands.
Description
IRC is a technology that combines receive antennas to mitigate inter-cell interference. This
technology is usually used with receive diversity. IRC can be used for multiple-input
multiple-output (MIMO) decoding in any scenario, especially in scenarios with colored
interference.
The IRC algorithm simulates a random process for interference. During this process. an
optimal filtering technology is used to pre-whiten received data based on interference-related
parameters, such as the covariance matrix. After IRC processing, interference is similar to
white noise and UL receive gains increase. The IRC algorithm outperforms the maximum
ratio combining (MRC) algorithm in signal demodulation in interference scenarios. The
covariance matrix used for the IRC algorithm requires a high precision in channel evaluation.
This feature applies to the scenarios where interference is strong and interference sources are
densely distributed.
Enhancement
None
Dependencies
An eNodeB must be equipped with two or more receive antennas.
58
2.53.2 TTRFD036103 ICIC
Availability
This feature was introduced in eLTE 3.1.1 and is enhanced in eLTE 3.1.1.
Summary
ICIC implements inter-cell interference mitigation by uplink static ICIC, full edge mode, and UL/DL time domain ICIC. The full edge mode applies to LTE TDD and LTE FDD, whereas uplink static ICIC and UL/DL time domain ICIC apply only to LTE TDD.
Benefits
Inter-cell interference is mitigated, thereby improving CEU throughput and voice quality.
Description
In the LTE system, a cell can use all the frequency bands of the entire system. If multiple cells
are deployed, there is interference between these cells, particularly at the cell edge. In most
cases, transmit frequency bands are coordinated between neighboring cells to mitigate
inter-cell interference.
This feature involves the following three parts:
UL static ICIC: performs frequency domain coordination to divide the entire frequency
band into two or three frequency bands. The central frequency band and cell edge
frequency are fixed, and a different frequency band is used at the edge of each cell to achieve interference suppression.
Full edge mode: is downlink dedicated and uses a principle similar to that for UL static
ICIC. The difference is that the full edge mode allocates UEs to cell edge frequency
bands first regardless of the UE type and then to the central frequency band in the event of insufficient resources.
UL/DL time domain ICIC: performs time domain coordination and takes effect only for
UL and DL semi-persistent services. Different cells are defined with a unique
semi-persistent scheduling (SPS) activation start time based on their physical cell IDs.
Therefore, SPS on different neighboring cells is activated in different DL subframes when the network load is light, which prevents inter-cell interference.
Enhancement
The UL/DL time domain ICI mechanism is added.
Dependencies
The cells in a network or the cells with neighbor relationships have the same frequency and
bandwidth.
UL/DL time domain ICIC requires that the cell bandwidth is smaller than or equal to 5 MHz.
59
2.53.3 TTRFD036104 Inter-RAT Interference Avoiding
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature aims to prevent uplink inter-RAT interference on a cell and applies only to LTE
TDD. With this feature, the eNodeB detects the interference degree on each radio bearer (RB)
in the frequency domain and blocks the RBs on which interference meets the interference
threshold during scheduling.
Benefits
Uplink interference on a cell in the frequency domain is prevented, and therefore, cell uplink
throughput improves in scenarios where interference exists.
Description
An LTE TDD network may overlap with intra-frequency band wireless systems such as
TETRA, GOTA, GT800, and SCDMA in terms of coverage, thereby resulting in interference.
As a result, trunking services and PS services become unstable or even interrupted. This
feature is introduced to identify and prevent inter-RAT interference in the operating
bandwidth.
This feature is implemented as follows:
Measure the interference power of each RB.
Filter the interference power, and compare the power with the interference threshold to
determine whether the RB experiences abnormal interference. If the power is greater
than the interference threshold, it indicates that the RB experiences abnormal interference.
If yes, use the MAC uplink scheduling algorithm to schedule the abnormal RB resources to prevent decrease in uplink throughput.
Enhancement
None
Dependencies
None
2.54 TTRFD0370 BeamForming
Availability
This feature is introduced in eLTE 3.1.1
60
Summary
As a downlink multi-antenna feature, beamforming applies to LTE TDD and improves
throughput, thereby improving user experience.
Benefits
This feature brings array gains for the system, and improves cell coverage and user experience
when channel quality is poor.
Description
With this feature, data is weighted and then transmitted at the transmitter to form a directional
beam toward the target UE, and signals transmitted by multiple antennas are superimposed at
the target UE. This increase the SINR and improves user experience of CEUs. This feature forms
a beam for a UE with a different direction from that for other UEs, as shown in the following
figure. This makes energy become more centralized, thereby mitigating interference in other
UEs.
Cell A
Cell B
Cell C
Enhancement
None
Dependencies
This feature has the following requirements:
The eNodeB must be configured with eight transmit antennas and eight receive antennas, and the LBBPd4 board is required.
This feature only applies to the system bandwidths 20 MHz and 10 MHz.
UEs must support TM7 defined in 3GPP Release 8.
61
2.55 TTRFD0371 TDD Ultra-long-distance Coverage
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature supports special subframe pattern (SSP) 5 and PRACH preamble format 1 or 3.
Theoretically, after this feature is enabled, the maximum cell radius of an LTE TDD cell is 93
km and the maximum cell radius of an LTE FDD cell is 100 km.
Benefits
The cell coverage radius increases. In scenarios where wireless transmission is seldom
blocked by barriers, such as the sea, grassland, desert, and suburban areas, this feature
provides wider cell coverage, thereby reducing the network construction cost.
Description
This feature increases the maximum allowed round-trip delay (RTD) by increasing the GP
length of the special time slot and PRACH detection window length. In an LTE TDD system,
this feature supports SSP5 (indicating that DwPTS:GP:UpPTS = 3:9:2) and PRACH preamble
formats 1 and 2, which helps significantly increase the maximum theoretical cell coverage
radius.
However, the actual cell coverage radius depends on the wireless transmission environment,
eNodeB height, UE height, and frequency band. Generally, Extended Range mainly applies to
the scenarios where:
Wireless transmission is seldom blocked by barriers, such as the sea, grassland, desert,
and rural areas.
The low frequency band is used.
The eNodeB and UE are very high.
Enhancement
None
Dependencies
Only the LBBPd board supports this feature.
The PRACH preamble format 3 applies only to subframe assignment (SA) 0, which indicates
that the uplink and downlink subframe configuration ratio is 3:1.
The PRACH preamble format 1 applies to SA 0 and SA 1. SA 1 indicates that the uplink and
downlink subframe configuration ratio is 2:2.
62
2.56 TTRFD0381 RRU Topology
2.56.1 TTRFD038101 RRU Star Topology
Availability
This feature was introduced in eLTE 3.1.1.
Summary
eNodeBs can be connected in the star topology.
Benefits
This feature offers the following benefits:
Simplified eNodeB networking and management
Higher reliability
Description
Figure 2-3 shows the RRU star topology.
Figure 2-3 RRU star topology
In the star topology, an eNodeB uses the S1 interface to connect to the EPC through the layer
2 or layer 3 network. eLTE 3.1.0 does not support X2 interfaces between eNodeBs.
Enhancement
None
63
Dependencies
None
2.56.2 TTRFD038102 RRU Chain Topology
Availability
This feature was introduced in eLTE 3.1.1.
Summary
eNodeBs can be connected in the chain topology, which applies to strip-shaped areas with a
sparse population.
Benefits
The chain topology reduces costs of transmission equipment, network construction, and
transmission link lease.
Description
Figure 2-4 shows the chain topology.
Figure 2-4 RRU chain topology
In a chain topology, only the first-level RRU is directly connected to a baseband processing
board, and other RRUs are cascaded to their upper-level RRUs one by one. On the chain, the
end directly connected to the BBU is the chain head, and the other end is the chain tail. The
chain tail cannot be connected to the baseband processing board.
Data of a lower-level RRU is forwarded by its upper-level RRUs. The total physical
bandwidth of RRUs in a chain cannot exceed the physical bandwidth capacity of the
connected CPRI port on the baseband processing board.
A maximum of six cascading levels of RRUs are supported on a chain if the physical
bandwidth is sufficient.
Chain topologies apply to long and narrow, and loosely populated areas, such as highways,
railways, and subways. Chain topologies require less optical fibers than other topologies.
Chain topologies are less reliable. If an RRU or the optical channel is faulty, all cells served
by its lower-level RRUs are affected.
Only eRRU3251/3255 supports chain topologies.
64
Enhancement
None
Dependencies
None
2.57 TTRFD0382 RRU Combination
2.57.1 TTRFD038201Multi-RRU Combination
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Multiple RRUs in an eNodeB can serve one cell.
Benefits
Network deployment becomes flexible and network construction and deployment costs
decrease.
Description
Currently, two RRUs can serve one cell.
Requirements for the two RRUs are as follows:
Connect to the same LBBP.
Configured with the bandwidth of 5 MHz, 10 MHz, or 20 MHz. 5 MHz is unavailable
for LTE FDD networks.
Work in 2T2R mode and at the same frequency.
Intra-RRU combination has been available since eLTE 3.1.1. After a 4T4R RRU is configured
as two 2T2R RRUs, the two 2T2R RRUs can be combined into a 2T2R cell.
Enhancement
None
Dependencies
The RRUs connected to the BBU must support this feature.
65
2.57.2 TTRFD038202 Multi-RRU Combination in an Indoor Distributed System
Availability
This feature is introduced in eLTE 3.1.1.
Summary
With this feature, multiple RRUs are configured into one cell in an indoor distributed system,
thereby reducing carrier configurations and handovers. This feature applies to trunking
enterprise networks deployed in coal mines and subways.
Benefits
This feature offers the following benefits:
Reduced carrier configurations
Mitigated cell edge interference in an indoor distributed system
Reduced handovers
Description
This feature mainly applies to indoor distributed scenarios such as coal mines and subways.
Under low traffic, multiple RRUs can be configured to serve one cell. This effectively
mitigates intra-frequency interference in the overlapped areas and reduces handovers.
When the traffic rises, the system capacity can be expanded by reducing the number of
combined cells or expanding the carriers.
Only the LBBPd board supports this feature. A maximum of six 2T2R RRUs with a
bandwidth of 20 MHz, 10 MHz, or 5 MHz can be combined. Downlink signals of the
combined cell are transmitted over the RRUs, and the RRU with the best signal quality is
selected as the target RRU to demodulate uplink signals.
Several channels in an RRU can be combined into a cell. That is, the antennas configured for
one RRU can be multiple 2-channel groups, and these channel groups are combined into one
cell. For example, one 8T8R or 4T4R RRU can be split into multiple 2T2R channel groups. A
maximum of three channel groups can be combined.
Several channels in 2 RRU can be combined into a cell. For example, a 4T4R RRU can be
split into two 2T2R channel groups,and 3 or 4 2T2R channel groups in 2 4T4R RRU can be
combined into a cell.
RRUs in an indoor distributed system can be combined in a star chain, link chain, or mixed
chain.
This feature provides only inter-RRU and intra-RRU combination in the LBBPd board.
This feature applies only when UEs are moving a speed smaller than 120 km/h.
This feature can be used together with remote RRUs.
66
Enhancement
None
Dependencies
The LBBPd board must be configured.
2.58 TTRFD0383 Remotely Installed RRU
Availability
This feature was introduced in eLTE 3.1.1.
Summary
RRUs can be installed far away from a BBU. They are connected to the BBU using optical
fibers. This feature also applies to tower mounting.
Benefits Network coverage expands.
Network construction costs decrease.
Site acquisition becomes easier.
Description LTE TDD network
The maximum distance between a BBU and an RRU is 20 km when the LBBPc board is configured, and is 40 km when the LBBPd board is configured.
LTE FDD network
The maximum distance between a BBU and an RRU is 20 km when the LBBPd board is configured.
Enhancement
None
Dependencies
None
67
2.59 TTRFD0385 VPN
2.59.1 TTRFD038501 Voice Service VPN
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature uses the network infrastructure shared by other groups to combine a virtual
private network (VPN) with functions of private networks for special group users in the
scheduling system. The VPNs work independently from one another.
Benefits
Customers share network infrastructures. Logically, users, groups, scheduling server, audio
and video server, and gateways are divided to own different network permissions.
Description
The unique super administrator of the entire network divides users into different VPNs based
on their telephone numbers, and each VPN is configured with a VPN administrator and VPN
scheduling operator. Then, logical separation is achieved in the following aspects:
VPN-based separation is achieved scheduling and services, including voice services, video services, short messages, multimedia messages, and GIS positioning services.
Security
gateway
eOMC CNDispatcher
VPN subnet 1
Dispatching console + OMC client
VPN subnet 3
Dispatching console + OMC
client
VPN subnet 2
Dispatching console + OMC
client
Control center
Transmission
network
VPN subnet 1VPN subnet 2
VPN subnet 3
Application
server
Central
dispatching console
68
VPN-based management permissions are separated. The administrator can visit data in
the VPN to which it belongs.
A UE or dispatch person can manage user data and service data, and replay audio and video files in the VPN to which it belongs.
The audio and video server or gateway server dedicated to each VPN or shared by all VPNs can be configured.
The super administrator can dynamically or temporarily group users in different VPNs
into a group.
User permissions on VPN outgoing and incoming of PTP calls can be set.
Enhancement
None
Dependencies
None
2.59.2 TTRFD038502 Packet Service VPN
Availability
This feature was introduced in eLTE 3.1.1.
Summary
To support the user’s packet service VPN of the SGI interface, eLTE 3.1.1 will use the VPN
function of the external router or Layer3 switch.
Benefits
This feature provides the private and security VPN channel for the user’s packet service.
Description
The external routers or layer3 switches are deployed at the two sides of eCNS/eSCN and APP
server, the user configures the VPN functions of the routers or layer3 switches to support the
packet service VPN network.
The external routers or layer3 switches support the familiar VPN technologies, such
as:GRE/IPsec/MPLS/L2TP. The VPN networking figure shows as below:
69
Enhancement
None
Dependencies
The feature fully depends on the VPN functions of the external routers or layer3 switches.
2.60 TTRFD0386 Hierarchical Networking
Availability
This feature is introduced in eLTE 3.1.1.
Summary
Multiple dispatchers can be configured in hierarchical mode, of which one serves as the
upper-level dispatcher and the others serve as the lower-level dispatchers. UEs served by the
upper-level dispatcher can initial voice or video calls to those served by the lower-level
dispatchers. UEs served by different lower-level dispatchers can also initiate voice or video
calls to one another.
Benefits
Network coverage is expanded because the emergency communication vehicle which can be
configured in hierarchical mode is used to expand network coverage for the enterprise
network or to fill coverage holes.
Multiple emergency communication vehicles or isolated sites can be configured in
hierarchical mode for multi-level commanding and dispatching.
Description Scenarios
This feature can be used to expand network coverage because the emergency
communication vehicle which can be configured in hierarchical mode is used to expand network coverage for the enterprise network or to fill coverage holes.
Multiple emergency communication vehicles or isolated sites are configured in
hierarchical mode for multi-level commanding and dispatching.
Network architecture
A hierarchical network can be of a star topology, of which, one dispatcher serves as the
upper-level dispatcher and other dispatchers serve as lower-level dispatchers. The
upper-level dispatcher can be the intelligent network or an emergency communication
vehicle, and the lower-level dispatcher can be an emergency communication vehicle or a fixed isolated site. Figure 2-5 shows the network architecture of a hierarchical network.
70
Figure 2-5 Network architecture
Dispatching
consoleDevice on the
enterprise network
Dispatcher
Dispatcher
Device on the
enterprise network
Dispatching
console
Dispatching
console
Device on the
enterprise network
Dispatcher
Functions
− Each dispatching system in the hierarchical network is a whole dispatching system
and all functions of an individual dispatching system are available in the hierarchical
network.
− On a hierarchical network, the upper-level and lower-level dispatchers can work in
hierarchical mode or independently. However, voice or video service message
exchanged between two UEs served by different lower-level dispatchers must be transferred through the upper-level dispatcher.
− Physical transmissions are performed between the upper-level and lower-level
dispatchers. On a dual-level dispatching network, mutual transmission is optional.
− Voice PTP calls can be initiated between UEs served by upper-level and lower-level dispatchers, or between UEs served by the lower-level dispatchers.
− Voice group calls can be initiated between UEs served by upper-level and lower-level dispatchers, or between UEs served by the lower-level dispatchers.
− Emergency calls can be initiated between UEs served by upper-level and lower-level
dispatchers, or between UEs served by the lower-level dispatchers.
− Video feedback services can be initiated between UEs served by upper-level and lower-level dispatchers, or between UEs served by the lower-level dispatchers.
− The upper-level dispatching console can initiate video distribution services on UEs served by the lower-level dispatchers.
Principle
− Registration configuration
A sub network is managed by an eOMC. Therefore, registration on an eOMC takes effect only on the dispatchers and CN in the subnet managed by the eOMC.
− Limitations
Two eOMCs are provided to separately manage the upper-level and lower-level
dispatchers. Information of UEs that are registered on the upper-level and lower-level dispatchers is separately stored on related eOMCs.
Registration of users, groups, and dispatch persons on multiple UEs needs to be
manually implemented. For registration of groups in different levels of sub networks,
the upper-level dispatch person must ensure that registration information on the upper-level and lower-level sub networks is consistent.
71
− Service process
Services are set up between UEs served by different dispatchers through an SIP
signaling procedure. When a voice or video service needs to be set up, SIP signaling
messages are exchanged between dispatchers. If the service is set up between two
lower-level dispatchers, the SIP signaling messages are transferred over the
upper-level dispatcher.
The SIP signaling procedures for setting up various services on a hierarchical
network are similar. Figure 2-6 uses the voice PTP call as an example to illustrate the
procedure, in which, the UBP serves as a dispatcher, the BCC serves as a dispatcher
control plane processing module, and the BDC serves as a dispatcher user plane
processing module.
Figure 2-6 SIP signaling procedure for voice PTP calls
Lower-level
CNS1
Lower-level
UBP1
Upper-
level
CNS2
Upper-level
UBP2
PTT speaker
UE1
UE2
NAS
Invite/180Ring/200OK
NAS
Invite/180Ring/200OK
Invite/180Ring/200OK
Signaling
Voice
The SIP signaling procedure is detailed as follows:
Step 2 Upon receiving an INVITE message forwarded by the CN, UBP1 replies with a 100Tring
message. In hierarchical networking mode, if UBP1 finds that it does not serve the called
party based on number analysis, UBP1 sends UBP2 the INVITE message that carries the
dialog ID and RTP port allocated to UBP1.
Step 3 Upon receiving the forwarded INVITE message, UBP2 replies to UBP1 with a 100Tring
message. If the called party is served by UBP2, UBP2 sends the CN an INVITE message that
contains the dialog and RTP port allocated to UBP2.
Step 4 After control plane message exchange on the called party is complete on the CN and UE, the
called party rings. Then UBP2 sends the 180Ring message to the calling party through UBP1.
Step 5 After the called party hangs up, the CN that the called party camps on sends UBP2 with a 200
OK message that carries information about the RTP port on the CN. Then, UBP2 establishes
the RTP user plane toward the CN that the called party camps on.
Step 6 UBP2 sends UBP1 the 200 OK message that carries information about the RTP ports
corresponding to UBP1 and UBP2.
Step 7 Upon receiving the 200 OK message, UBP1 connects to the RTP user plane between UBP1
and UBP2 based on the carried information about RTP ports.
72
Step 8 UBP1 sends the 200 OK message to the CN that the calling party camps on and establishes
the RTP user plane toward the CN.
----End
Enhancement
None
Dependencies
None
2.61 TTRFD0387 Routing Behind MS
Availability
This feature is introduced in eLTE 3.1.1.
Summary
Routing Behind MS enables multiple UEs that are connected to the CPE through Wi-Fi or the
Ethernet to remotely access the enterprise network and implements data exchange between
the UEs and devices on the network side.
Benefits
If multiple UEs remotely access the enterprise network through a wireless device, NAT
conversion is performed on the wireless device. However, this applies only to unidirectional
data services sent by the UEs. Routing Behind MS is introduced to implement bidirectional
data exchange between the UEs and enterprise network.
Routing Behind MS supports mutual access between the branch devices, and between the
branch devices and enterprise network devices. This makes access between the branch devices
and enterprise network devices become flexible, fast, and secure.
Description
One or more EPS bearers can be established between the CN and CPE. In the downlink, the
CN forwards the unicast service IP packet streams over the SGi interface to the specified CPE
through a LAN port without any change. In the uplink, the CPE forwards the unicast service
IP packet streams over the LAN port to the CN without any change. This forms a direct
mutual access between the enterprise network and CPE branch offices and between the CPE
branch offices.
During forwarding, filtering rules can be configured to map different forwarded service data
streams to different EPS bearers.
73
10.2.2.0/24
10.2.3.0/24
10.1.0.0/16
eSCNeCNS
Router
Headquarters
Branch A
Branch B
CPE
CPE
WIFI
Ethernet
Enhancement
None
Dependencies
None
2.62 TTRFD0401 Audio and Video Recording
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The dispatch person can record voice and video services.
Benefits
The dispatch person can review voice and video recording files.
Description
This feature implements the following functions:
Stores, queries, deletes, and exports audio and video recordings, including
− Audio and video recording on PTP calls, group calls, video upload, and fixed cameras
− Audio recording on PTP video calls
− Query, replay, and export of audio and video files on the WebLMT based on the group or UEs and duration
Triggers and stops local audio and video recording on the dispatching console
The UEs and groups, on which audio and video recording is performed, can be preset.
74
Enhancement
None
Dependencies
None
2.63 TTRFD0402 Charging
2.63.1 TTRFD040201 PS Charging
Availability
This feature is introduced in eLTE 3.1.1.
Summary
The eCNS210 can export 3GPP-compliant PGW-CDR used for charging offline PS traffic. By
interconnecting with the CG and the third-party charging system, the eCNS210 provides the
PS charging scheme compatible with the LTE public network.
Benefits
This feature meets the customer requirements for offline PS charging.
Description
The gateway module of the eCNS210 provides the PGW-CDR, which is then sent to the CG
over the Ga interface. The CG receives, stores, and converts the PGW-CDR into the final
CDR required by the charging system, and sends the final CDR to the charging system.
The following figure shows the typical networking for implementing charging.
75
eCNS210
Ga interface (GTP)
CG9812 Charging system provided
by the customer
Bi interface (FTP)
eOMC
eOMC interface
LTM/WEBUI
OM interface
LMT/WEBUI
Enhancement
None
Dependencies
None
2.64 TTRFD0403 Roaming
2.64.1 TTRFD040301 PS Roaming
Availability
This feature is introduced in eLTE 3.1.1.
Summary
Roaming is provided for PS services among eCNS210s.
Benefits
Several eCNS210s can be deployed in the same network to expand the network coverage.
Description
PS services can roam among eCNS210s in a pure broadband access system by using the
specially established channels.
76
The UE under coverage of an eNB managed by an eCNS210 is able to obtain services from
another eNB managed by another eCNS210 anywhere else.
The UE that is powered on without the coverage of a home eSCN210 can be identified and
authorized by connecting to the home eCNS210.
The UE that leaves the coverage of a home eSCN210 due to a TA change can send user
information requests and updates to the home eSCN210 when initiating a track area update
(TAU) procedure.
Enhancement
None
Dependencies
None
2.65 TTRFD0404 Service Identification by SPI
Availability
This feature is introduced in eLTE 3.1.1.
Summary
In eLTE 3.1.1, only the UEs could initiate bearer setup requests, and the network side could
not initiate bearer setup or modification requests. This may not meet customer requirements
for QoS guarantee because certain services may be required to be preferentially guaranteed.
This feature identifies service flows and guarantees QoS by Shallow Packet Inspection (SPI).
Benefits
This feature provides flexible QoS guarantee for the customer.
Description
Shallow Packet Inspection refers to inspection of the 5-tuple contained in the IP header
transmitted at Layer 3 or 4. The 5-tuple includes source IP address, destination IP address,
source port, destination port, and protocol type. SPI-based QoS policy control analyzes the
5-tuple in the IP header to determine the basic service flow information, thereby identifying
service flows and guaranteeing QoS. SPI includes two parts: shallow service identification
and initiating dedicated bearer setup and modification request by the network side.
Related QoS policies are configured on the CN. The system identifies and parses uplink and
downlink data packets of UEs performing service access. Then, the system applies different
control policies to different service types. QoS policies can be based on user types or service
types.
User type-based policy control: Users are classified into different types based on the IMSI segments. The service control policies vary with user types.
Service type-based policy control: The service control policies vary with service types. For example, specific policies are applied to FTP services.
77
New dedicated bearers are established only if the QCI and ARP of new service flows are
different from those of existing dedicated bearers. Normally, new service flows are bound to
the existing dedicated bearer with the same QCI and ARP, and the MBR and GBR are
accumulated.
Enhancement
None
Dependencies
None
2.66 TTRFD0501 Interworking with PSTN
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Users in a trunking enterprise network make point-to-point (P2P) calls with users on the
public network, that is, PSTN and PLMN users.
Benefits
Users in a trunking enterprise network can communicate with users on the public network.
Description The trunking enterprise network interworks with the PSTN through the PSTN gateway.
Users on the trunking enterprise network can make P2P calls to public land mobile network (PLMN) and public switched telephone network (PSTN) users.
PSTN and PLMN users can make P2P calls to users on the trunking enterprise network.
The foreign exchange station (FXS) interface on the PSTN gateway is directly connected
to the trunking enterprise network. The foreign exchange office (FXO) and E1 interfaces support two-stage dialing.
The PSTN gateway can be installed on the communication vehicle. In this case, the E1 interface is not supported.
Enhancement
None
Dependencies
None
78
2.67 TTRFD0502 Interworking with TETRA
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Users in a trunking enterprise network make group calls with TErrestrial Trunked RAdio
(TETRA) users through the TETRA gateway.
Benefits
Users in a trunking enterprise network can communicate with TETRA users.
Description
The TETRA gateway can be configured for the trunking enterprise network to support interworking with TETRA users.
TETRA users can be added to group calls in the trunking enterprise network.
TETRA users can initiate group calls in the trunking enterprise network.
TETRA users can preempt or release the floor.
The TETRA gateway can be installed on the communication vehicle.
Enhancement
None
Dependencies
None
2.68 TTRFD0503 Interworking with PLMN
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Users in a trunking enterprise network make P2P calls with users on the public network, that
is, PLMN and PSTN users.
Benefits
Users in a trunking enterprise network can communicate with users on the public network.
79
Description
This feature implements the following functions:
The trunking enterprise network interworks with the PLMN through the PLMN gateway.
The PSTN and PLMN users can access services over the GSM/CDMA air interface.
Users on the trunking enterprise network can make P2P calls to PSTN and PLMN users.
The PSTN and PLMN users can make P2P calls to users on the trunking enterprise network.
Enhancement
None
Dependencies
None
2.69 TTRFD0504 Interworking with USW/SW Radio Station and 350 MHz MPT1327 Users
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Users in a trunking enterprise network make group calls with ultrashort wave (USW) or short
wave (SW) radio station and 350 MHz MPT1327 users over the air interface.
Benefits
Users in a trunking enterprise network can communicate with USW/SW radio station and 350
MHz MPT1327 users.
Description
This feature implements the following functions:
Adds USW/SW radio station and 350 MHz MPT1327 users to group calls or allows them to initiate group calls.
Allows USW/SW radio station and 350 MHz MPT1327 users to initiate group calls and preempt or release the floor.
Sets up a maximum of four group calls.
Enhancement
None
80
Dependencies
None
2.70 TTRFD0505 SIP Interface
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The SIP interface is available for SIP-based service systems.
Benefits
Trunking enterprise networks can communicate with SIP-based service systems.
Description
A trunking enterprise network can implement the following services with a SIP-based service
system over the SIP interface:
P2P voice calls
Group calls
Video monitoring services
Enhancement
None
Dependencies
None
2.71 TTRFD0601 Communication From Immobility
Availability
The feature in the case of vehicle-mounted rapid deployment was introduced in eLTE 3.1.1.
Summary
Cell coverage provided by a vehicle-mounted base station is achieved when an emergency
dispatch vehicle or vehicle-mounted rapid deployment system is in the static state.
81
Benefits
Wireless communication is implemented when an emergency dispatch vehicle or
vehicle-mounted rapid deployment system is in the static state.
Description
An emergency dispatch vehicle in the static state uses cells of communication from
immobility to provide wireless coverage. Users in the cells can perform trunking voice and
data services. 1.4 GHz and 1.8 GHz emergency dispatch vehicles provide three-sector cell
coverage and 400 MHz emergency dispatch vehicles provide omnidirectional coverage by a
single cell.
The vehicle-mounted rapid deployment system in the static state uses cell of communication
from immobility to provide wireless coverage. Users in the cell can perform trunking voice
and data services. 1.8 GHz and 400 MHz vehicle-mounted rapid deployment system provides
omnidirectional coverage by a single cell.
Enhancement
None
Dependencies
None
2.72 TTRFD0602 Communication on the Move
Availability
The feature in the case of vehicle-mounted rapid deployment was introduced in eLTE 3.1.1.
Summary
Cell coverage provided by a vehicle-mounted base station is achieved when an emergency
dispatch vehicle or vehicle-mounted rapid deployment system is on the move.
Benefits
Wireless communication is implemented when an emergency dispatch vehicle or
vehicle-mounted rapid deployment system is on the move.
Description
An emergency dispatch vehicle on the move uses cells of communication on the move to
provide wireless coverage. 1.4 GHz, 1.8 GHz, and 400 MHz emergency dispatch vehicles
provide omnidirectional coverage by a single cell.
The vehicle-mounted rapid deployment system on the move uses cell of communication on
the move to provide wireless coverage. Users in the cell can perform trunking voice and data
services. 1.8 GHz, and 400 MHz vehicle-mounted rapid deployment system provides
omnidirectional coverage by a single cell.
82
Enhancement
None
Dependencies
None
2.73 TTRFD0603 Switch Between Communication From Immobility and Communication on the Move by One Click
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Cells of communication from immobility and communication on the move can be switched by
one click in an emergency dispatch vehicle.
Benefits
Cell coverage modes can be switched by one click when an emergency vehicle shifts between
the static state and the moving state.
Description
Cells of communication from immobility and cells of communication on the move are
configured on a base station mounted on an emergency vehicle. When the emergency vehicle
shifts between the moving state and the static state, an interface is used to switch cells of
communication from immobility and cells of communication on the move accordingly.
Enhancement
None
Dependencies
None
2.74 TTRFD0651 Dispatching Console API SDK
Availability
This feature was introduced in eLTE 3.1.1.
83
Summary
The software development kit (SDK) is provided for enterprise users to develop the
third-party dispatching console.
Benefits
Enterprise users can develop the third-party dispatching console.
Description
The SDK provides the application interface of all services for the dispatching console of
enterprise networks and can be used to develop a third-party dispatching console. These
services include voice, video, SMS, MMS, and GIS positioning services.
A third-party dispatching console can obtain information and status of users and group calls.
The SDK development manual can be provided to the third party.
Enhancement
None
Dependencies
The scheduler must support trunking services.
2.75 TTRFD0652 Terminal Further Development based Portable Handset
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The cooperators can develop UEs and client software by using EM350 or EM350-D61 cards.
Benefits
The EM350 or EM350-D61 cards can function as the modem platform provided for the
cooperator. The cooperator can use such platforms together with the APP system to develop
various types of UEs and client software.
Description
The following table describes the frequency bands and bandwidths supported by EM350 and
EM350-D61 cards.
84
Card Frequency Band Bandwidth
EM350 1.4 GHz: 1447-1467
MHz
5 MHz, 10 MHz, and 20 MHz
1.8 GHz: 1785-1805
MHz
5 MHz, 10 MHz, and 20 MHz
800 MHz (band 20):
832-862 MHz in the
uplink
792-821 MHz in the downlink
5 MHz
EM350-D61 400 M: 380-470 MHz 3 MHz, 5 MHz, 10 MHz, and 20
MHz
The EM350 card provides the following external interfaces:
Two antenna interfaces (50 ohms, 1T2R)
UART serial interface
USB2.0 Slave interface, which transmits inter-AP data and AT control signaling.
Voice and data interfaces, include:
A series of mono PCM interfaces for digital voice services
Analog voice input (differential MIC) and output (speaker) interface
USIM card interface
Power amplifier (PA) interface for 1.4 GHz or 1.8 GHz frequency band (EM350 card)
and 400 MHz frequency band (EM350-D61 card)
Interface for fast establishment of PTT services
Interface for CP sleep status and AP sleep status to ensure low power consumption
The EM350 provides the following functions:
Implements data services and trunking services on the modem side. The cooperator can
develop UEs capable of data services and trunking services based on the EM350 modem
platform.
Supports AMR 12.2 Kbit/s and AMR 4.75 Kbit/s and provides a complete voice service
solution. The cooperator can use PCM digital service or analog voice to develop UEs capable of voice services based on the EM350.
Provides the interface for maintenance and test logs and supports offline upload of the
logs on the modem to the APP system. This facilitates the development, debugging, and
maintenance of the cooperator.
Supports the layout debugging environment used by Windows XP. This environment supports AT and service debugging by using Windows.
Enhancement
None
85
Dependencies
None
2.76 TTRFD0653 Terminal Further Development based EM350
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature provides a software package for UE manufacturers to further develop UE
software.
After integrating the package into the Android operating system on UEs, UE manufacturers
can modify the Android software so that PTT services are available on UEs.
Benefits
This feature enables PTT services on UEs and reduces UE manufacturers' development
workload.
Description
The UE software further development package consists of the following files:
PTT installation package (*.apk) for providing PTT services on UEs
Framework installation package (*.jar) for implementing the PTT signaling flows and UE resource conflict management
Native layer library file (*.so) for delivering AT commands to eCPs
UE software further development guide
To implement PTT services on UEs, the UE software further development package provides the following interfaces for UEs:
PTT service interface
Interface for managing UE resource conflicts
Bottom-layer driver interface
This interface defines the displays PTT service requirements for bottom-layer drivers. To
implement PTT services, UE manufacturers must modify bottom-layer drivers based on these requirements.
Key adaptation interface
This interface allows users to perform PTT services using UE keys.
Enhancement
None
86
Dependencies
UEs must run the Android operating system.
2.77 TTRFD0701 IP Transmission
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The evolved core network system (eCNS), evolved smart core switch node (eSCN), and
eNodeB support the following basic IP transmission functions:
Ethernet layer 2 forwarding
IP route forwarding
TCP-based transmission
UDP-based transmission
The eCNS, eSCN, and eNodeB also support Ethernet QoS-related features, such as trunking,
virtual local area network (VLAN), and differentiated services code point (DSCP).
Benefits
This feature implements IP transmission in trunking enterprise networks and supports
multiple transmission networking modes.
Description
The eCNS, eSCN, and eNodeB perform the following functions:
Manage physical ports.
Configure port IP addresses.
Support the layer 2 or layer 3 transmission network.
Forward packets on static routes.
A static route is a route that is manually configured for transmitting packets to a network
or device. An NE can communicate with the peer device through a static route and send packets to the destination IP address in the specified path.
Support the layer 2 VPN.
In addition, the evolved operation and maintenance center (eOMC) supports remote
self-deployment of eNodeBs based on the Dynamic Host Configuration Protocol (DHCP),
and the eCNS supports the virtual routing and forwarding (VRF) function.
Enhancement
None
87
Dependencies
None
2.78 TTRFD0801 Authentication
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The authentication feature enables the eCNS or eSCN to identify and authenticate UEs and
synchronize keys with UEs.
When this feature is enabled, the eCNS/eSCN checks the requests from UEs and allows only
authorized UEs to use services in networks.
In addition, UEs can authenticate the eCNS/eSCN.
Benefits
This feature offers the following benefits:
Prevents unauthorized UE access to networks.
Reduces UE security risks caused by access to unauthorized networks.
Description
This feature applies only to the UEs equipped with UMTS subscriber identity modules
(USIMs).
The authentication vector consists of the following items:
Random challenge (RAND)
A RAND is a random number consisting of 16 bytes. The eCNS/eSCN sends it to a UE.
Authentication token (AUTN)
An AUTN consists of 16 bytes. The UE uses it to authenticate the eCNS/eSCN.
Expected response (XRES)
An XRES is the UE response that the eCNS/eSCN expects. It consists of 4 to 16 bytes.
The eCNS/eSCN compares it with the user response (RES) or RES+RES_EXT
calculated by the UE. If they are consistent, the UE has been authenticated. Otherwise, the UE fails to be authenticated.
Key ASME (KASME)
The KASME is a 32-byte root key that the UE calculates using the cipher key (CK) or
integrity key (IK) and the PLMN ID of the Access Security Management Entity
(ASME).
In the LTE system, the eCNS functions as the ASME.
NOTE
88
UE eNodeBeCNS/eSCN
(integrated with the HSS)
Authentication Request
Authentication Response
The authentication procedure is as follows:
1. The eCNS/eSCN sends the home subscriber server (HSS) an Authentication Information
Request message to request the authentication vector. The message contains the
international mobile subscriber identity (IMSI) of the UE, service node (SN) ID, and network type (NT).
2. Upon receiving the Authentication Information Request message, the HSS sends the
eCNS/eSCN an Authentication Information Response message containing the
authentication vector. If the eCNS/eSCN requests multiple authentication vectors, the HSS numbers the vectors and sends them to the eCNS/eSCN in sequence.
3. The eCNS/eSCN sends an Authentication Request message to the UE to trigger
authentication. The message contains the RAND, AUTN, and KSIASME. KSI is short
for key set identifier.
4. The UE sends an Authentication Response message to the eCNS/eSCN and uses the AUTN to authenticate the eCNS/eSCN.
− If the eCNS/eSCN fails to be authenticated, the UE sends the eCNS/eSCN an Authentication Failure message with the failure cause.
− If the eCNS/eSCN has been authenticated, the UE calculates the RES based on the
RAND and sends the RES to the eCNS/eSCN. The eCNS/eSCN then compares the
RES with the XRES in the authentication vector. If they are consistent, the UE has
been authenticated. Otherwise, the UE fails to be authenticated, and the eCNS/eSCN sends an Authentication Reject message to the UE.
When both the UE and eCNS/eSCN have been authenticated, the UE calculates and saves the
KASME for encryption and integrity protection.
In addition, the eCNS/eSCN can request an authentication vector set in advance. Before the
authentication vectors in a set are used up, the eCNS/eSCN actively requests a new
authentication vector set from the HSS. As a result, UE access duration decreases and user
experience improves.
Enhancement
None
Dependencies
None
89
2.79 TTRFD0802 Air Interface Data Encryption
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature provides confidentiality protection for both signaling and user data between an
eNodeB and UEs.
Benefits
This feature prevents unauthorized interception and modifications.
Description
This feature implements encryption using the AES algorithm and decryption. In the LTE
system, radio resource control (RRC) signaling and user data are encrypted and decrypted at
the Packet Data Convergence Protocol (PDCP) layer. After an eNodeB receives UE context
from the EPC, the encryption function is activated by the initial security activation procedure.
After the RRC connection is established, the eNodeB exchanges RRC signaling messages
with the UE to negotiate the encryption algorithm and key, which apply to all radio bearers
between the eNodeB and UE.
The encryption algorithm and key can be changed during a handover.
Enhancement
None
Dependencies
None
2.80 TTRFD0803 End-to-End Encryption
2.80.1 TTRFD080301 Group call Encryption
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports trunking group call encryption.
Benefits
Encrypt the PTT voice stream, and prevent eavesdropping on the sensitive communication.
90
Description
The Terminal that supports E2E encryption should equip the TF encipher card, which can be
authenticated by the KDC (Key Distribution Center). When the user initiates the enciphered
PTT communication, KDC will distribute the session key to all the terminals in the PTT group.
The speaker will encipher the voice stream by the TF module, and the receivers will decipher
the voice steam with the same session key.
Enhancement
None
Dependencies
TTRFD0201 Trunking Group Call
2.80.2 TTRFD080302 Point to Point Call Encryption
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports private call end-to-end encryption.
Benefits
Encrypt the private call voice stream, and prevent eavesdropping on the sensitive
communication.
Description
The Terminal that supports E2E encryption should equip the TF encipher card, which can be
authenticated by the KDC (Key Distribution Center). When the user initiates the enciphered
private call, KDC will distribute the session key to caller and callee. The caller will encipher
the voice stream by the TF module, and the callee will decipher the voice steam with the same
session key.
Enhancement
None
Dependencies
TTRFD0101 Private Call.
91
2.80.3 TTRFD080303 Short Data Service Encryption
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature supports short data encryption.
Benefits
User can encrypt the short data, including short messages and multimedia messages, in order
to protect the sensitive messages.
Description
The Terminal that supports E2E encryption should equip the TF encipher card, which can be
authenticated by the KDC (Key Distribution Center). When the user sends the short data in
encryption mode, KDC can generate the encipher key. The sender encrypts the short data with
encipher key and the receiver decipher the message with the same key.
Enhancement
None
Dependencies
TTRFD0124 Short Data Service
2.81 TTRFD0804 Integrity Protection
Availability
This feature was introduced in eLTE 3.1.1.
Summary
This feature implements encryption and integrity protection for non-access stratum (NAS)
signaling and RRC signaling.
Benefits
This feature guarantees signaling data integrity and transmission reliability, and therefore
improves user satisfaction.
Description
This feature uses two security mechanisms for signaling data between UEs and the EPS.
RRC security mechanism
92
The eNodeB and UE negotiate the algorithm and key for RRC signaling integrity
protection and encryption. The algorithm and key are sent in the access stratum (AS) Security Mode Command message.
NAS security mechanism
The eCNS/eSCN and UE negotiate the algorithm and key for NAS signaling integrity
protection and encryption. The algorithm and key are sent in the NAS Security Mode
Command message.
The eCNS/eSCN supports the following algorithms:
Null ciphering algorithm for encryption
Advanced Encryption Standard (AES) and SNOW 3G for integrity protection and encryption
On the UE: After receiving the NAS Security Mode Command message and authenticating the
eCNS/eSCN, the UE performs integrity protection and encryption for uplink NAS signaling.
On the eCNS/eSCN:
− After sending the NAS Security Mode Command message, the eCNS/eSCN performs integrity protection of downlink NAS signaling.
− After receiving the NAS Security Mode Complete message, the eCNS/eSCN encrypts downlink NAS signaling.
− After sending the NAS Security Mode Command message, the eCNS/eSCN decrypts
uplink NAS signaling.
Enhancement
None
Dependencies
None
NAS
PDCP PDCP
NAS
eNodeB
NAS encryption/integrity
RRC encryption/integrity
User plane encryption
UE MME
93
2.82 TTRFD0901 FlowControl
Availability
This feature was introduced in eLTE 3.1.1.
Summary
If the system central processing unit (CPU) usage exceeds the specified threshold, flow
control automatically rejects new service access or stops signaling tracing and log recording
to prevent system crashes caused by long-term overload.
Benefits
This feature prevents system crashes caused by long-term overload and improves network
reliability.
Description
Flow control can monitor the resource usage, such as the CPU usage. If the resource usage
exceeds the specified threshold, the system takes the following measures to reduce further
resource usage:
Rejects new service access.
Stops signaling tracing and log recording.
When the system load returns to normal, the overload control measures no longer take effect
and the system works properly.
When the system is overloaded, the operation and maintenance center (OMC) can still access
and maintain the system. In addition, alarms on the OMC help maintenance personnel solve
problems.
Enhancement
None
Dependencies
None
2.83 TTRFD0903 CN Reliability
2.83.1 TTRFD090301 CN Board Redundancy
Availability
This feature was introduced in eLTE 3.1.1.
94
Summary
Distributed software and hardware structure and hardware redundancy improves eCNS
hardware reliability.
Different modules have different functions and each module works independently. If one module is faulty, other modules are not affected and the system can still work properly.
Key components adopt redundancy technique. For example, the enhanced service unit
(ESU) works in active and standby mode. The active ESU controls the module and the
standby ESU synchronizes and backs up data of the active ESU. If the active ESU is
faulty, the standby ESU takes over as the active ESU to control the module. In this way, services can continue without interruption.
Benefits
This feature improves equipment reliability.
Description
All boards in the EPC support redundancy backup. The following table describes the board
backup modes.
Board Type Board Name Backup Mode
Maintenance board Operation and maintenance unit
(OMU)
1+1 cold backup
System board Switch unit (SWU) 1+1 load sharing
Shelf management Unit (SMU) 1+1 hot backup
Service board ESU 1+1 process-level hot backup
Interface board Universal service interface (USI) 1+1 cold backup
Switch interface (SWI) 1+1 load sharing
Shelf data module (SDM) 1+1 hot backup
Quad-port 10GE rear interface
(QXI)
1+1 hot backup or 1+1 load
sharing
Enhancement
None
Dependencies
None
95
2.83.2 TTRFD090302 S1-flex
Availability
This feature was introduced in eLTE 3.1.1.
Summary
S1-flex enables one eNodeB to set up S1-MME connections to multiple MMEs, which form a
resource pool known as an MME pool. When a UE accesses the network through an eNodeB,
the eNodeB selects a serving MME for the UE and sets up a dedicated S1-MME connection.
If an MME is faulty and a UE initiates a service request, the eNodeB selects another available
MME to avoid service interruption.
Benefits
The MME backup function is available for disaster tolerance, which improves MME
reliability.
Description
Two MMEs in a resource pool work simultaneously, and are connected to all eNodeBs in the
MME pool area. Different UEs access different MMEs to perform services in load sharing
mode. If one MME is faulty, the eNodeB selects another EPC to perform services. Therefore,
network reliability is improved.
The following figure shows the logical connection of NEs.
The eNodeBs in the disaster tolerance area must connect to both MME A and MME B. The
two MMEs work properly, and status and configuration data synchronization is not required
between them. However, subscription data on both MMEs must be the same. The transport
network configuration varies with application scenarios.
96
The following figure shows load sharing between different MMEs.
Enhancement
None
Dependencies
None
2.83.3 TTRFD090303 CN Geographical Redundancy
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature implements NE-level 1+1 cold redundancy of CNs by reuse the S1-flex load
balancing algorithm.
97
The active and standby NEs will periodically check the status of each other by use
handshaking. If the active NE becomes faulty, the standby NE detects the fault by heartbeat
detection, and then switches to the active state, meanwhile, the related alarms will be reported
to the NMS.
Benefits
This feature provides NE-level cold redundancy of CNs in case of regional disasters. The
active/standby switchover is a cold switchover. That is, all services carried on the NE that
switches from the active to standby state are interrupted. The NE that switches from the
standby to active state can admit new services within 3 minutes.
Description
The heartbeat connection is enabled between the active and standby CNs, and the UEs' TAIs
and Attach/ Detach status are backed up during heartbeat shakes.
The two CNs are deployed in different areas and are represented by two NEs with different
MME IDs in the network topology. The two CNs are both connected to the eNodeBs,
dispatcher, and the eOMC.
Currently, configuration data and subscription data cannot be synchronized between the active
and standby CNs. Therefore, the eOMC is required to ensure data consistency between them.
After S10 link is configured, the two CNs compete for the active role over the S10 link. After
the competition is complete, UEs can query the active/standby status of the two CNs through
the eOMC. The active and standby CNs send the STOP OVERLOAD message and the
START OVERLOAD message, respectively, over the S1 interface.
On the enterprise network system, if an NE enters the OVERLOAD status or its
corresponding link is disconnected, the eNodeB will not allocate services to this NE based on
the S1Flex load balancing algorithm.
Each time a CN NE starts or the OVERLOAD status changes, the CN notifies the eNodeB
and dispatcher of the active/standby status change.
The following figure shows the data flow changes caused by active/standby switchovers of
CNs.
98
CN
dispatcher
eOMC servereOMC server
dispatcher
CN
Transport
network
APS
X
Group call/point-to-
point call uplink
Group call/point-to-
point call downink
PS uplink and
downlink
If the standby CN detects that the active CN has lost the heartbeat, the standby CN reports the
heartbeat fault alarm and sends the STOP OVERLOAD message to switch to the active state.
After the eNodeB is informed of the OVERLOAD status change between the active and
standby CNs, the eNodeB instructs UEs to access the new active CN in the uplink based on
the S1Flex load balancing algorithm.
Enhancement
None
Dependencies
None
2.84 TTRFD0904 NodeB Reliability
2.84.1 TTRFD090401 Single RRU Cold Ring Backup
Availability
This feature was introduced in eLTE 3.1.1.
Summary
In CPRI topology, the BBU and RRUs form a ring topology. A unidirectional ring topology
can be regarded as two unidirectional chains.
99
Benefits
This feature improves CPRI link reliability.
Description
Unidirectional ring mode includes the cold ring mode and hot ring mode.
The cold ring mode adopts cold backup. In the cold ring mode, data is transmitted only on the link in use.
The hot ring mode adopts hot backup. In the hot ring mode, the same IQ data is
transmitted on two links simultaneously.
eLTE 3.1.1 supports only unidirectional cold ring backup. Unidirectional ring cold backup
includes intra-board and inter-board ring cold backup. eLTE 3.1.1 supports only intra-board
ring cold backup.
Enhancement
None
Dependencies
None
2.84.2 TTRFD090402 NodeB board Redundancy
Availability
This feature was introduced in eLTE 3.1.1.
Summary
A cell can be reestablished on another LBBP with available resources or on a backup LBBP.
Benefits
This feature improves system reliability.
Description
If an LBBP is faulty or its resources are insufficient, the cell served by the LBBP cannot be
dynamically reestablished on the LBBP. With inter-LBBP redundancy, the cell can be
reestablished on another LBBP with available resources or on a backup LBBP. In this way,
services in the cell can automatically recover and service interruption duration is reduced.
The following figure shows the topology of three 10 MHz 2T2R RRUs with CPRI backup.
100
A red line in the figure represents a link between the LRRU and the source LBBP, and a green
line represents a link between the LRRU and the target LBBP. In the preceding figure, the
eNodeB is configured with two LBBPs. When one LBBP is faulty, the eNodeB can detect and
locate the fault, and then selects another LBBP to reestablish the cell. The target LBBP is
connected to the RRU using a CPRI port and provides services for the cell.
One or more cells can be established on an LBBP.
The target LBBP is selected based on the remaining resources of the LBBP.
Enhancement
None
Dependencies
None
2.84.3 TTRFD090403 Fallback Mode
Availability
This feature is introduced in eLTE 3.1.1.
Summary
This feature allows the eNodeB disconnected from the CN to support basic functions of PTP
calls and group calls within its coverage area.
Benefits
This feature improves system reliability.
101
Description After faults occur in the CN or the transmission between the eNodeB and the CN, this
feature guarantees the basic PTP calls and group calls function within the coverage area
of the eNodeB. After the faults are rectified, the eNodeB automatically recover the normal running status. These basic functions include:
− Registration under a single eNodeB
− Group calls (including the setup, floor application and release, and shutdown of
group calls) under a single eNodeB
− Emergency calls under a single faulty eNodeB
− Late entry under a single faulty eNodeB
− Calling name presentation under a single eNodeB
− Notification of entering or exiting the single faulty eNodeB mode to the peer end
After the eNodeB enters the fault weakening mode, it supports PTP calls under its
coverage area.
The mobility management processes, such as inter-cell handovers and tracking area update (TAU), are supported.
For the eNodeB configured with the license for fault weakening, a new MPT board needs to be configured as the standby built-in CN.
The routine maintenance and software upgrade of the standby CN of fault weakening are
supported.
The following figure shows the implementation before fault weakening is enabled:
COR
E0
COR
E1
COR
E2
TRAN
COR
E0
COR
E1
COR
E2
TRAN
LS
W
LS
WMDS
eNB
CNPU
AP
eCN
S
eOMC
SCTP signaling
PS user plane
CS user plane
Before fault weakening:
The transmission connection between the eNodeB and the eCNS is functional.
The SCTP signaling plane over the S1 interface is established between the eCNS and the eNodeB.
The MDC ultimately connects the CS user plane.
The eCNS completes conversion between the eNodeB and the AP.
An SCTP link between the eNodeB MPT and the built-in CN board (CNPU shown in the
following figure) can be set up in advance to facilitate activation of fault weakening.
The following figure shows the implementation after fault weakening is enabled:
102
CORE0 CORE1 CORE2
TRAN
CORE0 CORE1 CORE2
TRAN
LSW
LSWMDS
eNB
CNPU
AP
eCN
S
eOMC
SCTP
signalingCS user
plane
After fault weakening is enabled:
The eNodeB loses the transmission connection to the eCNS.
The built-in CN board (CNPU shown in the preceding figure) implements the connection, to be specific, local switching of the CS user plane within the eNodeB.
The SCTP link between the eNodeB MPT and the built-in CN board actually carries the S1 signaling plane.
UEs under a single faulty eNodeB with fault weakening enabled can perform only basic voice
services, for example, having the floor, monitoring group calls, or initiating PTP calls. Such
UEs can communicate only with UEs under the same eNodeB and cannot perform PS
services.
Enhancement
None
Dependencies
None
2.85 TTRFD0905 Direct Mode Operation(DMO)
2.85.1 TTRFD090501 Analog DMO
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Direct mode operation (DMO) is a supplementary function and can be used for
communication when an area has no LTE signal.
103
In a DMO network, user can talk to other users on the same frequency after pressing the PTT
button on the UE. When the speaker is talking, other users cannot preempt the floor. After the
floor is released, other users can press the PTT to talk.
To expand the DMO communication scope, a DMO repeater is used.
Benefits
Users can communicate with each other when an area has no LTE signal.
Description DMO introduction
DMO is used for communication when there is no LTE signal. eLTE 3.1.1 supports only DMO. The specifications of a DMO network are as follows:
− Frequency range: 400 MHz to 470 MHz
− Maximum output power over the antenna port: 26 dBm to 28.5 dBm
− Distance between two speakers: 3 km to 5 km (in open areas)
DMO performs the following functions:
− Sets up an analog DMO call or listens to calls in a specified frequency.
− Adjusts frequencies. Users can adjust frequencies by using the encoder or the
navigation key on the UE, or by entering the frequencies on the UE. The difference
between two channels is 12.5 kHz.
With this feature, users can choose the following items:
− DMO transmit power, which can be 0.5 W or 1 W (default value)
− Denoising level, which ranges from 0 to 8 (The default value is 3.)
DMO audio mode
In a DMO network, the audio mode includes hand-free mode, headset mode, and hand
microphone mode.
− In the hand-free mode, the speaker is used for voice output and the MIC is used for voice input.
− In the headset mode, the PTT receiver in the earphone is used for voice output and the MIC in the earphone is used for voice input.
− In the hand microphone mode, the speaker in the microphone is used for voice output
and the MIC in the microphone is used for voice input.
The coverage area can be expanded using a DMO repeater. To connect to a DMO repeater, a
UE must be configured with the transmit frequency and receive frequency.
Enhancement
None
Dependencies
None
104
2.86 TTRFD0906 System Antivirus
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Virus can be prevented without affecting services.
Benefits
This feature improves the robustness and security of operators' equipment.
Description
Before an application program is released, it is scanned by at least one piece of prestigious
antivirus software, such as Symantec, TrendMicro, or McAfee, to prevent it from being
attacked by virus or malicious codes.
System antivirus provides the following functions:
System customization
System log management
Security hardening for the system password, file property, and kernel parameters
Interconnection security data configuration
Enhancement
None
Dependencies
None
2.87 TTRFD0907 OMC Geographical Redundancy
Availability
This feature is introduced in eLTE 3.1.1.
Summary
With this feature, two eOMCs in different areas work in 1+1 active/standby mode to provide
high availability element management services. If the active eOMC cannot provide services
due to certain reasons, the standby eOMC automatically takes over element management
services. This ensures the high availability and reliability of the element management system.
105
Benefits
This feature allows the element management system to quickly recover in the event of natural
disasters.
Description
The remote disaster recovery for eOMCs adopts the mature Veritas Storage_Foundation_of
High_Availability solution developed by Symantec. The negotiation, monitoring and
switchover of all resources and services are managed by Veritas. With remote disaster
recovery, two eOMCs in different areas work in 1+1 active/standby mode. If the active eOMC
is functional, it processes all services and the standby eOMC carries no service load but
synchronizes data with the active eOMC. If the active eOMC becomes faulty, the remote
standby eOMC takes over services.
Both the active and standby eOMCs adopt the network topology with dual network ports. The
two network ports are deployed on different network segments. One carries the applications,
and the other carries the backup and heartbeat data packages between the active and standby
eOMCs. The applications and the remote disaster recovery system (also called HA system)
use separate routes to isolate faults. Enough bandwidth resources must be reserved for the
data backup channel between the active and standby eOMCs. The transmission between the
active and standby eOMCs must support Layer 2 networking. They use floating IP addresses
(configured through Veritas) to implement applications. The HA system is transparent to the
managed NEs.
Currently, only DELL R820 servers can be used in the remote disaster recovery system.
The remote disaster recovery system cannot be used for load balancing. The system
specifications are the same as that of a single-node cluster.
Services interruption time does not exceed 25 minutes after a switchover of the remote disaster recovery system.
Enhancement
None
Dependencies
Remote disaster recovery of eOMCs is independent of the managed NEs.
The service port between the active and standby eOMCs in the remote disaster recovery
system uses floating IP address. Therefore, NEs are unaware of the eOMC redundancy or
switchovers between the two eOMCs. Specifically, the remote disaster recovery system does
not affect NEs. External NEs (such as the dispatching console and CN) must use floating IP
addresses to connect the eOMCs.
2.88 TTRFD0908 Dispatching System Geographical Redundancy
Availability
This feature is introduced in eLTE 3.1.1.
106
Summary
With this feature, dispatching systems work in equipment-level redundancy modes. If the
active dispatching system cannot provide services because of power-off or other reasons, the
standby dispatching system can still provide services.
Benefits
This feature improves system reliability and shortens the service interruption time.
Description The dispatching systems support 1+1 backup.
This feature applies to PTP calls, group calls, and PS services (including video, GIS, and short data services).
After old services are interrupted, new services can be fast admitted within 3 minutes (in
local active/standby mode) or 8 minutes (in remote disaster recovery mode). Users can
manually reinitiate interrupted services if needed.
The active/standby switchover of dispatching systems is implemented through floating IP addresses and therefore do not affect external NEs, such as the eOMC, CN, and UEs.
Enhancement
None
Dependencies
None
2.89 TTRFD1001 BWA-based Terminal Management As an independent subsystem in the evolved operation and maintenance center (eOMC), the
broadband wireless access (BWA)-based terminal management system has the following
features:
It is logically independent from the eOMC.
Its client can be started independently.
Its server can be deployed with the eOMC.
This feature applies only to fixed terminals, such as customer premises equipment (CPE) or
terminal access units (TAUs). Management of fixed terminals complies with the CPE WAN
Management Protocol (CWMP) (TR069), which defines the access mode of CPEs or TAUs,
and eOMC upper-layer application services.
This feature provides the following functions:
System function
Automatic terminal detection and network access
Terminal topology displayed in a table
Full-configuration delivery management
Command delivery in online mode
107
Software upgrade in batches
Terminal restart in batches
Factory defaults restore in batches
Remote diagnosis enhancement using the ping or traceroute program
Terminal log collection
2.89.1 System Function
Availability
This feature was introduced in eLTE 3.1.1.
Summary
System functions involve the following items:
Independent client for terminal management
CWMP-based southbound interfaces
DNS server
System help
Benefits
This feature offers the following benefits:
Independent client for terminal management
This client can be started independently. After users log in to the client, they can manage terminals or modify user rights for terminal management.
Standard CWMP-based southbound interfaces
Standard CWMP-based southbound interfaces are compatible with all CWMP-compliant terminals, improving system extensibility.
DNS server
The dedicated DNS server is no longer configured on the eOMC. If the default domain
name of the management server is set for a terminal before delivery, a radio connection can be established between the terminal and eOMC after the terminal is powered on.
System help
The system provides rich online help information and supports the full-text search function.
Description
The software for the terminal management system and the eLTE 3.1.1 eOMC software are
compressed into one file. The terminal management system can install or remove the software
based on user requirements. The terminal management interface can be independently started
and used for user authentication.
In eLTE 3.1.1, the CWMP-based terminal management system provides the following
functions:
Automatic terminal detection and network access
108
Full-configuration delivery after terminals are powered on
Remote upgrade of terminal software
Terminal restart and factory defaults restore in batches
Real-time monitoring of key parameters and terminal status
After the terminal management system is installed, the DNS server automatically starts and
processes domain name resolving requests received from terminals.
Enhancement IneLTE 3.1.1the terminal management system can manage both CPEs and TAUs.
The port mediation mechanism in eLTE 3.1.1 has been optimized to be applicable to different types of terminals or the same type of terminals with different ports.
The eOMC is independently released with terminals.
Dependencies
None
2.89.2 Automatic Terminal Detection and Network Access
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The eOMC can automatically detect new terminals in a network and manage them.
Benefits
No manual operation is required for management of new terminals in a network.
Description
If a terminal accesses a network after it is initially powered on, the default radio bearer is
established between the terminal and the evolved packet core (EPC) in compliance with the
CWMP protocol. The terminal then sends an access request to the eOMC. Upon receiving the
request, the eOMC automatically manages the terminal. If the eOMC manages the terminal
for the first time, it delivers the full-configuration file to the terminal.
Enhancement
In eLTE 3.1.1, the system can support importing and exporting of Engineering Parameters of
CPE.
Dependencies
None
109
2.89.3 Terminal Topology Displayed in a Table
Availability
This feature was introduced in eLTE 3.1.1.
Summary
A CPE or TAU list can be generated to provide the status information of all CPEs or TAUs
managed by the eOMC for users.
Benefits
System usability is improved. With the terminal management system, users can view the
topology of the whole network and log in to any CPE or TAU.
Description A table lists the status of all CPEs or TAUs, and users can perform the following
operations in the table:
− Modify or delete the terminal attribute.
− Update the terminal configuration.
− Restart terminals.
− Restore the factory defaults.
Users can query the following information:
− Status of the operation and maintenance (O&M) channel between the eOMC and
terminals
− Time of the latest communication between the eOMC and terminals
− Terminal IDs, alias names, locations, and IP addresses of terminals
− Software and hardware versions
− Time of the latest configuration file delivery
Users can delete or modify a topology.
Enhancement
In eLTE 3.1.1, terminal query has been optimized as follows:
All terminals are grouped by their locations and then displayed in a tree topology in the left
area of the table.
The eOMC generates a terminal location list after receiving manually imported terminal locations. Users can set different search criteria to query terminal information.
Dependencies
None
NOTE
110
2.89.4 Full-Configuration Delivery Management
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Users can upload and manage the full-configuration file for terminals, and the eOMC can
deliver and manage the full-configuration file for terminals.
Benefits
The eOMC can automatically deliver a full-configuration file to a new terminal in the network
if the file matches the terminal. Therefore, no manual operation is required.
Description
Users can import, delete, or update the full-configuration file for terminals. If a terminal
automatically accesses the network, the eOMC automatically delivers the full-configuration
file to the terminal based on the terminal ID.
Users can manually deliver the full-configuration file to specified terminals.
Users choose terminals and add them to the task pool. The eOMC then automatically delivers
the full-configuration file to the terminals based on the terminal IDs.
If the full-configuration file for a terminal is unavailable, users need to manually import the file and then deliver it to the terminal.
Enhancement
None
Dependencies
None
2.89.5 Command Delivery in Online Mode
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Users can run man-machine language (MML) commands to modify or query parameters
related to specified online terminals.
NOTE
111
Benefits
Less time is required for online parameter modifications, and the graphical user interface
(GUI) facilitates MML command input and parameter modifications.
Description
On the eOMC, users can choose one or several terminals with the same software version, and
then log in to an interface for command delivery. The command tree in the left area of the
interface provides commands for users. If users choose one command, the parameters of this
command are displayed in the right area of the interface. Then, users can set the parameters
and run the command. The command output is displayed in the upper-right area. This
operation is the same as that on the eNodeB or EPC.
Enhancement
None
Dependencies
None
2.89.6 Software Upgrade in Batches
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The eOMC can manage terminal software in batches.
Benefits
This feature offers the following benefits:
Less time is required for upgrading terminal software.
GUI interfaces facilitate user operations and information query.
Description The eOMC can download software to terminals for a future restart or upgrade.
Terminal software can be upgraded in batches. The GUI interface shows the status of
each upgrade task, including the task number, terminal name, file name, status, start time,
and end time.
Enhancement
None
Dependencies
None
112
2.89.7 Remote Restart in Batches
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The eOMC can restart terminal software in batches.
Benefits
This feature offers the following benefits:
Less time is required for restarting terminal software.
GUI interfaces facilitate user operations and information query.
Description
The reboot command is delivered to terminals and then the eOMC can remotely restart the terminals.
Terminals can be remotely restarted in batches.
Enhancement
None
Dependencies
None
2.89.8 Factory Defaults Restore in Batches
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The eOMC can restore terminal factory defaults in batches.
Benefits
This feature offers the following benefits:
Less time is required for restoring factory defaults.
GUI interfaces facilitate user operations and information query.
Description
The reboot command is delivered to terminals and then the eOMC can remotely recover factory defaults.
113
Factory defaults can be restored in batches.
Enhancement
None
Dependencies
None
2.89.9 Remote Commissioning in Batches
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Users can use the ping or traceroute program on the eOMC to remotely commission terminals
in batches.
Benefits
This feature offers the following benefits:
Less time is required for terminal commissioning.
GUI interfaces facilitate user operations and information query.
Description
1. Users specify one or multiple terminals and start the ping or traceroute program. Then,
users run commissioning commands with parameters set for each terminal on the GUI interface.
2. After the terminals receive the commissioning commands, they notify the eOMC of the
commissioning result. The eOMC then automatically displays the received
commissioning result for users.
Enhancement
None
Dependencies
None
2.89.10 Terminal Log Collection
Availability
This feature was introduced in eLTE 3.1.1.
114
Summary
The eOMC can remotely collect terminal logs in batches.
Benefits
Log analysis facilitates terminal fault locating.
Description The eOMC provides a GUI for users to remotely collect terminal logs. With the logs,
Huawei R&D engineers can locate faults in terminals.
Terminals compress and upload all logs after receiving log requests from users, and the current one-click terminal log is a compressed package with a size of 20 MB.
Users can simultaneously collect logs of multiple terminals.
Enhancement
None
Dependencies
None
2.90 TTRFD1002 Portable Terminal Management
Terminals referred to in this section are portable terminals.
As a subsystem in the eOMC, the portable terminal management system has the following
characteristics:
It is logically independent from the eOMC.
Its client is integrated with the BWA-based terminal management system client.
Its server can be deployed with the eOMC.
The portable terminal management system provides the following functions:
Software package and configuration file package management
Software package download
Configuration file package download
Application package download
Over the air (OTA)-based download report query
With the portable terminal management system, the software package, application package and configuration file package are downloaded in OTA mode.
2.90.1 Software Package, Configuration File Package Management
Availability
This feature was introduced in eLTE 3.1.1.
NOTE
115
Summary
The package management system allows users to upload the software package,
configuration file package and to query the available software package, configuration file
package.
Benefits
GUI interfaces facilitate software package, configuration file package upload in OTA mode.
Description
The software package is managed as follows:
Users can query currently available software packages or configuration file packages by
the terminal type. Users can upload new software packages, or configuration file
packages by the terminal type.
All packages are grouped by the terminal type.
The server of the portable terminal management system performs the following functions:
Calculates the sum of message digest algorithm 5 (MD5) verification results.
Updates the following information in the database:
− Terminal version
− Uniform resource locator (URL) and MD5 verification code for software packages or configuration file packages
A maximum of 10 software packages, or configuration file packages can be uploaded to each
type of terminal.
Enhancement
In eLTE 3.1.1, both the software packages and configuration file packages can be managed.
Dependencies
None
2.90.2 Software Package Download
Availability
This feature was introduced in eLTE 3.1.1.
Summary
After receiving a software package download request from a terminal, the eOMC OTA server
responds to the request and allows users to download software packages.
Benefits
Users can download or upgrade software packages in OTA and online modes.
116
Description
The eOMC OTA server provides download services in Hypertext Transfer Protocol (HTTP)
mode.
1. To download software or application package, a terminal sends the eOMC OTA server an HTTP request, which contains the following information:
− International mobile subscriber identity (IMSI)
− International mobile equipment identity (IMEI)
− Trunk system user number (TSUN)
− Terminal type
− Terminal version information, including configuration information
2. The eOMC OTA server checks whether the software version reported by the terminal is the same as that in the database, and then responds to the terminal as follows:
− If the reported version is available in the database, the eOMC OTA server responds to
the terminal that software upgrade is required and notifies the terminal of the software download path and MD5 verification results.
− If the reported version is unavailable, the eOMC OTA server responds to the terminal that software upgrade is not required.
Enhancement
None
Dependencies
None
2.90.3 Configuration File Package Download
Availability
This feature was introduced in eLTE 3.1.1.
Summary
After receiving a configuration file package download request from a terminal, the eOMC
OTA server responds to the request and allows users to download the configuration file
packages.
Benefits
Users can download or upgrade configuration file packages in OTA and online modes.
Description
The eOMC OTA server provides download services in HTTP mode.
To download a configuration file package, a terminal sends the eOMC OTA server an HTTP
request, which contains the following information:
IMSI
117
IMEI
TSUN
Terminal type
Terminal version information, including configuration information
The eOMC OTA server checks whether the configuration file version reported by the
terminal is the same as that in the database, and then responds to the terminal as follows:
If the reported version is different from that in the database, the eOMC OTA server
responds to the terminal that a configuration file upgrade is required and notifies the terminal of the package download path and the sum of MD5 verification results.
If the reported version is the same as that in the database, the eOMC OTA server responds to the terminal that a configuration file upgrade is not required.
If the software version of a terminal is different from that recorded in the eOMC OTA server, the software version of the terminal is preferentially upgraded.
Enhancement
None
Dependencies
None
2.90.4 OTA-based Download Report Query
Availability
This feature was introduced in eLTE 3.1.1.
Summary
GUI interfaces present details about download services provided by the OTA server for
terminals.
Benefits
The OTA-based download report helps users know how many terminals have successfully
performed download services using the OTA server and the details about each download
service.
Description
The OTA-based download report is a two-dimensional table and contains the following
information:
Terminal type, version, IMSI, and IMEI
Subscriber number
Latest software upgrade and configuration file upgrade results
When users query a report, they can set search criteria based on the previous information.
NOTE
118
Enhancement
In eLTE 3.1.1, the latest software upgrade and configuration file upgrade results are presented
in the OTA-based download report.
Dependencies
None
2.91 TTRFD1003 Performance Management
Based on the performance counters of the EPC and eNodeB, data about the network status is
recorded during performance management. The recorded data is significant for measurement,
planning and design, and operation and management of communications networks.
Availability
No. Function Introduced In
1 eOMC performance data collection and
storing
eLTE 3.1.1 eOMC
2 eCNS and eNodeB performance data
collection and storing
eLTE 3.1.1 eCNS
3 eSCN performance data collection and
storing
eLTE 3.1.1 eSCN
4 eOMC performance data query based on
search criteria and template
eLTE 3.1.1 eOMC
5 eOMC performance report query and
template-based report generation
eLTE 3.1.1 eOMC
Summary
Performance management provides the following functions:
Performance data collection
The eOMC collects performance data as follows:
1. Periodically collects performance data about the EPC and eNodeB.
2. Stores the data to its server.
3. Parses the data and stores the parsed data to the database for future analysis.
− Both preliminary collection and supplementary collection are supported.
− The eOMC server stores only performance data collected during the latest 21 days.
Performance counter query
Users can query performance data on the eOMC either by setting search criteria or using
a template that is generated based on the search criteria. Users have permission to query,
modify, or delete contents in the template.
119
Performance report generation
In eLTE 3.1.1, eNodeB performance data is processed using certain algorithms, and the
calculation results are presented in a report.
− Performance reports are available for both packet switched (PS) services and push to talk (PTT) services.
− The report generation conditions can be saved as a template. The saved template can
be used for generating a new performance report. Users have permission to query,
modify, or delete contents in the template.
Benefits
This feature offers the following benefits:
Historical performance data can be saved for a long period of time.
The eOMC database can be used for performance data analysis.
User-friendly interfaces facilitate data query.
User can save frequently used search criteria for querying performance data as a template for future use.
Users can analyze the network performance based on performance reports for both PS services and PTT services.
Users can save the frequently used report generation conditions as a template for future use.
Description
Performance management provides the following functions:
Performance counter collection
The EPC and eNodeBs generate a group of performance counter files every 30 minutes and
request the eOMC to upload the files to the specified folder in its server in File Transfer
Protocol (FTP) mode. If the eOMC does not correctly upload the files, it sends an automatic
check request to the EPC or eNodeBs during the next 30 minutes. If a file is missing, the
eOMC uploads the file again to its server in FTP mode.
After the eOMC periodically uploads the EPC and eNodeB performance counter files to its
server, it automatically starts its parsing module to parse all the files and then stores the data
in its database. Only the data stored in the database can be queried from the eOMC client.
Only data stored during the latest seven days is available in the eOMC database.
Performance counter query
Users can set the following search criteria to query performance data on the eOMC:
− Network element (NE)
− Measurement object
− Function set
− Measurement counter
− Time range
− Ascending order of a field
− Descending order of a field
− Users can also select either of the organization types to query performance data on the eOMC:
120
− Function set
− Measurement object
The eOMC provides a set of template management interfaces for querying performance
data. On the interfaces, users can save frequently used search criteria as a template to
quickly query performance data next time. The search criteria in a template include the NE, measurement object, function set, measurement counter, and time range.
Performance report generation
The following figure shows the procedure for generating a performance report.
Generate a performance report by performing any of the following operations:
Select a template from the performance report template list and double-click it.
Modify the attribute of a performance report. Then, save the report as a new template
node or generate a report using the new attribute.
It takes a maximum of 5 minutes to generate a performance report.
A maximum of six performance reports can be displayed on each eOMC client.
The eOMC provides a set of template management interfaces for generating performance
reports. On the interfaces, users can save frequently used report generation conditions as a
template to quickly generate a new report next time. The report generation conditions in a
performance report template include the NE and time range. Performance reports are available
for both PS services and PTT services.
Enhancement
None
Dependencies
None
NOTE
121
2.92 TTRFD1004 Alarm Management
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The fault alarm management system monitors the system running status. If the system detects
a fault or disturbance, it generates an alarm to notify the maintenance personnel.
Benefits
Detailed alarm information facilitates fault locating and troubleshooting.
Description
The fault alarm management system can generate alarms about all software, hardware, and
external environment. The detailed alarm information accurately indicates the fault locations.
With this system, all faults can be promptly detected and rectified. To distinguish fault
severity, four types of alarm severities are defined.
Critical
Major
Minor
Warning
Users can change the alarm severities based on actual conditions.
If an alarm is generated, the fault alarm management system provides detailed alarm
information for fault locating and rectification. Users can mask alarms that are not important
to them.
The client of the fault alarm management system performs the following functions:
Differentiates alarms with different severities by color.
In this way, users can quickly identify critical and major alarms.
Provides various search criteria for users to query alarms, such as the time range, alarm
severity, and alarm type.
In this way, users can quickly identify specified alarms for fault locating and rectification.
Enhancement
None
Dependencies
None
NOTE
122
2.93 TTRFD1005 Configuration Management
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The configuration management system manages all system parameters. With this system,
users can add, modify, delete, or query parameters.
Benefits
This feature offers the following benefits:
The system can work properly with correct configurations.
Users can manage all NEs using the independent configuration management system configured for each NE.
Description
With the configuration management system, users can configure data either in dynamic mode
or static mode.
In dynamic mode, users can modify the configurations without interrupting the normal
running of the system.
In static mode, users can modify the data scripts in offline mode and then load them. The new configuration takes effect after the system is restarted.
The eOMC can be used to back up or export data on the eNodeB, eSCN230, or eCNS210.
Enhancement
None
Dependencies
None
2.94 TTRFD1006 Call Tracing
Availability
This feature was introduced in eLTE 3.1.1.
Summary
Call tracing can be based on a user, group, or interface. The tracing results can be saved in a
file, and the file can be parsed and reviewed.
123
User-based call tracing records detailed information about message creation, capturing,
and parsing for a single user.
Group-based call tracing records detailed information about message creation, capturing, and paring for a group.
Interface-based call tracing records detailed information about message creation, capturing, and parsing over an interface.
Benefits
This feature offers the following benefits:
Call tracing facilitates fault locating during routine maintenance. After data configuration is
complete, users can use call tracing to check whether a signal link is normal.
Description
The EPC performs IMSI- or mobile station international ISDN number (MSISDN)-based user
tracing on the control plane and user plane. An eNodeB performs S-temporary mobile
subscriber identity (S-TMSI)-based single-user tracing. The EPC can start message tracing
even if a terminal does not attach to the network. After the terminal attaches to the network,
all singling and user data can be captured.
Call tracing types
The following three types of call tracing are available:
− User-based call tracing: traces signaling and messages of a specified user.
− Group-based call tracing: traces signaling and messages of a specified group.
− Interface-based call tracing: traces all messages over an interface.
Call tracing result saving
The traced message stream can be automatically or manually saved on the EPC and eNodeB. The tracing results can be saved in one of the following formats:
− Tracing message-related .tmf file: saves tracing messages. Users can open the file
using the Trace Viewer tool and browse it in offline mode. This type of file presents
users with intuitive browsing experience.
− Interface-related .txt file: saves messages displayed in the tracing interface.
− Protocol-related .txt file: saves explanations to protocols.
− .csv file: saves complete binary message streams.
Message stream query and review
Users can query message streams using the LMT tracing function or the Trace Viewer tool.
Detailed information is available for a specified message stream, as shown in the following
figure.
124
A horizontal line divides the Message Browser window into two parts, and a user can move this line upwards or downwards to change the size of the upper window and lower window. If the user clicks a
row in the upper window, the background of the row becomes dark blue and its detailed information, represented in hexadecimal mode, is displayed in the dark blue part of the lower window.
Users can use the Trace Viewer tool to view tracing files saved on the local computer. The
Trace Viewer tool provides the following functions:
Message stream query
The Trace Viewer tool can be used to query complete information about a message steam,
including the message direction, generation time, message type, and contents, as shown
in the following figure.
NOTE
125
Message stream review
If a user double-clicks a message stream, a window showing detailed information about the message stream is displayed, as shown in the following figure.
126
A horizontal line divides the Message Browser window into two parts, and a user can move this line upwards or downwards to change the size of the upper window and lower window. If the user clicks a row in the upper window, the background of the row becomes dark blue and its detailed information, represented in hexadecimal mode, is displayed in the dark blue part of the lower window.
Message stream sequencing
All tracing message streams can be arranged in a sequence by the message number, generation time, message direction, or message type.
Enhancement
In eLTE 3.1.1, the DSP GUTI command has been added to query the S-TMSI based on the
IMSI or MSISDN. Users can run this command to query the mobile country code (MCC),
mobile network code (MNC), mobile management entity (MME) group ID, MME code, and
M-temporary mobile subscriber identity (M-TMSI) in the globally unique temporary identity
(GUTI) represented in decimal mode. Based on the previous information represented in
decimal mode, single-user tracing can be performed.
Dependencies
None
NOTE
127
2.95 TTRFD1007 Log Management
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The log management system manages all logs and can be used to export or upload logs. Each
NE is configured with the log management system, and users can export logs of an NE from
the eOMC.
Benefits
Different types of logs provide system operation and running records for users.
Description
NEs can provide the following types of logs:
Running logs: record the software running status that can be detected by the system, such
as the system-level startup, system status change. Running logs provide information for the system maintenance personnel to judge the system running status.
Commissioning logs: record the software running status that cannot be detected by the
system, such as the object status change and record of an abnormal message.
Commissioning logs help Huawei R&D engineers locate faults and analyze the system running efficiency.
Operation logs: record commands delivered from the operation and maintenance system to terminals. Operation logs help maintenance personnel manage O&M records.
Security logs: record security events occurred on NEs, such as account login, account
management, account authentication, and other security events.
In addition to the previous types, an eNodeB also provides call history record (CHR) logs.
CHR logs: record all call history and are used for identifying abnormal calls.
Enhancement
None
Dependencies
None
2.96 TTRFD1008 Software Management
Availability
This feature was introduced in eLTE 3.1.1.
NOTE
128
Summary
The eOMC can manage eNodeB and eSCN software and patches, involving the following
operations:
Software version query, software upgrade, activation, and rollback
Patch download, loading, activation, confirmation, deactivation, deletion
Patch download using the one-click upgrade function
Benefits
This feature offers the following benefits:
GUI interfaces facilitate eNodeB and eSCN software and patch management.
With the one-click upgrade function, the software upgrade process is simplified.
Description Software management provides the following functions:
− Software version query: Users can quickly locate an NE or query the software version by entering the NE name or version name.
− One-click upgrade: Users can download and activate eNodeB software through a
one-click operation. Users can also choose to only download the software version or
patch version on the one-click upgrade interface. In addition, one-click upgrade can be used to upgrade software in batches.
− Software activation: All software downloaded to an eNodeB is in the non-activated state, and must be activated.
Patch management provides the following functions:
− Patch loading: changes the patch status from idle to deactivated.
− Patch activation: changes the patch status from deactivated to activated.
− Patch confirmation: changes the patch status from activated to running.
− Patch deactivation: changes the patch status from activated to deactivated.
− Patch deletion: changes the patch status to idle.
− Patch update: After a patch is updated, the eNodeB patch information changes, including the hot patch number, software version, activation time, and status.
Enhancement
In eLTE 3.1.1, eSCN software can also be managed.
Dependencies
None
2.97 TTRFD1009 Network Preventive Maintenance Network preventive maintenance can be used to periodically or proactively check the running
status of NEs and a network. With this feature, potential troubles in the NEs or network can be promptly detected and rectified to ensure the proper running of the network.
129
Availability eNodeB Network Preventive Maintenance is introduced in eLTE 3.1.1.
eCNS Network Preventive Maintenance is introduced in eLTE 3.1.1.
eCGP Network Preventive Maintenance is introduced in eLTE 3.1.1.
eSCN Network Preventive Maintenance is introduced in eLTE 3.1.1.
Summary
With scenario management, items for checking NEs or NE types during network preventive
maintenance can be grouped. For example, if NE parameters are checked during a holiday or
routine maintenance, a preventive maintenance task can be created in the equipment
preventive maintenance scenario and is then performed. In this case, the system checks only
the specified NEs and items.
NE preventive maintenance is application scenario-oriented. Each application scenario
provides a set of items. After users select an application scenario and the NEs to be checked,
NE preventive maintenance in a specified application scenario can be performed. For example,
users can select a type of NE or a single NE, and specify when to perform the NE preventive
maintenance during a task creation. In this case, users do not need to set the items for an NE
when creating an NE preventive maintenance task. After the preventive maintenance finishes,
users can click a task and the result is then presented.
Benefits
This feature offers the following benefits:
Application scenarios designed for network preventive maintenance are tailored to site requirements. Users can select an application scenario and NEs.
The preventive maintenance result is available to users.
Description Application scenario
Application scenarios for network preventive maintenance are as follows:
− Equipment preventive maintenance
− Upgrade check
− Core Network POOL Data Consistency Check
Network preventive maintenance supports only the previous two scenarios. Users cannot modify or create application scenarios.
Task
A task includes the following items: task name, application scenario, NE list, and
execution mode.
Tasks can be performed periodically or promptly.
− Periodical mode: In this mode, tasks can be created, deleted, modified, suspended, recovered, or stopped.
− Prompt mode: In this mode, tasks can only be created, deleted, stopped, or performed again.
NOTE
130
All tasks must be manually created.
Preventive maintenance report
The preventive maintenance report presents all data in a table. After users click a preventive maintenance task, they can choose to open the report or save it as a file.
Information in the report includes the NE ID, check items, and preventive maintenance
result. The following four types of results are defined for each check item:
− Passed
This result applies when the specified exceptions do not occur and no alarm is generated.
− Unpassed
This result applies when the specified MML command output is displayed or an alarm is generated.
− Unsuccessfully executed
This result applies when an error occurs during MML command execution.
− Manually handled
This result applies when items for checking MML commands and top N alarms are
not defined for health check. In this case, maintenance personnel need to judge the
result.
Enhancement
None
Dependencies
None
2.98 TTRFD1010 Remote Maintenance Information Collection
Availability
This feature was introduced for the eNodeB in eLTE 3.1.1.
This feature was introduced for the eCNS in eLTE 3.1.1.
This feature was introduced for the eSCN in eLTE 3.1.1.
This feature was introduced for the CPE in eLTE 3.1.1.
This feature was introduced for the eOMC in eLTE 3.1.1.
Summary
Users can remotely collect maintenance information in batches through the eOMC.
NOTE
131
Benefits
This feature provides information for users to locate faults.
Description
For the eOMC client, the user can execute the one-click log collection script through
Windows to generate a single compressed file. This file contains all related information
required to locate faults in the eOMC client.
For the eOMC server, the user can log in to the eOMC server and execute the one-click log
collection script under Suse Linux to generate a single compressed file. This file provides all
related information required to locate faults in the eOMC server.
For the eNodeB/eSCN, the user can select the boards through the GUI on the eOMC client.
The eOMC client will then automatically collect and send the one-click logs about these
boards to the computer at which the user operates. For the eSCN, the user can dump the
debugging logs on the eSCN to the eOMC to expand the capability of the eSCN to store
debugging logs.
For the eCNS/eSCN, the user can directly select the files (such as debugging logs and security
logs) to be collected through the FTP file transmission GUI on the eOMC client. The eOMC
will then collect and send the related files to the computer at which the user operates.
The user can select the CPEs through the GUI on the eOMC client. The eOMC will then
collect and send one-click logs about these CPEs to the eOMC server. The user can export the
logs to the computer through the file manager.
Enhancement
In eLTE 3.1.1, the following enhancements have been added:
Location information and logs of the eOMC client and server can be collected.
One-click logs of the eSCN/eNodeB can be collected.
The debugging logs of the eSCN can be dumped.
Dependencies
None
2.99 TTRFD1021 Subscriber Subscription Data Management
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The subscriber subscription data management system authenticates subscribers, and provides
subscription data about PS services, PTT services, and groups.
132
Benefits
Operators can provide differentiated services for subscribers or groups after setting quality of
service (QoS) subscription parameters.
Description
Operators can set the authenticate key for each terminal. A network and a terminal can
authenticate each other.
Operators can set basic PS service-related subscription parameters for each terminal,
including the bandwidths on the downlink and uplink, access point name (APN), and QoS.
For terminals performing PTT services, operators can set the following information to them:
priority, PTT capability, emergency service routing number, user name, and groups to which
the terminals performing PTT services belong.
Subscription data can immediately take effect after it is modified. In this way, terminals can
perform services using the latest subscription data.
Enhancement
None
Dependencies
None
2.100 TTRFD1022 Remote Management on Subscription Data
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The operation client can be used for:
Card registration
Account registration and deregistration
Subscription data modification
Group attribute setting
Benefits
GUI interfaces facilitate remote management of subscription data.
Description
After a terminal is connected to the home subscriber server (HSS), the following operations
can be remotely performed on the operation client:
133
Card registration and account registration
Key configuration for the UMTS subscriber identity module (USIM) card
Subscription data modification for PS services and PTT services, such as APN and QoS
for PS services
Account deregistration
Group deletion
Quick query of subscription data about subscribers and groups
Subscription data backup, which ensures data reliability
Enhancement
None
Dependencies
This feature requires that TTRFD1021 Subscriber Subscription Data Management be enabled.
2.101 TTRFD1031 Multi-Language
2.101.1 TTRFD103101 Chinese and English Support
Availability
This feature was introduced in eLTE 3.1.1.
Summary
The eCNS, eSCN, UE, eAPP, eOMC, and eNodeB support both Chinese and English.
Benefits
This feature meets the requirements of users outside China.
Description
NEs involved in the trunking system support Chinese and English (universal language). Users
can select the language based on actual requirements.
Enhancement
None
Dependencies
None
134
2.101.2 TTRFD103102 Other Languages Support besides Chinese&English
Availability
This feature is introduced in eLTE 3.1.1.
Summary
Service data can be input and displayed in language other than Chinese or English, that is,
minority language. This feature applies to countries in which minority language is spoken.
Benefits
This feature meets the requirements of users that speak minority language outside China.
Description
The trunking system can configure and display the user name, group call name, short
messages, and multimedia messages in minority language. UEs can manage the address book
and play ringback tone or alert tome in minority language. Only the preceding service data
can be input and displayed in minority language. The other user interfaces support only
Chinese and English.
This feature supports the interface of minority language.
Enhancement
None
Dependencies
None
2.102 TTRFD1041 Driving Test
Availability
This feature is introduced in eLTE 3.1.1.
Summary
EP680 v2 supports the LTE drive test, trunking service drive test, and basic drive test services
for building or optimizing an enterprise network.
Benefits
With this feature, customers' demands for statistics on basic enterprise network performance
can be met.
135
Description
Performance statistics on trunking services, PS services, signaling access, and signaling
handovers can be collected and reported.
The collected statistics matches the Hisilicon AGENT module interface to ensure correct
transfer to the drive test software.
The AGENT transfers the collected statistics to the drive test software for further analysis in
the backend.
The backend drive test software performs the following operations:
1. Parses signaling.
2. Plays back signaling.
3. Measures key events in real time.
4. Exports or imports collected statistics.
5. Analyzes trace data.
6. Outputs category-specific statistics on counter values.
Enhancement
None
Dependencies
None
2.103 TTRFD2001 400MHz OffLine Frequency Scan
Availability
This feature is introduced in eLTE 3.1.2.
Summary
Automatic or manuals frequency scan and configuration.
Benefits
With this feature, clean frequency can be found and used to wireless coverage in rapid
deployment scenario to avoid interference.
Description
Automatic mode: after the devices power on, the rapid deployment system scans 380
MHz~450 MHz automatically and takes effect clean frequency band according to scan result.
Manuals mode: in running state, user sets start/end frequency and then resets system. After scan is finished, the system takes effect clean frequency band according to scan result.
136
If user do not set special frequency band, the priority is 20 MHz, 10 MHz, 5 MHz, and 3 MHz
in order; else follow frequency band by user’s configuration. When scan result can not
satisfied with requirement of frequency band, system indicates error information.
Enhancement
None
Dependencies
None
2.104 TTRFD2002 WIFI Console
Availability
This feature is introduced in eLTE 3.1.2.
Summary
The DC can connect to MDC by WIFI.
Benefits
With this feature, the DC can connect to MDC in move state.
Description
The DC can connect to MDC in WIFI coverage area anywhere.
Enhancement
None
Dependencies
None
137
A Acronyms and Abbreviations
Numerics
3GPP 3rd Generation Partnership Project
A
AES Advanced Encryption Standard
AMBR aggregate maximum bit rate
AMC adaptive modulation and coding
AMR Adaptive Multirate
AP application processor
APK application package file
APN access point name
ARP allocation/retention priority
AS access stratum
ASME American society of mechanical engineers
AUTN authentication token
B
138
BLER block error rate
BWA broadband wireless access
C
CCU cell center user
CDR call detail record
CEU cell edge user
CHR call history record
CK cipher key
CPE customer premises equipment
CPU central processing unit
CQI channel quality indicator
CRS Oracle Cluster Ready Service
CWMP CPE WAN Management Protocol
D
DC dispatch console
DCI downlink control information
DHCP Dynamic Host Configuration Protocol
DMRS demodulation reference signal
DMO direct mode operation
DSCP differentiated services code point
139
E
E-UTRAN evolved universal terrestrial radio access network
E2E end to end
eCNS evolved core network system
eNodeB E-UTRAN NodeB
eOMC evolved operation and maintenance center
EPC evolved packet core
EPS evolved packet system
eSCN evolved smart core switch node
ESU enhanced service unit
F
FTP File Transfer Protocol
FXO foreign exchange office
FXS foreign exchange station
G
GBR guaranteed bit rate
GIS geographic information system
GTP-U GPRS Tunneling Protocol-User Plane
GUI graphical user interface
GUTI globally unique temporary identity
140
H
HD high definition
HARQ hybrid automatic repeat request
HSS home subscriber server
HTTP Hypertext Transfer Protocol
I
IBLER initial block error rate
ICIC inter-cell interference coordination
IK integrity key
IMEI international mobile equipment identity
IMS IP multimedia subsystem
IMSI international mobile subscriber identity
IP Internet Protocol
IRC interference rejection combining
ISDN integrated service digital network
K
KASME key ASME
L
LCG logical channel group
141
LTE Long Term Evolution
M
M-TMSI M-temporary mobile subscriber identity
MBR maximum bit rate
MCC mobile country code
MCS modulation and coding scheme
MD5 message digest algorithm 5
MDC multimedia dispatch center
MIMO multiple-input multiple-output
MME mobility management entity
MML man-machine language
MNC mobile network code
MRC maximum ratio combining
MSISDN Mobile Station International ISDN Number
N
NAS non-access stratum
NE network element
NT node table
O
OI overload indication
142
OMC operation and maintenance center
OMU operation and maintenance unit
OTA over the air
P
P2MP point-to-multipoint
P2P point-to-point service
PBCH physical broadcast channel
PBR policy-based routing
PBX private branch exchange
PCFICH physical control format indicator channel
PCO protocol configuration option
PDCCH physical downlink control channel
PDCP Packet Data Convergence Protocol
PDSCH physical downlink shared channel
PF proportional fair
PHICH physical HARQ indicator channel
PLMN public land mobile network
PRACH physical random access channel
PRB physical radio bearer
PS packet switched
PSD power spectrum density
PSTN public switched telephone network
143
PTT push to talk
PUCCH physical uplink control channel
PUSCH physical uplink shared channel
Q
QCI QoS class identifier
QoS quality of service
QPSK quadrature phase shift keying
QXI Quad-port 10GE rear interface
R
RAND random challenge
RB radio bearer
RB resource block
RES user response
RF radio frequency
RRC radio resource control
RRM radio resource management
RS reference signal
RSRP reference signal received power
RSRQ reference signal received quality
RTD round-trip delay
RTP Real-Time Transport Protocol
144
S
SA subframe assignment
S-TMSI S-temporary mobile subscriber identity
SDF service data flow
SDM shelf data module
SID silence indicator
SINR signal to interference plus noise ratio
SIP Session Initiation Protocol
SM short message
SMU Shelf Management Unit
SN service node
SP strict priority
SPS semi-persistent scheduling
SRS sounding reference signal
SSP special subframe pattern
SW short wave
SWI switch interface unit
SWU shelf management unit
T
TA tracking area
TAU tracking area update
145
TCP Transmission Control Protocol
TETRA TErrestrial Trunked RAdio
TPC transmit power command
TS technical specifications
TSUN trunk system user number
TTI transmission time interval
U
UDP User Datagram Protocol
UE user equipment
UMTS Universal Mobile Telecommunications System
URL uniform resource locator
USI universal service interface
USIM UMTS subscriber identity module
USW ultrashort wave
V
VLAN virtual local area network
VoIP voice over IP
VoLTE voice over LTE
VPN virtual private network
VRF virtual routing and forwarding
146
W
WAN wide area network
WFQ weighted fair queuing
WRR weighted round robin
X
XRES expected response
Top Related