request for proposal - huawei · request for proposal project "xxx" 20 sep 2013 ... 4.3.9...
TRANSCRIPT
Request for Proposal
Project "XXX"
20 Sep 2013
Chujian WX10464
IMPORTANT: This document is only for reference, please make necessary adjustment according to the
particular project.
重要: 本文档仅作为参考,请根据具体项目情况做必要的修正.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 2 of 47
Contents
1 Introduction .............................................................................................................................. 6
2 General Requirements ............................................................................................................. 6
2.1 Eligibility Criteria for Vendor Qualification................................................................................................ 6
2.1.1 Eligibility Criteria – Financial Conditions ......................................................................................... 6
2.1.2 Eligibility Criteria – Environmental Conditions ................................................................................. 6
2.1.3 Experience of the Solution ................................................................................................................ 6
2.2 Purpose of the RFP .................................................................................................................................... 7
2.2.1 Background ...................................................................................................................................... 7
2.2.2 Service Introduction .......................................................................................................................... 7
3 Broadband Service Requirements.......................................................................................... 7
3.1 Overall Requirements ................................................................................................................................ 7
3.1.1 Service Overview ............................................................................................................................. 7
3.1.2 Video, Voice, and Data Convergence ................................................................................................. 7
3.1.3 Unified Dialing Number for All Services ........................................................................................... 8
3.1.4 Power Control .................................................................................................................................. 8
3.1.5 QoS Management ............................................................................................................................. 8
3.1.6 VPN ................................................................................................................................................. 8
3.1.7 Hierarchical Networking ................................................................................................................... 8
3.1.8 Charging（only eCNS210 supports this feature） ............................................................................. 8
3.2 Function Requirements .............................................................................................................................. 9
3.2.1 Voice Services .................................................................................................................................. 9
3.2.2 Video Services .................................................................................................................................12
3.2.3 Data Services ...................................................................................................................................13
3.2.4 Message Services .............................................................................................................................14
3.2.5 Location-based Services...................................................................................................................14
3.2.6 Multimedia Record Services ............................................................................................................15
3.3 Security Requirements ..............................................................................................................................15
3.3.1 Authentication .................................................................................................................................15
3.3.2 E2E Encryption ...............................................................................................................................15
3.3.3 Anti-jamming ..................................................................................................................................16
3.4 Interoperability Requirements ...................................................................................................................16
3.4.1 Interconnection with PSTN/PLMN/IP PBX/Conventional Phone ......................................................16
4 Broadband Trunked Multimedia Dispatching .................................................................. 16
4.1 General Requirements...............................................................................................................................16
4.2 Specification Requirements.......................................................................................................................17
4.3 Features ....................................................................................................................................................19
4.3.1 Voice Service Management ..............................................................................................................19
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 3 of 47
4.3.2 Video Service Management ..............................................................................................................20
4.3.3 Voice and Video Recording Management .........................................................................................20
4.3.4 SMS/MMS Service Management .....................................................................................................20
4.3.5 GIS Service Management.................................................................................................................20
4.3.6 User Group Management .................................................................................................................21
4.3.7 Service Configuration Management .................................................................................................21
4.3.8 Security Management ......................................................................................................................22
4.3.9 VPN ................................................................................................................................................22
4.3.10 Hierarchical Deployment ...............................................................................................................22
5 Base Station ............................................................................................................................. 23
5.1 General Requirements...............................................................................................................................23
5.1.1 BBU Requirements ..........................................................................................................................24
5.1.2 1.8GHz 4 PATH RRU Requirements ................................................................................................24
5.1.3 1.4GHz 8 PATH RRU Requirements ................................................................................................25
5.1.4 400MHz 2 PATH RRU Requirements...............................................................................................25
5.1.5 1.8GHz 2 PATH RRU Requirements ................................................................................................26
5.1.6 800MHz 2 PATH RRU Requirements...............................................................................................26
5.1.7 High Availability Design ..................................................................................................................27
5.2 Standard Compliance ................................................................................................................................27
6 Core Network .......................................................................................................................... 27
6.1 General Requirements...............................................................................................................................27
6.2 Specification Requirements.......................................................................................................................28
6.3 High Reliable Requirements .....................................................................................................................29
6.4 Features ....................................................................................................................................................29
6.4.1 QoS Requirements ...........................................................................................................................29
6.4.2 Security Requirements .....................................................................................................................29
6.4.3 Transmission Requirements .............................................................................................................30
6.4.4 Service Requirements ......................................................................................................................30
6.4.5 OM Requirements............................................................................................................................30
7 Terminal .................................................................................................................................. 30
7.2 Professional Multimedia PTT Handset ......................................................................................................31
7.2.1 Overview .........................................................................................................................................31
7.2.2 Display Window ..............................................................................................................................31
7.2.3 Indicators and Switches ...................................................................................................................32
7.2.4 Transceiver ......................................................................................................................................32
7.2.5 Handheld Radio Accessories ............................................................................................................32
7.2.6 Built-in Test Routine ........................................................................................................................33
7.2.7 Battery Charger ...............................................................................................................................33
7.2.8 Battery Unit .....................................................................................................................................33
7.2.9 Software ..........................................................................................................................................33
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 4 of 47
7.3 Vehicle Mounted Terminal ........................................................................................................................34
7.3.1 Overview .........................................................................................................................................34
7.3.2 Hardware .........................................................................................................................................34
7.3.3 Software ..........................................................................................................................................35
7.4 Data Transmission Terminal ......................................................................................................................35
7.4.1 Overview .........................................................................................................................................35
7.4.2 Hardware .........................................................................................................................................35
7.4.3 Software ..........................................................................................................................................36
8 Easy Network Management System .................................................................................... 36
8.1 General.....................................................................................................................................................36
8.2 Feature(Server Platform Version) ..............................................................................................................36
8.2.1 Hardware Platform Requirement ......................................................................................................36
8.2.2 Platform Function Requirement .......................................................................................................38
8.2.3 Topology Management.....................................................................................................................38
8.2.4 Configuration Management ..............................................................................................................38
8.2.5 Performance Management ................................................................................................................38
8.2.6 Fault Management ...........................................................................................................................39
8.2.7 Software Management .....................................................................................................................39
8.2.8 Security Management ......................................................................................................................39
8.2.9 System Management ........................................................................................................................39
8.2.10 Handset & Vehicle Mounted Terminal Management .......................................................................40
8.2.11 Broadband Access Terminal Management .......................................................................................40
8.2.12 Log Management ...........................................................................................................................41
8.2.13 Equipment Inspection ....................................................................................................................41
8.2.14 Operation Management ..................................................................................................................41
8.3 Feature(PC Platform Version) ...................................................................................................................41
8.3.1 Hardware Platform Requirement ......................................................................................................41
8.3.2 Platform Function Requirement .......................................................................................................42
8.3.3 Topology Management.....................................................................................................................42
8.3.4 Configuration Management ..............................................................................................................42
8.3.5 Performance Management ................................................................................................................42
8.3.6 Fault Management ...........................................................................................................................42
8.3.7 Software Management .....................................................................................................................43
8.3.8 Security Management ......................................................................................................................43
8.3.9 System Management ........................................................................................................................43
8.3.10 Handset & Vehicle Mounted Terminal Management .......................................................................44
8.3.11 Broadband Access Terminal Management .......................................................................................44
8.3.12 Log Management ...........................................................................................................................44
8.3.13 Operation Management ..................................................................................................................45
8.4 Reliability.................................................................................................................................................45
8.4.1 Data Security ...................................................................................................................................45
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 5 of 47
8.4.2 Operation Security ...........................................................................................................................45
8.4.3 Software Reliability .........................................................................................................................45
8.4.4 Hardware Reliability ........................................................................................................................45
9 Gateways ................................................................................................................................. 46
9.1 Telephony Gateway ..................................................................................................................................46
9.2 Trunking Gateway ....................................................................................................................................46
9.3 Video Gateway .........................................................................................................................................46
9.4 Data Gateway ...........................................................................................................................................46
10 Second Development Interfaces ......................................................................................... 46
10.1 SIP/SDK Interface ..................................................................................................................................46
11 Annex ..................................................................................................................................... 47
12 Appendix ............................................................................................................................... 47
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 6 of 47
1 Introduction
This document describes the technical requirements defined by the XXX for vendors to perform the
technical evaluation.
The XXX seeks the proposals of wireless broadband/trunking/wireless video surveillance solution for the
xxx project. The wireless broadband solution needs to support functions, such as voice, video, and data acquisition.
The XXX requires the proposal on the equipment (hardware and corresponding software) to meet all
requirements described in this document. In case a feature or requirement has dependency on the proposed
equipment hardware, this condition needs to be clarified and the corresponding hardware needs to support
the features or requirements described in the proposal.
The XXX reserves the interpretation and modification rights of the Request for Proposal (RFP).
2 General Requirements
2.1 Eligibility Criteria for Vendor Qualification
2.1.1 Eligibility Criteria – Financial Conditions
1. To guarantee that the proposed vendor can continuously provide business value. The bidder must
submit the following copies of audited accounts and annual reports for last three years.
− Profit & loss account
− Balance sheet
− Cash flow
− Statement of changes in equity
− Director's report and auditor's report
− Confirmation that the company is still trading
− A statement of turnover since the last set of published accounts
− Details of any outstanding claims or litigation against the company
2.1.2 Eligibility Criteria – Environmental Conditions
1. The vendor must have good documented quality framework and must be certified by ISO 9001:2000
or ISO 9002:2000 or better organizations. The vendor must accordingly submit copies of relevant
certificates to the personnel. ISO is short for International Organization for Standardization.
2. The proposed system must pass the CE/ROHS/FCC/C-TICK certification and security-related test. The vendor must accordingly submit copies of relevant certificates to the personnel.
3. The proposed system must comply with international EMC standards. The vendor must demonstrate the EMC performance or EMC test report when necessary.
2.1.3 Experience of the Solution
1. The vendor must have the consolidated experience and business case to testify the ability of
commercial or trial deployment of the network. Customers must provide the detailed reference list and
the report.
2. It is important for the vendor to be a part of the international standardization organization. The vendor
must clarify whether the vendor is an independent member of the 3GPP standard group and provide more detailed information about the enrollment of 3GPP standardization activities. Contributions of
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 7 of 47
these activities include SA2 and CT, patents, and authorized applications, which shows the industrial
-guiding ability and deep-understanding of the LTE/SAE technology.
3. The vendor must demonstrate the solid wireless capability by global market share. Proposed vendor's wireless market share must be no less than 10%.
4. The vendor must demonstrate the influence in the PPDR trunked radio standard organization. The vendor must clarify whether it is an independent member of TCCA.
5. The vendor must demonstrate the solid LTE capability in the patent area. The vendor must provide the
third-party analysis report like ABI about the core patent specification number of the LTE recorded by
3GPP. The number of core patents must be no less than 150.
6. The vendor must demonstrate the solid LTE capability by the commercial contract number according
to the analysis report from authorization organizations like the GSA and Dell'Oro group. The number of LTE RANs that have been globally launched for commercial use must be no less than 30.
7. The vendor must demonstrate the solid LTE capability by the commercial contract number according
to the analysis report from authorization organizations like the GSA and Dell'Oro group. The number of LTE EPCs that have been globally launched for commercial use must be no less than 20.
8. The vendor must demonstrate the solid LTE capability by the base station shipment number. The number of LTE EPCs that have been globally launched for commercial use must be no less than 30.
2.2 Purpose of the RFP
2.2.1 Background
This section describes the project background.
2.2.2 Service Introduction
This section describes customers' service requirements.
3 Broadband Service Requirements
3.1 Overall Requirements
3.1.1 Service Overview
The proposed broadband trunking radio system must support the voice, video, data, and
location-oriented convergence services to provide continuous evolution capability for the XXX project.
3.1.2 Video, Voice, and Data Convergence
1. The proposed solution must support the concurrence of data and voice services. Data services include
not only the video service, message service, Internet data service, and location based service but also
other application services.
2. The proposed solution must support the combination of services, such as video services (video
surveillance/distribution/upload) and non-video services (the call from PSTN, individual call, and group call) concurrently.
3. The group call can be accepted without any manual intervention and remain concurrent with the
existing data services, and can preempt the accompanying sound of video services.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 8 of 47
3.1.3 Unified Dialing Number for All Services
The dispatching console (DC) and MS must support the use of a unified dialing number to trigger off
various services like a voice call, a video call, and a GIS. The number could be a user phone number or
group call number.
3.1.4 Power Control
1. In order to reduce the MS power consumption, the proposed system must support MS uplink power control function. By using this function, Base Station can control MS’ maximum sending power.
2. In order to minimize the Base Station power consumption, the proposed system must support that the
Base Station can dynamically adjust its transmit power in the downlink based on the radio channel quality.
3.1.5 QoS Management
1. The proposed system must ensure that Base Station and Core Network can provide bearer level QoS
management to ensure E2E QoS. On the control panel, the E2E QoS includes admission control,
congestion control, preemption control, overload control, and data flow control. On the data panel,
layer 3 QoS management must support DSCP and layer 2 must support IEEE 802.1p/Q for differentiated services.
2. The proposed system must support that different users can be assigned different priorities in the system.
3. The proposed system must support that different kind of services can be configured different QoS levels in the system.
3.1.6 VPN
1. The proposed system must support virtual private network (VPN) function. By using the VPN
function, the network infrastructure shared by different groups can be combined to make different
virtual private networks. The VPNs work independently from one another.
2. The proposed system must support that users, groups, scheduling server, audio and video server, and gateways can be divided and formed different VPNs.
3.1.7 Hierarchical Networking
1. The proposed system must support that 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.
2. UEs served by the upper-level dispatcher can initial voice or video calls to those served by the lower-level dispatchers.
3. UEs served by different lower-level dispatchers can also initiate voice or video calls to one another.
3.1.8 Charging（only eCNS210 supports this feature）
1. The proposed system must support to export 3GPP-compliant PGW-CDR used for charging offline PS traffic.
2. By interconnecting with the Charging Gateway (CG) and the third-party charging system, the
proposed system must be able to provide the PS charging scheme compatible with the LTE public network.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 9 of 47
3.2 Function Requirements
3.2.1 Voice Services
The system must support features described in the following sections.
3.2.1.1 Private Call
1. The proposed system must support point-to-point private calls between any two parties (MS to MS, MS to DC, and DC to DC).
2. The proposed system must guarantee that private call setup time must be less than 300ms.
3. The proposed system must guarantee that private call delay should be no more than 500ms.
4. The proposed system must support 12.2k and 4.75k AMR voice calls. The system can be
configured to decide which kind of voice type to be used.
5. The proposed system must enable users to perform PS services and private call services simultaneously.
6. The proposed system must support that an authorized dispatcher can forcely end a PTP call and release the related resources.
7. The proposed system must support that the duration of PTP call can be configured.
3.2.1.2 Barring Incoming Call
The proposed system must support a rule to block a specific incoming call or any incoming calls within a
specific number range.
3.2.1.3 Barring Outgoing Call
The proposed system must support a rule to block a specific outgoing call or any outgoing calls within a
specific number range.
3.2.1.4 Group Call
1. The radio system must support group voice calls, enable the communication between users of the same call group in a pre-defined area.
2. Group call setup time must be less than 300ms.
3. The maximum number of users supported in one group shall not be less than 1000.
4. Group members can join in the group manually or automatically as the handset configuration.
5. Group members can rejoin in an established group call manually or automatically. The network can refresh the group information in real time.
6. Only the dispatcher or the originated MS has the permission to end the group call.
7. One MS can belong to no less than 20 different trunking groups.
8. The talking rights of group members will be released after the group inactivity timer times out as the system configuration. The inactivity timer for every group call can be configured flexibly.
9. The proposed system must enable users to simultaneously perform PS services and group call
services.
10. The proposed system must support that an authorized dispatcher can forcely end a group call and release the related resources.
11. The proposed system must support that the duaration of speaker in a group can be configured.
12. The proposed system must support that the group name and speaker name are displayed on each MS in the group.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 10 of 47
3.2.1.5 Broadcast Call
1. The proposed solution shall support broadcast to the trunking users distributed in the whole area covered by the radio trunking telecommunication system..
2. The proposed solution shall support broadcast to the trunking users distributed in areas covered by some specific base stations in the radio trunking telecommunication system.
3. Only the dispatcher is allowed to initiate a broadcast call. Any preemption is forbidden.
4. If the initiator quits the broadcast call, the broadcast call will be released.
3.2.1.6 Emergency Call
1. The proposed system must support emergency point-to-point call and emergency group call.
2. The proposed solution must support emergency call initiated by MS or DC.
3. The proposed emergency group call setup time must be less than 300ms.
4. The emergency call has the highest priority and can preempt other P2P calls or group calls.
5. The proposed emergency call must support HOT MIC that will enable the MS to initiate emergency call immediately.
6. The controller must be able to answer an emergency initiated by a MS. The MS can initiate an emergency call by pressing a predefined number.
7. On the dispatcher screen, the scroll bar must be displayed with visual and audible alert showing details
about the ID and location from which the emergency call was originated. The controller must be able
to acknowledge the call and then select the calling party to activate a two-way communication.
3.2.1.7 Direct Mode Operation
1. To guarantee trunking users can still communicate when they stay in areas without LTE radio signal
coverage, the proposed solution shall support Direct Mode Operation. When trunking users entering
Direct Mode Operation, they can push the PTT button to speak with others within the same area.
2. The DMO must support the group collaboration within a radius of 5 km areas in the line of sight (LOS) situation.
3. In Enter/Quit Direct mode, handsets must be manually switched to the DMO mode for communication.
4. In Register/De-register mode, handsets must be registered or de-registered by pushing ON or OFF button of the handset radio.
5. An emergency call may not use the radio infrastructure.
3.2.1.8 Dynamic Regrouping
1. The proposed system must support DC to form a trunking group. Trunking users in the dynamic group can communicate as in ordinary group.
2. The proposed system must guarantee that the dispatcher can regroup 32 users every second when performing dynamic regrouping.
3. Only the dispatcher can set up or remove a dynamic group manually.
3.2.1.9 Temporary Group Call
The proposed system shall support that the dispatcher can initiate a temporary call on multiple MSs or
static groups. After the temporary call is terminated, all MSs and NEs automatically delete the
configuration of this temporary call.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 11 of 47
3.2.1.10 Later Entry
When a group call is set up, some users may not join the call due to power-off, out of the service area, or
other reasons. When the user powers on, enters the service area, or dials the active group number, the
system can connect late users to the ongoing call.
3.2.1.11 Preemptive Priority Call
1. The proposed system must support group call rights application triggered by the DC or MS. A high-priority member can preempt low-priority members' talking rights.
2. The time required for getting preemptive rights must be less than 200ms.
3.2.1.12 Call Group Scanning
1. The proposed system must allow users to listen to group calls in its scanning list. The MS will receive
the group call with the highest priority in the scanning list.
2. An MS shall be configured no less than 20 scanning groups.
3.2.1.13 Discreet Monitoring
1. The proposed system must support discreet monitoring. By using this service, a user may listen to one
or more communications between other users without any indication that the call is being overheard to these users.
3.2.1.14 Session Status Indication
1. The DC needs to monitor voice services in real time when an MS is in the online, idle, ringing, and communication states.
2. The DC needs to monitor video services in real time when an MS is in the idle, ringing, and uploading states.
3.2.1.15 User Status Query
The states of MSs, including the registration, current group, and online states, can be displayed in the DC.
3.2.1.16 Remote MS Disabling and Enabling
1. The proposed system must support dispatcher to remotely temporarily disable a MS in the network. If a MS is temporarily disabled, it can only use the services related to mobility management.
2. The proposed system must support dispatcher to remotely enable a MS which is temporarily disabled before. After being enabled, the MS shall have the ability t work like other normal MS.
3. The proposed system must support dispatcher to remotely permanently disable a MS in the network. If
a MS is permanently disabled, it can not access to the network any more immediately.
The dispather can identify whether a MS has been successfully disabled from the dispatching console.
3.2.1.17 Calling Party Identification
The proposed system must provide a means of identifying the current "control" terminal or the terminal on
which voice control is currently enabled.
3.2.1.18 Out of Service Indication
Audio and light indications are used to inform the user when the radio is out of the coverage range of the
radio system.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 12 of 47
3.2.1.19 Call Forwarding
The proposed system must support to transfer a PTP call for an MS to another telephone number before the
MS answers the call.
3.2.1.20 Voice Call Data Record
1. The proposed system must support to generate a call detail record (CDR) on voice group calls and
voice P2P calls. 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.
2. The proposed system must support that the voice call data record can be stored at least 28 days.
3.2.2 Video Services
3.2.2.1 Mobile Video Individual Call
1. The system must support video calls between MSs. The call on one side can see the video of the other
side through the camera on the MS.
2. The system must support the synchronization between the voice group call and the video call.
3.2.2.2 Mobile Video Upload
1. The system must support the upload of videos from MSs' cameras to the command centre. The video type must be D1, 720P or 1080P.
2. Both the MS and the DC can trigger the upload of videos from the MS.
3. Both the MS and the DC can release the upload of videos.
4. Both the MS and the DC can configure the uploaded videos from MS's front camera or the back camera.
5. Both the MS and the DC can configure videos uploaded with voice or only video type.
6. Both the MS and the DC can define videos uploaded with voice or without voice. When a video is
replayed, the voice channel can be opened or closed.
7. The MS can choose one from the uploaded videos to check; audio can be closed or opened.
8. Only authorized MS can view the uploaded video.
3.2.2.3 Mobile Video Dispatching
1. The dispatcher can distribute real-time videos to specified terminals, such as MSs, PCs, and other dispatchers.
2. The proposed system needs to enable the dispatcher to distribute video on a channel to one or more MSs.
3. The proposed system needs to project specified high definition (HD) video signal to the screen on the
TV wall.
4. Specifications for video dispatching are as follows:
Supporting the transformation of video types from D1, 720P or 1080P to CIF
Code type: H264
3.2.2.4 Fixed Video Access
1. The proposed broadband DC must support the browsing, replaying, and recording of HD videos through multiple channels simultaneously.
2. The proposed broadband DC must support the display of fixed video surveillance on a video wall.
3. The proposed broadband DC supports the Pan Tilt Zoom (PTZ) operation for fixed cameras.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 13 of 47
4. The proposed broadband DC can display the list of MSs from which videos are uploaded and fixed
cameras.
5. The proposed broadband DC must support the following video types: 1080P, 720P, D1, and CIF (352 x 288).
6. The proposed broadband DC must support the browsing of HD videos through 16 channels simultaneously.
3.2.2.5 Video Surveillance
1. The proposed system must support that dispatchers can use a camera to perform fixed video
surveillance.
2. The proposed system must support that MSs can use a camera to perform fixed video surveillance.
3. The proposed system must support that dispatchers can perform mobile video surveillance throug MSs’ cameras.
4. The proposed system must support that MSs can perform mobile video surveillance throug other MSs’ cameras.
5. The proposed system must support that the dispatcher who is surveilling an MS can also hear the
voices received by the MS being surveilled.
6. The proposed system must support that the MS that is surveilling other MS can also hear the voices
received by the MS being surveilled.
7. The proposed system must support that the video surveillance service and voice services can be performed simultaneously.
3.2.2.6 Video Projection
The proposed system shall support video display on large screen to optimum resolution and wide visual
range.
3.2.2.7 Combined Services Collaboration
The proposed system shall support that video Feedback, video distribution, and video surveillance can be
concurrent with non-video calls (including voice P2P calls and group calls).
3.2.2.8 Video Call Data Record
1. The proposed system must support to generate a call detail record (CDR) on 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.
2. The proposed system must support that the voice call data record can be stored at least 28 days.
3.2.3 Data Services
3.2.3.1 High Speed Data Services
1. The proposed system must support an uplink rate of 2Mbit/s or higher for a single user and provide the HD video upload function.
2. The proposed system must support a downlink rate of 6Mbit/s or higher for a single user and provide the HD video distribution function.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 14 of 47
3.2.3.2 Field Image Distribution
The digital trunking radio communication system must support high speed data services for the quick
transmission of field images and other data. Handsets must have built-in cameras to enable quick
photographing of crime scenes and the transmission to the emergency command center.
3.2.4 Message Services
3.2.4.1 Short Message Services
1. The system must support point-to-point (PTP) and point-to-group short message services (SMSs) between any two parties (MS to MS, MS to DC, and DC to DC).
2. Length of a single SMS transmission must support no less than 1000 bytes and fragmental transmission must be supported.
3. The system must support offline messages. When an MS is online, the server will send an offline
message to the MS automatically.
4. The system shall store the offline short messages for no less than 48 hours.
5. Each dispatcher and MS must support no less than 100 preset short messages.
6. The dispatcher and MS allow users to edit preset short messages.
7. The dispatcher and MS must support predefined status messages and emergency messages.
8. The DC must support the storage and export of all SMSs that have been sent or received. An alarm
will be generated when the storage buffer is insufficient.
3.2.4.2 Multimedia Messaging Services
1. The system needs to support PTP and point-to-group multimedia messaging services (MMSs) between MSs and dispatchers.
2. The MMS needs to support the picture, sound, and text functions. One MMS supports the transmission
of an HD picture up to 2 MB.
3. The sent or received multimedia messages can be stored and exported. When the space is insufficient, the system will send a notification message.
4. The system needs to support offline multimedia messages. When an MS is online, the server will send offline multimedia messages to the MS automatically.
5. The system shall store the offline multimedia messages for no less than 48 hours.
6. When the total multimedia message size reaches the storage limit, a message shall be displayed, indicating that the memory is full.
3.2.5 Location-based Services
1. The handset with build-in integrated GPS can provide location-based services.
2. The handset must can enable or disable GPS location service according to the command from the dispatching console.
3. The status of the GPS function is displayed on the MS and DC screens.
4. The MS needs to report specified GPS events in an emergency situation. In this case, the GPS function
can be enabled automatically without any order from the dispatcher. The dispatcher needs to support the configuration of GPS events in the MS.
5. If satellite searching fails or other exceptions occur, the MS needs to display an indicator and notify the dispatcher at the same time.
6. On the e-map (electrical map), the handset terminal status can be displayed when: GPS data reporting is enabled, satellite searching fails, and GPS data reporting is disabled.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 15 of 47
7. If satellite searching fails or GPS data reporting is disabled, the e-map shall display the latest GPS
location and update time.
8. For the devices without a GPS module (such as cameras), the system shall support manually configure their GPS data.
9. The proposed system shall support that the e-map can display the location of a camera. Users can configure and view surveillance presence on the e-map.
10. The proposed system shall support layer control on the e-map. Users can choose objects to display on the e-map.
11. The position and direction of the MS needs to be displayed on the map.
12. The server needs to support the MS periodical GPS reporting. The reporting period can be configured
as 1s, 2s, 5s, 10s, 15s, 30s, or 60s.
13. On the location map, the dispatcher can trigger video upload, video distribution, video call, voice call, and short message for multi-media dispatching.
3.2.6 Multimedia Record Services
3.2.6.1 Voice Record
1. The system needs to support the record of P2P voice calls and group voice calls.
2. The system needs to support the storage, query, deletion, and export of voice records.
3. The system needs to support the query, replay, and export of voice records by group, user, and time through Web GUI.
4. The voice records can be replayed using a generic soft player through Rapid Spanning Tree Protocol
(RSTP).
3.2.6.2 Video Record
1. The system needs to support the record of video calls and the upload of videos and fixed camera videos.
2. The system needs to support the storage, query, deletion, and export of video records.
3. The system needs to support the query, replay, and export of video records by user ID and time
through Web GUI.
4. The video records can be replayed using a generic soft player through RSTP.
3.3 Security Requirements
3.3.1 Authentication
When a user attempts to access the radio system, the system will verify and validate the radio identity
number of the user. If the radio identity number of the user is invalid, the user will be barred from accessing
the system.
3.3.2 E2E Encryption
1. The proposed system must support E2E encryption to ensure the confidentiality and eavesdropping protection of sensitive speeches from the source to the destination.
2. The proposed system must support E2E encryption to ensure the confidentiality of voice and video message from source to the destination.
3. The proposed system must support hardware E2E encryption.
4. The proposed system must support that the encryption algorithm can be replaceable by XXX.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 16 of 47
5. The proposed system must support one key per session encryption mechanism. Every time the system
initiates a voice or message service, a new key will be generated to guarantee the security of this service.
6. The proposed system must support 256 bits length encryption key.
3.3.3 Anti-jamming
1. The system needs to support the anti-jamming capability when the system is jammed by normal
inter-system interference and intention interference. The system has to work with the smallest change of data throughput and voice quality.
2. The system needs to support power control for anti-jamming. The system can retain the performance by controlling the transmission power to obtain a better signal-to-noise ratio (SNR) when it is jammed.
3.4 Interoperability Requirements
3.4.1 Interconnection with PSTN/PLMN/IP PBX/Conventional Phone
1. The signalling needs to support the SIP2.0 and SDP protocols (including RFC3261, RFC2976,
RFC2617, and RFC2327).
2. The data plane needs to support the RTP protocol (including RFC3550 and RFC1889).
3. The voice coder/decoder (CODEC) needs to support G.711.
4. The gateway can be connected to a LAN over the FE or GE interface.
5. The system can connect to the analog phone over the FXS interface and access the service system as an internal user.
6. The external user can connect to the system over the FXO or E1 interface.
7. The external user can connect to a PLMN system over the FXO or E1 interface.
8. SIP registration and individual call need to be supported.
4 Broadband Trunked Multimedia Dispatching
4.1 General Requirements
1. The dispatcher is easy-to-use and achieves real-time allocation of personnel and resources.
2. The dispatcher comprises the multimedia dispatching and processing center, multimedia recording and playback server, Dispatch Console and inter-system connection gateways.
3. The MDC is a customized server and controls all services and processes media streams. Different
dispatching servers apply to different scenarios, including the vehicle scenario, single station scenario,
small network scenario, and large network scenario.
4. The DC is a terminal platform installed on laptops, desktops, or workstations where dispatchers work.
The DC provides man-machine interfaces (MMIs) for dispatching trunking voice services, HD videos,
and high speed data. The dispatchers can view the user information, the group information, the camera
information, the video messages, SMs, and MMs, and can also provide video functions, such as distributing, monitoring, recording, transcoding, and transferring videos to a TV wall.
5. The MRS provides on-demand services, media recording and media management functions, and access to cameras.
6. The dispatcher provides the graphical user interface (GUI) for comprehensive dispatching, and can
monitor the status of terminals on the GUI and their voices and videos for communication and dispatching.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 17 of 47
7. The dispatcher can interconnect with pure IP transmission networks, such as metropolitan area
networks (MANs) and satellite links. The MDC and DC in the system can be far apart from each other.
8. The dispatcher provides the application programming interfaces (APIs) for 3rd parties to develop
application programs. The enabled API enables the secondary development for customized DC. The
API for DC development can be provided in DLL controls mode. The developer can develop the DC
client software by using the languages and the platform of DLL controls.
9. The system can interconnect with various networks and devices, such as PSTN, GSM, CDMA, Wi-Fi, and TETRA, and satellite networks
10. The dispatcher supports hierarchical deployment, with dispatchers serving as either an upper-level dispatcher or a lower-level dispatcher in a network.
11. The dispatcher supports configuration of one or more virtual private networks (VPNs). VPN services
are separate from each other. Logically, users, groups, scheduling server, audio and video server, and gateways are divided to own different network permissions..
4.2 Specification Requirements
4.2.1.1 Capacity Specifications
1. Capacity specifications of an MDC in the four application scenarios
Category Item Vehicle Scenario
Single Station Scenario
Small Network Scenario
Large Network Scenario
User or group
registration
Maximum number of
registered (online)
users
100 1000 4000 100,000
Maximum number of
registered (online) groups
50 256 512 4000
Service
concurrency
Maximum number of
concurrent
services(voice, video,
SM, MM and other services)
50 128 512 2000
Voice service Maximum number of
concurrent voice transcoding channels
(between AMR and
G.711)
16 32 32 32
Video service Maximum number of
concurrent video transcoding channels
(between D1 and CIF)
4 4 4 4
Maximum number of
concurrent fixed cameras
4 4 N/A N/A
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 18 of 47
Category Item Vehicle Scenario
Single Station Scenario
Small Network Scenario
Large Network Scenario
Maximum number of
concurrent video-to-walls (720 P)
4 4 16 16
SM/MM Maximum length of an
SM
1000 bytes 1000 bytes 1000 bytes 1000 bytes
Maximum number of
SMs preset in a
terminal or DC
100 100 100 100
Maximum number of
SMs saved in a terminal or DC
1000 1000 1000 1000
Maximum number of
MMs saved in a
terminal or DC
100 100 100 100
Maximum time for
saving an offline SM
48 hours 48 hours 48 hours 48 hours
Maximum number of
concurrent SMs
10 SMs per
second
10 SMs per
second
20 SMs per
second
50 SMs per
second
Maximum data volume
of an MM
2 MB 2 MB 2 MB 2 MB
Maximum number of
concurrent MMs
5 MMs per
second
10 MMs per
second
15 MMs per
second
20 MMs per
second
Maximum number of
SMs saved in the system
10,000 100,000 400,000 2,000,000
Maximum number of
MMs saved in the
system
200 2000 8000 40,000
GPS location Maximum number of
concurrent GPS services (30s)
100 1000 3000 8000
Dispatching
console
Maximum number of
concurrent DCs
2 10 40 200
Fixed camera Maximum number of
registered fixed cameras
4 100 1000 10,000
Maximum number of
fixed cameras for polling
4 16 16 16
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 19 of 47
2. enhanced capacity specifications through the extended MDCs
Item Vehicle Scenario
Single Station Scenario
Small Network Scenario
Large Network Scenario
Maximum number of
concurrent video transcoding channels
(between D1 and CIF)
N/A 32 32 72
Maximum number of
concurrent voice
transcoding channels
(between AMR and G.711)
N/A 320 320 720
3. Capacity specifications of an MRS in the four typical scenarios
Item Vehicle Scenario
Single Station Scenario
Small Network Scenario
Large Network Scenario
Maximum number of
concurrent voice
recordings
50 128 512 512
Maximum number of
concurrent video recordings
8/D1 16/D1 256/D1 256/D1
Maximum number of
concurrent video forwards
8/D1 16/D1 256/D1 256/D1
Maximum number of
concurrent voice/video
recording playbacks
1 2 8 8
Maximum time for voice
recording (hour)
10000 100000 200000–1000000 1000000
Maximum time for video
recording (hour)
D1: 200
CIF: 800
D1: 2000
CIF: 8000
D1: 4000–200000
CIF: 16000–80000
D1: 20000
CIF: 80000
4.3 Features
4.3.1 Voice Service Management
1. The DC supports P2P calls (full duplex) for push to talk (PTT), PSTN/PLMN, and other DC users. It also supports group calls (half duplex) for PTT, TETRA, and other DC users
2. Break in: Force one of the two parties in a P2P call to log off and talk to the other party.
3. Preemptive call: Become the speaker in a group call.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 20 of 47
4. Forced release: Forcibly disconnect an ongoing P2P call, group call, or video monitor service.
5. Joining a group at a later time: If the number of the DC user's ongoing services reaches the maximum
supported number (four), the DC user cannot join a group with ongoing services. A DC user can join a group with ongoing services after the DCe user's ongoing service is released.
6. Mute a group call: If a DC user mutes a speaker, the DC user hears nothing from the speaker but other members can hear the speaker.
7. Missed call management: The DC automatically records missed call information. Users can call back or delete the information.
8. Event management: When users initiate emergency calls, the DC receives relevant event information.
The DC users can use the event information to initiate P2P calls and video monitor requests to the users, query the GIS information of the users, and delete the event information.
9. Dynamic Regrouping: The dispatcher can combine multiple UEs with multiple static group calls that have been registered to form a new dynamic group call and set up the call.
10. Temporary Group Call: The dispatcher 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.
4.3.2 Video Service Management
1. The DC can monitor videos played on PTT users' terminals and the cameras.
2. Revolve: Rotate the video by 90,180 or 270 degrees clockwise, and restore the video.
3. Video mute: Mute ongoing videos.
4. Video on screen and video off screen: Display or close videos on the multi-pane.
5. Video projection and non-projection: Display or close videos on the video wall.
6. Pan-tilt-zoom (PTZ) control: Adjust the tilt, zoom, focus, and aperture of the cameras.
4.3.3 Voice and Video Recording Management
1. P2P calls: The DC can record the conversation between DC users and save the recorded files to a local PC.
2. Group calls: The DC can record the group conversation among DC users and save the recorded files to
a local PC.
3. Video monitor: The DC can record videos uploaded by DC users and save the recorded files to a local PC.
4. This dispatcher 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.
4.3.4 SMS/MMS Service Management
The DC can send or receive SMs or MMs to or from a PTT user or another DC. In addition, the DC can
export sent or received SMs or MMs.
4.3.5 GIS Service Management
1. A handset terminal can enable or disable GPS location according to the command from the DC, and
display icons to indicate whether GPS location has been enabled.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 21 of 47
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. The server can configure the specific event types.
3. If GPS satellite searching fails or another fault occurs, a message is displayed on the handset terminal (not affecting current user operations), and the fault is reported to the DC.
4. On the e-map, the handset terminal status can be displayed when GPS data reporting is enabled, Satellite searching fails or GPS data reporting is disabled.
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. The e-map also supports overwriting alarming.
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. Users can configure and view surveillance presence on the e-map.
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, 15s, 30s, or 60s. The default
period is 30s.
11. The other functions supported on the e-map are handset terminal-triggered video surveillance, video
distribution, P2P video calls, P2P voice calls, and SMs.
4.3.6 User Group Management
1. Support the query of wireless users by user number, user name, user priority, SIP password, user
service permission, VPN of the user, VPN egress permission, and VPN ingress permission (SIP is short for Session Initiation Protocol; VPN is short for virtual private network).
2. Support the query of fixed users by user number, user name, user priority, SIP password, user type, VPN of user, VPN egress permission, and VPN ingress permission.
3. Support the query of groups by group number, group name, group priority, group type, maximum call
floor duration, group enable/disable status, and VPN of the group.
4. Support the query of group wireless users by user number, group number, and user priority in the group.
5. Support the query of group fixed users by user number, group ID, and user priority in the group.
6. Support to set up another group of selected static groups and users. This group is open to query and deletion.
7. Support to set up a group of selected users temporarily, and this group will be automatically deleted when the call is end.
4.3.7 Service Configuration Management
1. Support the query of call limitations by user number, whether an outgoing call is forbidden, forbidden
type of outgoing calls, starting number of forbidden outgoing calls, ending number of forbidden
outgoing calls, whether an incoming call is forbidden, forbidden type of incoming calls, starting
number of forbidden incoming calls, and ending number of forbidden incoming calls, and support the addition, modification, and deletion of a call limitation.
2. Support the query of call transfers by user number, transfer target number, and call active/deactive
status, and support the addition, modification, and deletion of a call transfer.
3. Support state messages of DCs by state code and state value, and support the addition, modification, and deletion of a state message.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 22 of 47
4. Support the query and view of GIS information of fixed camera by user number of the fixed camera,
latitude of the fixed camera, altitude of the fixed camera, and installation location of the fixed camera, and support the addition, modification, and deletion of GIS information of fixed camera.
5. Supports the configuration of recording policies for all users or groups, and support the query, modification, and deletion of them.
6. Menu on the dispatcher side: An additional menu panelneeds to be provided for the display to allow
the type of calls to be selected such as pre-set PA messages (digital voice stored on the hard disk),
normal voice, status, priority, or emergency calls.
7. Dispatcher window templates: The controller needs to be able to set up individual user screen
configurations, namely different controller window templates. The terminal needs to save and recall
screen layouts defined by different users, allowing different controllers to quickly call up preference
files based on the log-in role of the controller.
4.3.8 Security Management
1. The dispatcher needs to incorporate the access control (AC) feature and provide a password-protected
login dialog box to ensure AC and security and validation of access permission. When the system is switched on, the dispatcher needs to be set to the default condition for available buttons and actions.
2. A password-protected exit dialog box needs to be provided and activated when the button is pressed to ensure that the user really wants to exit the system.
3. User management includes query, addition, modification, and deletion of user accounts and their rights.
4.3.9 VPN
1. The super administrator can divide users into different VPNs based on their telephone numbers, and each VPN is configured with a VPN administrator and VPN scheduling operator.
2. VPN-based separation is achieved scheduling and services, including voice services, video services,
short messages, multimedia messages, and GIS positioning services.
3. A Terminal or dispatcher person can manage user data and service data, and replay audio and video files in the VPN to which it belongs.
4. User permissions on VPN outgoing and incoming of PTP calls can be set.
4.3.10 Hierarchical Deployment
1. The dispatch platform supports hierarchical deployment, with dispatchers serving as either an upper-level dispatcher or a lower-level dispatcher in a network.
2. An upper-level dispatcher operates in a eLTE system or an emergency dispatch vehicle. A lower-level dispatcher operates in an emergency dispatch vehicle.
3. An upper-level dispatcher communicates with a lower-level dispatcher in the following ways, Wired
backhaul, Satellite backhaul and Microwave backhaul
4. the upper-level dispatching console can group together users managed by an upper-level dispatcher
and users managed by different dispatchers. Lower-level users can communicate with upper-level
users or with each other in ways of private voice calls, group voice calls, emergency calls, video uploading, and video distribution.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 23 of 47
5 Base Station
5.1 General Requirements
1. The proposed base station must support a frequency band of 1.8GHz (1785MHz~1805MHz) or
1.4GHz（1447MHz~1467MHz）or 400MHz（380MHz~400MHz）or 800MHz (Download 791 MHz～
821 MHz, Upload 832 MHz～862MHz).
2. The baseband module and radio module of proposed base station must support distributed architecture.
3. The maximum bit rates per base cell over 20MHz wide channels must be 100Mbit/s for downlink and 50Mbit/s for uplink.
4. The base station must support scalable spectrum bandwidth configuration of 5 MHz/10 MHz/20 MHz.
(Note: Products with 1.4 GHz do not support 5 MHz, and 400 MHz can support 3 MHz channel
bandwidth.)
5. To reduce the total cost of operation (TCO) of the base station, the proposed base station must support
the distributed architecture that includes base band unit (BBUs) and remote radio unit (RRUs). BBUs
are connected to RRUs through optical cables over the common public radio interface (CPRI). The
maximal CPRI throughput must support 4.9Gbit/s.
6. The proposed base station must support “Fallback mode”. When the Core Network Device is down,
the eBBU starts the Fallback mode; it will ensure that all the services under the eNodeB work normally.
7. To reduce power consumption of the base station, the power amplifier efficiency of the proposed base station must be 40% less than the average level in the industry.
8. The transmit power of the base station at top of the cabinet must be at least 20W and be adjustable in a
specified ratio.
9. The maximum throughput per base station must be 450 Mbit/s for downlink and 300 Mbit/s for uplink.
10. The proposed base station must support a maximum of 12 cells (Note:for4T4R 20MHz,only support 6 cells).
11. Each base station must support a maximum of 3600 active users (RRC_connected) at channel
bandwidth of 5 MHz/10 MHz/20 MHz. The RF connector type of the base station must be N-type 50 Ohm.
12. The proposed system must support uplink power control and dynamic downlink power allocation. Vendor needs to provide detailed information about the power control mechanism.
13. The proposed base station must support the following modulation: DL/UL QPSK, DL/UL 16QAM, and DL 64QAM.
14. The proposed base station must support trunking services and the maximum group number per cell
needs to be 80 groups (5 MHz channel bandwidth), 120 groups (10 MHz channel bandwidth), and 160 groups (20 MHz channel bandwidth).
15. Trunking group call set up time of the base station must be less than 300 ms.
16. The proposed base station must support the redundant and hot swappable power supply modules.
17. The proposed base station must provide alarm notification when the cabinet is open, or overheat or high FER occurs.
18. The capacity of battery backup system for the base station must be no less than -48V 184Ah.
19. The number of the wireless data radio bearers per user must be no less than 8.
20. The base station must support transmitter diversity, adaptive MIMO schemes, open-loop spatial multiplexing, closed-loop spatial multiplexing, and closed-loop rank-1 pre-coding.
21. The base station must support MS category 2/3/4.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 24 of 47
22. Maximum throughput of MAC layer per base station must be no less than 300 Mbit/s for uplink and
450 Mbit/s for downlink.
23. The capacity of the active users per base station must be no less than3600.
24. The radio module of proposed base station must support cascading.
5.1.1 BBU Requirements
1. The BBU must support GPS synchronization.
2. The proposed BBU must support 3 cells per Base Station (Note: for 4T4R 20M,only support 1 cell).
3. The proposed BBU must be installed in a free space with 19-inch width and 2U height.
4. The proposed BBU must support two FE/GE optical interfaces, or one FE/GE optical interface and
one FE/GE electron interfaces, or two FE/GE electronic interfaces.
5. The proposed BBU must provide an OM channel towards the local maintenance terminal (LMT) or OMC.
6. The proposed BBU must provide clock ports for clock synchronization, alarm monitoring ports for
environment monitoring, and a Universal Serial Bus (USB) port for commissioning the use of a USB
storage device.
7. The proposed BBU must manage the entire base station by means of operation and maintenance (OM) and signaling message processing.
8. The porposed BBU must support CNPU (Core network processing unit) which provides fallback mode capability.
9. The proposed BBU must support UEIU(Environment monitoring module),when the UPEUc cannot
meet the monitoring requirement from users, the UEIU needs to be configured. The UEIU shares a
slot with the UPEUc. When two UPEUc are configured for hot backup, the UEIU cannot be configured but can be replaced by the second UPEUc.
10. The proposed BBU must support UFLPb (FE/GE surge protection module) which can be configured
in any slot on BBU. It is recommended that the UFLPb be installed in slot 6 when BBU is configured
with one LMPT. The UFLPb is preferred to be inserted into the SLPU surge protection box. The
UFLPb supports surge protection on FE/GE ports.The proposed BBU must support IP20 for the ingress protection rating.
11. The proposed BBU must support a maximum of 12 cells(Note:for4T4R 20MHz,only support 6 cells).
12. The proposed BBU must support star type, chain type, and load sharing network topologies.
13. The proposed BBU must support the IP Sec protocol to provide secured backhaul transmission.
14. The proposed BBU must support at least 6 CPRI interfaces per BBU.
15. The proposed BBU must be modularly assembled to meet different requirements of network capacity and faulty board replacement.
16. The proposed BBU must have an expansion capability by inserting boards without impacting the
existing service and system performance.
17. The weight of one fully equipped BBU must be less than 12 kg.
18. Normal power supply for the BBU must be -48V DC (-38.4V DC to -57V DC).
19. The proposed BBU must be support work in environment temperature of -20°C~+55°C.
5.1.2 1.8GHz 4 PATH RRU Requirements
1. The RRU must be installed on a pole, wall, or stand.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 25 of 47
2. The RRU can be installed close to the antenna to shorten feeder length, reduce signal loss, and
improve system coverage.
3. The RRU must be serve to modulate and demodulate baseband signals and RF signals, process data, amplify power and detect standing waves.
4. The RRU must support a frequency band of 1.8G(1785MHz~1805MHz).
5. RRUs must support 20 W output powers per channel.
6. The volume of 4T4R RRU must be less than18.5 liters and weight must be less than 18.5 kg.
7. Receiving sensitivity of the RRU must support -103.5 dBm.
8. Normal power supply of the RRU must be -48V DC(-36V DC to -57V DC) or 220V AC(90V AC to 290V AC).
9. The typical average power consumption per RRU must be no more than 350 W.
10. The typical max power consumption per RRU must be no more than 465 W.
11. The RRU must support the natural cooling mechanism instead of a fan.
12. The RRU can be deployed remotely and the maximum distance between an RRU and a BBU must be 20 km.
13. The RRU must support environment temperature from -40°C to 55°C.
5.1.3 1.4GHz 8 PATH RRU Requirements
1. The RRU must be installed on a pole, wall, or stand.
2. The RRU can be installed close to the antenna to shorten feeder length, reduce signal loss, and improve system coverage.
3. The RRU must be serve to modulate and demodulate baseband signals and RF signals, process data, amplify power and detect standing waves.
4. The RRU must support a frequency band of 1.4GHz（1447MHz~1467MHz）.
5. RRUs must support 8 W output powers per channel at 2:2 time slot ratio or 6 W output powers per channel at 1:3 time slot ratio.
6. The volume of 8T8R RRU must be less than 24 liters and weight must be less than 24 kg.
7. Receiving sensitivity of the RRU must support -103 dBm.
8. Normal power supply of the RRU must be -48V DC(-36V DC to -57V DC).
9. The typical average power consumption per RRU must be no more than 250 W.
10. The typical max power consumption per RRU must be no more than 300 W.
11. The RRU must support the natural cooling mechanism instead of a fan.
12. The RRU can be deployed remotely and the maximum distance between an RRU and a BBU must be 20 km.
13. The RRU must support environment temperature from -40°C to 45°C(2:2 time slot ratio+8W/Path or
1:3 time slot ratio+6W/Path) or -40°C to 50°C(2:2 time slot ratio+6W/Path or 1:3 time slot ratio+5W/Path).
5.1.4 400MHz 2 PATH RRU Requirements
1. The RRU must be installed on a pole, wall, or stand.
2. The RRU can be installed close to the antenna to shorten feeder length, reduce signal loss, and
improve system coverage.
3. The RRU must be serve to modulate and demodulate baseband signals and RF signals, process data, amplify power and detect standing waves.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 26 of 47
4. The RRU must support a frequency band of 400M（380MHz~400MHz）.
5. RRUs must support 20 W output powers per channel.
6. The volume of 2T2R RRU with must be less than 18 liters and weight must be less than 18 kg.
7. Receiving sensitivity of the RRU must support -103.5dBm at 5MHz/10MHz/20MHz channel bandwidth or -104.5 dBm at 3MHz channel bandwidth.
8. Normal power supply of the RRU must be -48V DC(-36V DC to -57V DC).
9. The typical average power consumption per RRU must be no more than 220 W.
10. The typical max power consumption per RRU must be no more than 320 W.
11. The RRU must support the natural cooling mechanism instead of a fan.
12. The RRU can be deployed remotely and the maximum distance between an RRU and a BBU must be 20 km.
13. The RRU must support environment temperature from -40°C to 55°C.
5.1.5 1.8GHz 2 PATH RRU Requirements
1. The RRU must be installed on a pole, wall, or stand.
2. The RRU can be installed close to the antenna to shorten feeder length, reduce signal loss, and improve system coverage.
3. The RRU must be serve to modulate and demodulate baseband signals and RF signals, process data, amplify power and detect standing waves.
4. The RRU must support a frequency band of 1.8G(1785MHz~1805MHz) .
5. RRUs must support 20 W output powers per channel.
6. The volume of 2T2R RRU must be less than 12.5 liters and weight must be less than 12.5 kg.
7. Receiving sensitivity of the RRU must support -102 dBm.
8. Normal power supply of the RRU must be -48V DC(-36V DC to -57V DC).
9. The typical average power consumption per RRU must be no more than 190 W.
10. The typical max power consumption per RRU must be no more than 250 W.
11. The RRU must support the natural cooling mechanism instead of a fan.
12. The RRU can be deployed remotely and the maximum distance between an RRU and a BBU must be 20 km.
13. The RRU must support environment temperature from -40°C to 50°C.
5.1.6 800MHz 2 PATH RRU Requirements
1. The RRU must be installed on a pole, wall, or stand.
2. The RRU can be installed close to the antenna to shorten feeder length, reduce signal loss, and improve system coverage.
3. The RRU must be serve to modulate and demodulate baseband signals and RF signals, process data,
amplify power and detect standing waves.
4. The RRU must support a frequency band of 800MHz(Download 791 MHz～821 MHz, Upload 832
MHz～862MHz).
5. RRUs must support 40 W output powers per channel.
6. The volume of 2T2R RRU without shell must be less than 18 liters and weight must be less than 17.5 kg.
7. The volume of 2T2R RRU with shell must be less than 25 liters and weight must be less than 20 kg
8. Receiving sensitivity of the RRU must support -106.4 dBm at 1T1R.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 27 of 47
9. Receiving sensitivity of the RRU must support -109.2 dBm at 1T2R
10. Normal power supply of the RRU must be -48V DC(-36V DC to -57V DC).
11. The power consumption per RRU must be no more than 300 W.
12. The RRU must support the natural cooling mechanism instead of a fan.
13. The RRU can be deployed remotely and the maximum distance between an RRU and a BBU must be 20 km.
14. The RRU must support environment temperature from -40°C to 50°C(1120W/ m² solar radiation).
15. The RRU must support environment temperature from -40°C to 55°C(without solar radiation).
5.1.7 High Availability Design
1. The base station must support CPRI interface backup.
2. The RRU must support channel failure detection under multi-antenna configuration. It must be able to fall back to the single antenna mode when a failure occurs on maintain system reliability.
3. The BBU must support ingress protection 20 and the RRU must support ingress protection 65.
4. The working temperature of the BBU must support -20°C to +55°C.
5. The system availability of base station must be more than 99.999%.
6. The time required for the system reset of the base station must be less than 450 s.
7. The mean time between failures of base station must be more than 155000 hours.
8. The mean time to repair of the base station must be less than 1 hour.
5.2 Standard Compliance
1. The base station must comply with the following storage environmental standards: ETSI
EN300019-1-1 V2.1.4 (2003-04) class1.2 "Weather protected, not temperature-controlled storage
locations".
2. The base station must comply with the following transportation environmental standards: ETSI EN300019-1-2 V2.1.4 (2003-04) class 2.3 "Public transportation".
3. The base station must comply with the following anti-seismic performance standards: Interim
Provisions for Test of Anti-seismic Performances of Telecommunications Equipment
(Telecommunication Industry Standard of the People's Republic of China).
4. The base station must meet electromagnetic compatibility requirements, and comply with the
following standards: R&TTE Directive 1999/5/EC, R&TTE Directive 89/336/EEC, 3GPP TS 36.113, ETSI EN 301489-1/23, ETSI EN 301908-1 V2.2.1 (2003-10), ITU-R SM.329-10,CTA,CE,RoHS.
6 Core Network
6.1 General Requirements
1. The proposed CN must be modular expandable to increase call capacity, radio site capacity, and
gateway capacity. Expansions during the lifetime of the infrastructure must not require replacement of equipment.
2. The proposed CN must support different services (such as subscriber data management, mobility
management, voice trunking, and gateway) with a coherent range of equipment in order to avoid
separate and unmanageable solutions.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 28 of 47
3. The proposed CN must use non-proprietary OSs as the basis for all software- and firmware-based
components in order to ensure long-term maintenance of the products, and must be certified in real time for carrier grade availability and performance.
4. The proposed CN hardware must allow software upgrades during the lifetime of the system in order to deliver new functions and bug fixes, without replacing or upgrading equipment.
5. The proposed CN hardware must be several modalities applying to different scenarios, which applies to the large (1500 base stations), middle (30base stations), and small (single base station) scale.
6. The vendor must provide high integrated core network. The hardware solution must be compact. It
enables the MME, P-GW, S-GW, and HSS to be deployed in one cabinet.
6.2 Specification Requirements
The dimension of the CN for the large scale network must be less than 14U. The following table lists the specifications.
Item Name Value
(Maximum Subscriber Number) 200,000
(Maximum Subscribed Group Number) 20,000
(Maximum Base Station Number) 1500
(Maximum Subscriber Number Per Group) 1000
(Maximum Activation Voice Call Number) 1000
The dimension of the CN for the middle scale network must be less than 2U. The following table lists the specifications.
Item Name Value
(Maximum Subscriber Number) 4000
(Maximum Subscribed Group Number) 512
(Maximum Base Station Number) 30
(Maximum Activation Voice Call Number) 512
(Maximum Subscriber Number of a Group) 1000
The dimension of the CN for the small scale network must be integrated in the base station. The following table lists the specifications.
Item Name Value
(Maximum Subscriber Number) 1000
(Maximum Group Number) 256
(Maximum Base Station Number) 1
(Maximum Activation Voice Call Number) 128
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 29 of 47
Item Name Value
(Maximum Subscriber Number of a Group) 1000
6.3 High Reliable Requirements
1. All business software modules or processes of a large-scale network must support redundancy. In case
of equipment or software failures, the switchover to redundant modules or processes must be
automatic and must be completed in a maximum of 2 seconds. MSs must not go out of services or
require re-registration when switching over to the redundant module or process.
2. Vendors must describe whether the system is considered as a carrier class. The solution availability must reach 99.999%.
3. The proposed CN product must support 1+1 board redundancy.
4. The whole power consumption of the CN must be less than 3500 W in large scale scenario with maximum and redundant configuration, and 110 W in middle scale scenario.
5. Long term work temperature of the proposed CN must support 5°C to +45°C in large scale scenario
and -20°C to +50°C in middle scale scenario.
6. Short term work temperature of the proposed CN must support -5°C to +50°C in large scale scenario
and -50°C to +55°C in middle scale scenario.
7. Temperature for storage of the proposed CN must support -40°C to +70°C in large scale scenario.
8. .
9. Long term relative humidity of the proposed CN must support 5% to 85% in large scale scenario and 5% to 95% in middle scale scenario.
10. Normal power supply for the proposed CN must be -40V DC to -72V DC in large scale scenario and -38.4V DC to -57V DC in middle scale scenario..
6.4 Features
6.4.1 QoS Requirements
1. The proposed CN QoS implementation must comply with the 3GPP TS 23.401 protocol.
2. The proposed CN must support packet classification: DiffServ (DSCP) and 802.1p/Q.
3. The proposed CN must support multiple queue types: Strict-Priority queue, Weighted Round Robin queue, and Weighted Fair Queuing.
6.4.2 Security Requirements
1. The proposed CN must support the subscriber authentication function to realize subscriber
identification, authentication, and synchronization using encryption key. The function can be used to
check the validity of a subscriber's service request and ensure that only legal subscribers can use network services.
2. The authentication on the network is bi-directional. Subscribers can use this function to avoid access to unknown networks, and therefore avoiding security risks.
3. The proposed CN must provide user identity encryption to avoid the risk of the user identity (IMSI)
being stolen.
4. The proposed CN must support NAS signaling encryption and integrity protection to improve the system security. The NAS signaling encryption and integrity support SNOW 3G and AES.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 30 of 47
6.4.3 Transmission Requirements
1. The proposed CN in a large scenario must support no less than 40 Gbit/s data throughput.
2. The proposed CN in the middle and small scenarios must support no less than 2 Gbit/s data throughput.
3. The proposed CN gateway in a large scenario must support the GE/10GE optical port.
4. The proposed CN must support the VLAN sub-interface.
5. The proposed CN must support the VPN.
6.4.4 Service Requirements
1. The proposed CN must provide packet data services to the MS although it is engaged in an individual call.
2. The proposed CN must provide packet data services to the MS although it is engaged in group call.
3. The proposed CN must enable the terminal to create several PDN connections to access different networks. This feature allows subscribers to access several networks at the same time.
4. The proposed CN must support routing behind the CPE technology. By using this function, several
terminals can access the network through the CPE and support bidirectional communications.
5. The proposed CN must support radius interfaces, and can connect to the AAA server over the radius interface. MS authentication and IP address assigning are performed on the same AAA server.
6.4.5 OM Requirements
1. The proposed CN must support the upgrade of all software at the same time, which can reduce the upgrade time.
2. The proposed CN must support online patch features and can correct the fault without interrupting services.
3. The proposed CN must support performance date acquisition, which is important for measurement, design, operation, and network management.
4. The proposed CN must support real-time fault alarm reporting, and can handle the fault according the
alarm.
5. The proposed CN must support equipment management functions, graphical equipment monitoring,
and equipment control (including rearrangement, reset, and forbidden), objects (including boards,
ports, links, and logical entities). It also supports equipment testing. The test function is an important
way for locating problems. Provide port, link's ring tests and connectivity tests.
6. The proposed CN must support security management to ensure that only authorized users can use the
system. System security includes account management, authorization management, operation period control, account validity control, terminal control, account lockout policy, password policy, and log.
7. The proposed CN must support subscriber tracing and interface tracing. The subscriber tracing
includes signaling and data tracing based on the IMSI or MSISDN; the interface tracing is S1
signaling message trace.
8. The log management supports the runtime log, debug log, operation log, and security log. Log management manages all log files, and provides the log export and upload functions.
7 Terminal
1. The proposed terminal must comply with the 3GPP R8 and R9 standards.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 31 of 47
2. The proposed vendor must provide a series of terminal products, which includes but are not limited to
broadband trunked radio handsets, explosion proof handsets, mobile office terminals, USB dongles, vehicle mounted terminals, broadband access terminals, and miniPCIe LTE cards for customization.
7.2 Professional Multimedia PTT Handset
7.2.1 Overview
1. The contractor must provide handheld radios with the full function key model.
2. The proposed handset must integrate private calls, PTT, broadband data, SMSs/MMSs, video surveillance, and video dispatching for easy operation and smooth collaboration.
3. The proposed handset must comply with IP67 protection for dust-proof and waterproof.
4. The proposed handset must comply with MIL-STD-810F standards for anti-drop. The handheld
terminals must be robust, water-spilling-proof, and enclosed by a die-cast chassis or can withstand
dropping test at 1.5 m above concrete ground without any damage.
5. The proposed handset must provide emergency buttons on the equipment. The emergency buttons must be designed not to be evoked easily by an inadvertent action.
6. The proposed handset radio must contain a "screw-in" type of detachable antenna, a belt clip, and a battery.
7. The proposed handset radio must have the "auto power off" feature to protect the battery from
over-discharging at low voltage. It must not consume any power when the radio is switched off.
8. The proposed handset must support 400 MHz spectrum.
9. The proposed handset must support dual microphone to guarantee the work in a noisy environment.
10. The proposed handset must support 802.11b/g/n and Wi-Fi hot spot.
11. The proposed handset must support two cameras. The rear camera resolution must be 5M pixel and
the front camera resolution must be 1.3M pixel.
12. The proposed handset must support to connect to USB camera. Video quality must be up to D1. Video data can be simultaneously displayed in the local and uploaded to the command center.
13. The proposed handset must support the connection to a Wi-Fi camera. Video quality must reach 1080P. Video data can be uploaded to the command center.
14. The proposed handset must support the USB 2.0 interface for connecting to a PC.
15. The proposed handset must support the One click video uploading.
16. The proposed handset must support E2E hardware encryption and the length of the encryption key is
256 bits.
17. The proposed handset design must be highly recognized by the industry. Vendors must provide proofs for the industry to recognize the IF Product Design Award.
7.2.2 Display Window
1. The proposed handheld radio must have a backlight display window with 2.4 inches QVGA 240*320
TFT screen at least.
2. The display window can display the following information:
− Calling party identification
− Incoming call mode including individual call, group call, emergency call, and system call message
− Real-time signal strength
− Real-time battery power level
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 32 of 47
7.2.3 Indicators and Switches
1. The proposed handheld radio needs to incorporate the following indicators and switches at least:
− Rotary switch for volume control and button or switch for power-on or -off control
− Rotary switch that allows a minimum of 20 talk groups at a time and a minimum of 20 ranges using the menu button for more talk group selection.
− Set automatic on or off time for the backlight through the menu.
− Call feature selection key
− Call feature scroll key
− Software programmable key
− PTT switch
− Transmit indicator
− Power-on indicator
− Built-in camera for enabling quick photographing of important scenes
− Built-in GPS for facilitating location-based services
2. The RF power needs to be adjusted automatically according to the distance. It is away from the base station.
3. Audible or visual indication must be available in low battery status.
7.2.4 Transceiver
1. The proposed handset must support voice services with the direct mode operation (DMO) function in areas without radio covered.
2. The proposed handset must support the operating temperature from -20°C to 60°C.
3. The proposed handset must support the RF power output with 200 mW at least.
4. The proposed handset must support the working bandwidth of 20 MHz.
5. The proposed handset must support the following modulation: DL/UL QPSK, DL/UL 16QAM, and DL 64QAM.
6. The proposed handset must support a minimum of 4 Mbit/s data throughput.
7. The proposed handset must support 3 MHz at -102 dBm, 5 MHz at -100 dBm with sensitivity, 10
MHz at -97 dBm, 20 MHz at -94 dBm.
8. The proposed handset must support temporary activation and deactivation for radio management.
9. The proposed handset must support permanent and remote activation and deactivation.
10. The proposed handset must support the built-in GPS feature and the accuracy needs to reach 10 meters.
7.2.5 Handheld Radio Accessories
1. The proposed handset must support a clip on speaker's extension microphone or the speaker can wear
the handheld on the chest.
2. The proposed handset must support connect PTT handheld microphone, and the handheld microphone must support IP55 protection.
3. The proposed handset must support the carrying case with a strap and shoulder strap.
4. The proposed handset must support the earpiece and the clips of a handheld.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 33 of 47
7.2.6 Built-in Test Routine
1. Built-in test routines must test the handheld radio. These routines must operate in offline mode to allow a complete functional test for a problematic module.
2. Built-in test routines must be initiated in the following scenarios:
− Local maintenance commands connecting to a local maintenance port through a notebook computer
− Self-check during the power-on initialization
7.2.7 Battery Charger
1. The contractor needs to provide a single unit desktop battery charger whose AC mains are 240 V + 10%
for each handheld radio terminal, a single phase at 50 Hz + 5% for the recharging of battery packs
complete with overcharged and over-discharged protection. The charger must have suitable protection against wide voltage variations and transients.
2. AC main voltage circuits must be isolated from low voltage circuits, and all exposed metal parts of the charger must be properly earthed by an earth continuity conductor to the mains plug.
3. The provided battery charger must have the following facilities at least:
− Power-on or charging-in-progress indication
− Quick charge mode
− Battery pack fully charged indication
4. The charger must provide automatic charging current regulation (constant current), including
avoidance of overcharging and regulation by cell temperature sensing. It must have trickle charging
capability after a full charge.
7.2.8 Battery Unit
1. The proposed handheld radio battery unit must support leak-proof.
2. The proposed handheld radio battery unit must be lithium ion battery and does not have any memory
effect.
3. The proposed handheld radio must be provided with one spare battery. Two numbers (02) of the spare battery must be provided for each handheld radio.
4. The fully charged handheld radio battery must supply a minimum of 15 hours power for the handheld radio with continuous operations at 5/5/90 cycle.
5. The fully charged handheld radio battery must supply a minimum of 30 hours power for the handheld
radio with continuous operations in DMO mode.
6. The proposed handheld radio battery pack must be securely and firmly connected to the handheld radio using a simple-locking mechanism. No tools need to connect to or disconnect from the battery.
7. The proposed handheld radio battery must sustain a minimum of 400 charging and recharging cycles without degrading by 10% of the nominal operating voltage.
7.2.9 Software
1. The proposed handset must support up to 720p 25fps HD video transmission, and support adaptive video coding to reduce the requirements on bandwidths.
2. The proposed handset must support 12.2K and 4.75K voice coding mode, to leverage different voice quality and radio coverage requirements.
3. The proposed handset must support SMS and MMS. One SMS transmission must support up to 1000
bytes. One MMS transmission must support up to 2 MB for high definition picture. The handset can store 1000 SMSs and 100 MMSs.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 34 of 47
4. The proposed handset must support predefined SMSs for reporting user status and also emergency
SMSs. All predefined SMSs can be flexibly configured in the handset.
5. The proposed handset must support the open of the secondary development standard interface for the third party according to industry characteristics.
6. The proposed handset must support the OTA function, to upgrade software and modify configuration data remotely.
7. The proposed handset must support man-down alarms for human safety.
8. The proposed handset must support the hot MIC function for an emergency multimedia PTT call.
7.3 Vehicle Mounted Terminal
7.3.1 Overview
The proposed vehicle-mounted terminal must support private calls, PTT, broadband data, SMSs/MMSs,
video surveillance, and video dispatching for easy operation and smooth collaboration.
7.3.1.1 voice trunking requirements
1. PTT setup delay must be less than 300 ms..
2. Call preemption delay must be less than 150 ms.
3. The proposed vehicle mounted terminal must support DMO mode operation.
7.3.1.2 multimedia dispatching requirements
1. The proposed vehicle mounted terminal must integrate with functions such as private calls, group calls, SMS, MMS, video uploading, and mobile office.
2. The proposed vehicle mounted terminal must support 1080P 25fps high definition video transmission, dispatching and distribution.
3. The proposed vehicle mounted terminal must support attached USB/FE cameras for applications in
complicated environments.
4. The proposed vehicle mounted terminal must support one-click video uploading and one-click photo uploading.
7.3.1.3 Encryption requirements
1. The proposed vehicle mounted terminal must support bidirectional authentication and air interface
encryption.
2. The proposed system must support AES encryption algorithm.
7.3.2 Hardware
1. The proposed vehicle-mounted terminal must support the operation at 400 MHz.
2. The proposed vehicle-mounted terminal must support the operation at 20 MHz frequency bandwidth.
3. The proposed vehicle-mounted terminal must support 2.4 inches QVGA 240*320 TFT screen at least.
4. The proposed vehicle-mounted terminal must support an intelligent operating system that allows customized development based on industry requirements.
5. The proposed vehicle-mounted terminal must support air interface encryption, E2E encryption, and remote activation or deactivation of the terminal.
6. The proposed vehicle-mounted terminal must comply with IP54 protection for dust-proof and waterproof.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 35 of 47
7. The proposed vehicle-mounted terminal must support the external antenna interface for better
coverage.
8. The proposed vehicle-mounted terminal must support 802.11b/g/n and Wi-Fi hot spot.
9. The proposed vehicle-mounted terminal must support the operating temperature from -40°C to 60°C.
10. The proposed vehicle-mounted terminal must support the 12V DC power supply from vehicle.
11. The proposed vehicle-mounted terminal must support BT 1.2/2.0/2.0+EDR and support data
transmission between BT equipment.
12. The proposed vehicle-mounted terminal must support USB 2.0.
13. The proposed vehicle-mounted terminal must support the hot MIC key for user's emergency call.
7.3.3 Software
1. The proposed vehicle-mounted terminal must support professional trunked radio services, such as
private calls, group calls, and emergency calls.
2. Group setup delay of the proposed vehicle-mounted terminal must be less than 300 ms.
3. The proposed vehicle-mounted terminal must support vehicle-mounted video surveillance.
4. The proposed vehicle-mounted terminal must support video distribution from the command center.
5. The proposed vehicle-mounted terminal must support HD video H.263 and H.264 and 15fps QVGA.
6. The proposed vehicle-mounted terminal must support WAP2.0 access.
7. The proposed vehicle-mounted terminal must support air interface integrity.
8. The proposed vehicle-mounted terminal must support PC tool configuration.
9. The proposed vehicle-mounted terminal must support power-on password.
10. The device must support web-based management.
7.4 Data Transmission Terminal
7.4.1 Overview
The CPE needs to provide standard interfaces to connect cameras, sensors, and computers for high speed
data transmission.
7.4.2 Hardware
1. The CPE must support built-in LTE high gain antenna and the gain is greater than or equal to 8 dB.
2. The CPE must support the external antenna interface for better coverage.
3. The CPE must support 802.11b/g/n and Wi-Fi hot spot.
4. The CPE must comply with IP65 protection for dust-proof and waterproof.
5. The CPE must support the operating temperature from -40°C to 60°C.
6. The CPE must support the FE port.
7. The CPE must support the POE power supply for easy installation.
8. The CPE must support 1T2R for higher data throughput.
9. The CPE must support outside installation, including hanging on the wall, and mast and vehicle mounting installation.
10. The device must support LED indicators for displaying LAN status, power status, and signal level.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 36 of 47
7.4.3 Software
1. The CPE must support the configuration of the ratio of uplink data resources to downlink data resources as 3:1, 2:2, and 1:3 for flexible data traffic models.
2. The CPE must support a built-in DHCP server and NAT for easy network planning.
3. The CPE must support the TR-069 management protocol and remote network management, including alarm reporting, remote upgrade, link detection, status query, and self-healing.
4. The device must support web-based management.
8 Easy Network Management System
8.1 General
1. The proposed NMS solution must cover key functionality fields, such as topology management,
configuration management, performance management, fault management, software management,
security management, system management, terminal management, log management, and routine
equipment inspection.
2. The proposed NMS solution must support operations on both the PC and the Server platform.
3. The proposed NMS solution must integrate the network management solution and can be used to
manage nodes, such as the CN, base station, dispatcher server, and terminal. Management of all
subsystems must share the same hardware and software platform, GUI interface, and unified
management operation.
4. To meet requirements of centralized management and distributed access, the proposed NMS solution must be based on the client/server architecture.
5. The proposed NMS solution must provide broadband access management, handheld management, vehicle mounted terminal management and operation user management functions in advance.
6. The proposed NMS solution must provide human based GUI and command line operation and maintenance interface.
7. The proposed NMS solution must provide data security, operation security, software reliability,
hardware reliability functions to improve the reliability of NMS system.
8. The propose NMS solution must provide support for the diverse scenarios like emergency
commanding vehicle, isolated base station, micro, small, medium and large network. Equipment management and terminal management must support unified or separate deployment.
9. The proposed NMS solution must provide at least 2Mbps broadband version, configuration channel
for the remote upgrade of terminal in the air interface.
8.2 Feature(Server Platform Version)
8.2.1 Hardware Platform Requirement
1. The proposed NMS server hardware must support following requirements(50 eNodeB and 4000
Terminal only)
CPU Intel Xeon E5-2620
Memory No less than 16GB
Hard disk 3*600GB 2.5 inch 10K RPM 6Gbps, Support hot plug in
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 37 of 47
SAS hard disk
Power Consumption <750W
Weight <20kg
Power Supply 220V AC 50/60Hz, Scope 100～240V AC
2. The proposed NMS server hardware must support following requirements(200 eNodeB and 8000
Terminal only)
CPU Intel Xeon E5-2690
Memory No less than 32GB
Hard disk 6*600GB 2.5 inch 10K RPM 6Gbps, Support hot plug in
SAS hard disk
Power Consumption <750W
Weight <25kg
Power Supply 220V AC 50/60Hz, Scope 100～240V AC
3. The proposed NMS server hardware must support following requirements(500 eNodeB and 10000
Terminal only)
CPU 4 Intel Xeon E5-4620
Memory No less than 64GB
Hard disk 9*600GB 2.5 inch 10K RPM 6Gbps, Support hot plug in
SAS hard disk
Power Consumption <750W
Weight <26kg
Power Supply 220V AC 50/60Hz, Scope 100～240V AC
4. The proposed NMS client hardware must support following requirements:
CPU Intel E5300
Memory 2GB
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 38 of 47
Hard disk 160 GB hard disk
OS Windows 7.0 or Windows XP
8.2.2 Platform Function Requirement
1. The proposed NMS must support maintenance of base station, core network, dispatcher, broadband
access terminal and handset.
2. The proposed NMS must support 1+1 backup of core network.
3. The proposed NMS must support fallback mode of base station.
4. The proposed NMS must support hierarchical commanding of dispatcher.
8.2.3 Topology Management
1. The proposed NMS must support display of the network equipment and sub network.
2. The proposed NMS must support the creation and deletion of subnets, nodes, and links in a topology
view.
3. The proposed NMS must support modification of topology objects, including basic properties, and position of topology objects in a topology view.
4. The proposed NMS must support the search of specified nodes.
5. The proposed NMS must support customization of a topology view, and the display and hiding of specified nodes and links.
6. The proposed NMS must support the query of topology objects, including link information, details about nodes and alarm status.
8.2.4 Configuration Management
1. The proposed NMS must support centralized configuration management function which provide user friendly interface which support associative information for input.
2. The proposed NMS must blind initialization of base station and assign maintenance IP automatically.
3. The proposed NMS must support automatic download of configuration data during base station
initialization.
4. The proposed NMS must support configuration of typical scenarios by template.
5. The proposed NMS must support the query of configuration data about network nodes.
6. The proposed NMS must support synchronization of configuration data.
8.2.5 Performance Management
1. The proposed NMS must support unified collection of performance result data such as network throughput, reliability directive and error rates about the core network, dispatcher and base station.
2. The proposed NMS must support the backup of performance data about the core network and base
station.
3. The proposed NMS must support the export of performance data from the core network and base station.
4. The proposed NMS must support the query of performance data from the core network and base station.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 39 of 47
5. The proposed NMS must support the storage of the performance data query results as a customized
template for next query.
6. The propose NMS must support performance form of base station.
8.2.6 Fault Management
1. The proposed NMS must support real time alarm notification on network nodes.
2. The proposed NMS must support automatic and manual alarm synchronization.
3. The proposed NMS must support browsing of alarms.
4. The proposed NMS must support the display of topologies and positioning of alarms.
5. The proposed NMS must support the query of detailed information about alarms.
6. The proposed NMS must support separate alarm boxes.
7. The proposed NMS must support the forwarding and separate storage of alarm information.
8. The proposed NMS must support the clearance, identification, and cancelation of specified alarms.
9. The proposed NMS must support the redefinition or mask of alarms.
10. The proposed NMS must support statistics on alarms.
11. The proposed NMS must support separate alarm consoles.
8.2.7 Software Management
1. The proposed NMS must support centralized remotely management of software, batch and file of network equipment.
2. The proposed NMS must support version management of software and patch of a base station and core network.
3. The proposed NMS must support batch upgrade of software and patches of base stations and core network.
4. The proposed NMS must support one key upgrade of software and patch of a base station and core
network.
5. The proposed NMS must support the upload of node data files.
8.2.8 Security Management
1. The proposed NMS must support hierarchical management of a user account, including the user, user
group, operation aggregation, domain, and terminal type.
2. The proposed NMS must support centralized user and user group management.
3. The proposed NMS must support centralized user authentication.
4. The proposed NMS must support security strategy setting.
5. The proposed NMS must support automatic terminal locking.
8.2.9 System Management
1. The proposed NMS must be compatible with different nodes and networks of different versions.
2. The proposed NMS must support Windows XP and Windows 7 operation system.
3. The proposed NMS must support data backup and restore.
4. The proposed NMS must support self-operation monitoring of the NMS.
5. The proposed NMS must support synchronization of network time through NTP or SNTP.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 40 of 47
6. The proposed NMS must support blind startup of network nodes and the NMS can function as a
DHCP server.
7. The proposed NMS must support centralized task management.
8. The proposed NMS must support version adaption of network nodes.
9. The proposed NMS must support private DNS function.
10. The proposed NMS must support collection of network nodes asset information.
11. The proposed NMS must support one key log collection of network nodes.
12. The proposed NMS must support smooth upgrade of NMS system.
8.2.10 Handset & Vehicle Mounted Terminal Management
1. The proposed NMS must support software & configuration upgrade of handset and vehicle mounted terminal by OTA protocol.
2. The proposed NMS must support provide upgrade form of handset.
8.2.11 Broadband Access Terminal Management
8.2.11.1 Software Management
1. The proposed NMS must support the manually terminal software upgrade.
2. The proposed NMS must support the download of terminal software packages.
3. The proposed NMS must support the query of terminal software versions.
8.2.11.2 Configuration Flow
1. The proposed NMS must support the download of configuration data during the first access of a terminal.
2. The proposed NMS must support modification and backup of terminal configuration data.
3. The proposed NMS must support synchronization of terminal configuration update.
8.2.11.3 Status Query
1. The proposed NMS must support the query of terminal status.
8.2.11.4 Alarm
1. The proposed NMS must support the alarm management of broadband access terminal.
2. The proposed NMS must support alarm synchronization.
3. The proposed NMS must support alarm display.
4. The proposed NMS must support alarm statistics.
5. The proposed NMS must support acknowledgement of alarm.
6. The proposed NMS must support alarm comment.
7. The proposed NMS must support alarm query.
8. The proposed NMS must support remote email notification of alarm.
9. The proposed NMS must support store the alarm as the TXT, HTML, CSV format.
10. The proposed NMS must support voice and light notification of alarm box.
8.2.11.5 Diagnose
1. The proposed NMS must support self-check and remote restart of the terminal.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 41 of 47
2. The proposed NMS must support manually linkage diagnose of terminal.
8.2.11.6 Terminal Form
1. The proposed NMS must support terminal report display. The form shall include IMSI, IMEI, version,
terminal type and user number information.
8.2.12 Log Management
1. The proposed NMS must support operation and security information log of network equipment.
2. The proposed NMS must support remote log collection of network and terminal equipment.
8.2.13 Equipment Inspection
1. The proposed NMS must support task based routine inspection and parameter adjustment.
2. The proposed NMS must support manually inspection of network equipment.
8.2.14 Operation Management
1. The proposed NMS must support subscriber management, MDS subscriber data export, user status
query, public parameter configuration query, call record export, and MDS data export.
2. The proposed NMS must support the addition, modification, deletion, and searching of trunking group
information.
3. The proposed NMS must support the addition, deletion of authentication information.
4. The proposed NMS must support management of VPN user.
5. The proposed NMS must support management of PS data user.
6. The proposed NMS must support call number segment management function.
8.3 Feature(PC Platform Version)
8.3.1 Hardware Platform Requirement
1. The proposed NMS server hardware must support following requirements(10 eNodeB and 1000
Terminal and single base station only)
CPU Core i5-3470
Memory No less than 8GB
Hard disk 1Tb 7200 RPM
Power Consumption <300W
Weight <10kg
Power Supply 220V AC 50/60Hz, Scope 100～240V AC
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 42 of 47
8.3.2 Platform Function Requirement
1. The proposed NMS must support maintenance of base station, core network, dispatcher, broadband
access terminal and handset.
2. The proposed NMS must support fallback mode of base station.
3. The proposed NMS must support single PC deployment.
8.3.3 Topology Management
1. The proposed NMS must support display of the network equipment and sub network.
2. The proposed NMS must support the creation and deletion of subnets, nodes, and links in a topology view.
3. The proposed NMS must support modification of topology objects, including basic properties, and
position of topology objects in a topology view.
4. The proposed NMS must support the search of specified nodes.
5. The proposed NMS must support customization of a topology view, and the display and hiding of specified nodes and links.
6. The proposed NMS must support the query of topology objects, including link information, details about nodes and alarm status.
8.3.4 Configuration Management
1. The proposed NMS must support centralized configuration management function which provide user friendly interface which support associative information for input.
2. The proposed NMS must blind initialization of base station and assign maintenance IP automatically.
3. The proposed NMS must support automatic download of configuration data during base station initialization.
4. The proposed NMS must support configuration of typical scenarios by template.
5. The proposed NMS must support the query of configuration data about network nodes.
6. The proposed NMS must support synchronization of configuration data.
8.3.5 Performance Management
1. The proposed NMS must support unified collection of performance result data such as network throughput, reliability directive and error rates about the core network, dispatcher and base station.
2. The proposed NMS must support the backup of performance data about the core network and base
station.
3. The proposed NMS must support the export of performance data from the core network and base station.
4. The proposed NMS must support the storage of the performance data query results as a customized template for next query.
5. The propose NMS must support performance form of base station.
8.3.6 Fault Management
1. The proposed NMS must support real time alarm notification on network nodes.
2. The proposed NMS must support automatic and manual alarm synchronization.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 43 of 47
3. The proposed NMS must support browsing of alarms.
4. The proposed NMS must support the display of topologies and positioning of alarms.
5. The proposed NMS must support the query of detailed information about alarms.
6. The proposed NMS must support separate alarm boxes.
7. The proposed NMS must support the forwarding and separate storage of alarm information.
8. The proposed NMS must support the clearance, identification, and cancelation of specified alarms.
9. The proposed NMS must support the redefinition or mask of alarms.
10. The proposed NMS must support statistics on alarms.
11. The proposed NMS must support separate alarm consoles.
8.3.7 Software Management
1. The proposed NMS must support centralized remotely management of software, batch and file of network equipment.
2. The proposed NMS must support version management of software of a base station and core network.
3. The proposed NMS must support batch upgrade of software and patches of base stations and core network.
4. The proposed NMS must support one key upgrade of software and patch of a base station and core
network.
5. The proposed NMS must support the upload of node data files.(2U core network and base station only)
8.3.8 Security Management
1. The proposed NMS must support hierarchical management of a user account, including the user, user
group, operation aggregation, domain, and terminal type.
2. The proposed NMS must support build in admin and user account.
3. The proposed NMS must support centralized user authentication.
4. The proposed NMS must support security strategy setting.
5. The proposed NMS must support automatic terminal locking.
8.3.9 System Management
1. The proposed NMS must be compatible with different nodes and networks of different versions.
2. The proposed NMS must support multi-language customization.
3. The proposed NMS must support Windows XP and Windows 7 operation system.
4. The proposed NMS must support self-operation monitoring of the NMS.
5. The proposed NMS must support synchronization of network time through NTP or SNTP.
6. The proposed NMS must support blind startup of network nodes and the NMS can function as a DHCP server.
7. The proposed NMS must support centralized task management.
8. The proposed NMS must support version adaption of network nodes.
9. The proposed NMS must support private DNS function.
10. The proposed NMS must support collection of network nodes asset information.
11. The proposed NMS must support one key log collection of network nodes.
12. The proposed NMS must support smooth upgrade of NMS system.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 44 of 47
8.3.10 Handset & Vehicle Mounted Terminal Management
1. The proposed NMS must support software & configuration upgrade of handset and vehicle mounted terminal by OTA protocol.
2. The proposed NMS must support provide upgrade form of handset.
8.3.11 Broadband Access Terminal Management
8.3.11.1 Software Management
1. The proposed NMS must support the manually terminal software upgrade.
2. The proposed NMS must support the download of terminal software packages.
3. The proposed NMS must support the query of terminal software versions.
8.3.11.2 Configuration Flow
1. The proposed NMS must support the download of configuration data during the first access of a terminal.
2. The proposed NMS must support modification and backup of terminal configuration data.
3. The proposed NMS must support synchronization of terminal configuration update.
8.3.11.3 Status Query
1. The proposed NMS must support the query of terminal status.
8.3.11.4 Alarm
1. The proposed NMS must support the alarm management of broadband access terminal.
2. The proposed NMS must support alarm synchronization.
3. The proposed NMS must support alarm display.
4. The proposed NMS must support alarm statistics.
5. The proposed NMS must support acknowledgement of alarm.
6. The proposed NMS must support alarm comment.
7. The proposed NMS must support alarm query.
8. The proposed NMS must support remote email notification of alarm.
9. The proposed NMS must support store the alarm as the TXT, HTML, CSV format.
10. The proposed NMS must support voice and light notification of alarm box.
8.3.11.5 Diagnose
1. The proposed NMS must support self-check and remote restart of the terminal.
2. The proposed NMS must support manually linkage diagnose of terminal.
8.3.11.6 Terminal Form
1. The proposed NMS must support terminal report display. The form shall include IMSI, IMEI, version,
terminal type and user number information.
8.3.12 Log Management
1. The proposed NMS must support operation and security information log of network equipment.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 45 of 47
2. The proposed NMS must support remote log collection of network and terminal equipment.
8.3.13 Operation Management
1. The proposed NMS must support subscriber management, MDS subscriber data export, user status
query, public parameter configuration query, call record export, and MDS data export.
2. The proposed NMS must support the addition, modification, deletion, and searching of trunking group
information.
3. The proposed NMS must support the addition, deletion of authentication information.
4. The proposed NMS must support management of PS data user.
5. The proposed NMS must support call number segment management function.
8.4 Reliability
8.4.1 Data Security
8.4.1.1 Backup Mechanism
1. The proposed NMS must support automatic and manual routine backup.
2. The proposed NMS must support external storage of backup data.
8.4.1.2 Recovery Mechanism
The proposed NMS must support data restoration based on the latest backup in case of system collapse.
8.4.2 Operation Security
8.4.2.1 Access Control
The proposed NMS must support access limitation control for the user at the provided time.
8.4.2.2 User Monitoring
The proposed NMS must support monitoring of all user operations and generates maintenance reports
automatically.
8.4.2.3 Operation Confirmation
The proposed NMS must support the validation mechanism for important and global configuration.
8.4.3 Software Reliability
The proposed NMS software must support the automatic self inspection mechanism.
8.4.4 Hardware Reliability
High server availability: full redundancy is required, including power supplies, RAID disk, and data
replication.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 46 of 47
9 Gateways
9.1 Telephony Gateway
1. The telephony gateway needs to provide the cross communication between the digital trunking radio
subscribers and an existing telephony system.
2. The telephony gateway needs to provide required interfaces for existing and legacy telephony systems.
3. The telephony gateway needs to provide required interfaces for existing wireless and wired telephony systems, namely, the PSTN, GSM, and CDMA networks.
4. The telephony gateway needs to provide feature transparency between two networks.
5. The telephony gateway needs to be integrated into the switch itself.
9.2 Trunking Gateway
1. The telephony gateway needs to provide trunking communications between the digital trunking radio subscribers and an existing trunking system.
2. The telephony gateway needs to provide required interfaces for existing wireless trunking systems including the analog trunking, TETRA and so on.
9.3 Video Gateway
1. The video gateway can connect various video signals to the trunking radio system. It turns the closed
video monitoring network into a subsystem of a dispatching system and turns the original monitoring-oriented working way to a dispatching-oriented working mechanism.
2. The video gateway must be able to connect Telepresence and Videoconferencing Product.
3. The video gateway must be able to connect Intelligent Video Surveillance.
9.4 Data Gateway
The data gateway functions as an interface on the IP network.
10 Second Development Interfaces
10.1 SIP/SDK Interface
1. The proposed system shall support SIP interface for 2nd
development of gateway to other systems.
2. The proposed system shall support SDK interface for 2nd
development of dispatching console or
gateway to other systems.
3. The proposed system supports heart beat detection mechanism.
4. The proposed interface shall based on SIP, SDP, TCP/UDP/IP, and RTP/RCTP.
5. The proposed system is in compliance with RFC 2327, 2617, 2976, 3261, 3262, 3263, 3264, 3265,
3266, 3310, 3311, 3420, 3428, 3489, 3515, 3581, 3605, 3608, 3856, 3891, 3892, 3903, 3966, 3994, 4028, 4320, 4321, 4480, 4488, 4863, 4169, 4317, 4566, and 5057.
6. The proposed system supports PCM voice based on G.711 A-Law/U-Law.
eLTE Tendor Document for Broadband Trunked Radio System INTERNAL
2013-10-24 Huawei confidential. No spreading without permission. Page 47 of 47
11 Annex
12 Appendix
LTE: Long Term Evolution
EPC: evolved packet core
MS: mobile station
DC: dispatching console
CN: core network
AMR: Adaptive Multi-Rate
E2E: End to End