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