Huawei ELTE3.1.x Broadband Trunking Solution Feature Description

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]

http://www.huawei.com/

mailto:[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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


2.24 TTRFD0213 Floor Pre-emption

Availability


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


2.25 TTRFD0215 Later Entry

Availability


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


2.26 TTRFD0216 Forced Release

Availability


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


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


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


2.29 TTRFD0219 Alias Display of Group and User

Availability


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


2.30 TTRFD0220 Broadcast Call

Availability


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


2.32 TTRFD0222 Call Forwarding

Availability


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


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


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


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


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


30

2.37 TTRFD0241 Barring of Incoming and Outgoing Calls

Availability


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


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


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


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


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


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


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.


channel quality. In this way, a tradeoff between the data rate and frame error rate can be achieved.

Enhancement

None

Dependencies


2.41.3 TTRFD030203 DL 64QAM

Availability


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.


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


2.41.4 TTRFD030204UL 64QAM

Availability


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


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


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


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


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


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


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


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


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


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


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.


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


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


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.


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


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


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


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


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


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


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


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


Summary

eNodeBs can be connected in the star topology.

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


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


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


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


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


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


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


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


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



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Summary

System functions involve the following items:

Independent client for terminal management

CWMP-based southbound interfaces

DNS server

System help

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


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


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


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


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


Summary

The eOMC can manage terminal software in batches.

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


Summary

The eOMC can restart terminal software in batches.

Benefits


Less time is required for restarting terminal software.


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


Summary

The eOMC can restore terminal factory defaults in batches.

Benefits


Less time is required for restoring factory defaults.


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


Summary

Users can use the ping or traceroute program on the eOMC to remotely commission terminals

in batches.

Benefits


Less time is required for terminal commissioning.


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


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


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


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


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


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


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


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


Summary

The configuration management system manages all system parameters. With this system,

users can add, modify, delete, or query parameters.

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


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


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


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


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


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


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


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


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


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


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


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


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


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

Huawei ELTE3.1.x Broadband Trunking Solution Feature Description

Documents

Transcript of Huawei ELTE3.1.x Broadband Trunking Solution Feature Description