43
America Movíl LTE Technical RFI

America Movíl LTE Technical RFI_PA1

  • Upload
    durba

  • View
    7

  • Download
    0

Embed Size (px)

DESCRIPTION

very good

Citation preview

America Movil LTE Technical RFI

DOCPROPERTY "DocNo" \* MERGEFORMAT Rev A

America Movl LTE Technical RFI

Contents41LTE References and Background

52Deployment strategies

63LTE Architecture and Roadmap

74LTE Radio Functionality

74.1Capacity and Licensing

84.2Mobility

124.3QoS

134.4Scheduler

134.5Voice Support

144.6Interference Coordination (ICIC)

155eNodeB

155.1General

175.2Performance and Air Interface

195.3Installation and Antenna Configuration

215.4Reliability

225.5Power Supply

235.6Synchronization

235.7Environmental Conditions

266eUTRAN Transport

266.1General

276.2eNodeB (eNB)

297Self Optimizing Network (SON)

308O&M

308.1General

308.2Fault Management

308.3Configuration Management

318.4Performance Management

339CORE

339.1General

339.2Hardware Requirements: PDN-GW, S-GW, MME

349.3Software Requirements: PDN-GW, S-GW, MME

349.4Capacity & Performance: PDN-GW, S-GW, MME

General

1 LTE References and Background1.1.1 Please provide a description of your background and involvement in LTE and LTE Advanced.

1.1.2 Please provide a description of your involvement in the 3GPP standardization process related to LTE and LTE Advanced. 1.1.3 Please provide a description of your involvement (if any) in the LTE/SAE Trial Initiative (LSTI). 1.1.4 Give a list of your LTE commercial customer wins globally. For each, include scope of project, spectrum band (FDD/TDD/Hybrid), expected launch timelines, infrastructure to be deployed (RAN, EPC, OSS etc) and device partnerships (if any). Also state whether these are for Tier 1, Tier 2 or Tier 3 operators.1.1.5 Please list completed and ongoing LTE trials (including spectrum band, timelines, scope, key achievements), and any additional planned trials (spectrum band, timeline, scope, goals), provide details of status of IOT efforts in support of these trials?1.1.6 Please state the Maximum Throughputs (UL and DL) achievable with different spectrum bandwidths; include all assumptions, inputs and equipment configurations used for these values.

1.1.7 Indicate what throughputs values (UL and DL) have been achieved in field trials and the trial configuration/equipment used.

1.1.8 Please state the difference in theoretical Maximum Throughputs (UL and DL) achievable with HSPA+ vs LTE for both 5 MHz and 10 MHz bandwidths, include all assumptions, inputs and equipment configurations used to obtain these values.2 Deployment strategies

There are uncertainties with regard to the future market trends and demands which may drive our decisions around LTE/SAE. This section provides the opportunity for you to describe your beliefs about the future market and help shape our strategic thinking and deployment plans for LTE/SAE.

2.1.1 Do you believe LTE/SAE is an enabler for new revenue streams as well as cost reductions going forward?

2.1.2 Please list the main reasons (if any) why America Mvil should seek to deploy LTE/SAE, please provide justification and rationale for these reasons.2.1.3 When do you consider the optimum time for LTE/SAE deployment in our market and why?2.1.4 What spectrum should America Mvil use for their future LTE deployment taking into consideration the current regional spectrum situation, economies of scale, mature ecosystem and ongoing LTE deployments/announcements worldwide?2.1.5 What do you consider are the major threats / potential disruptions to significant LTE/SAE deployment becoming a reality? These may be associated with technological, economic, regulatory or ecosystem developments.3 LTE Architecture and Roadmap3.1.1 Please describe your current roadmap for LTE/SAE system (HW and SW) and the related dependencies and timelines (proposed releases). 3.1.2 Describe evolution from LTE to LTE Advanced. Provide your roadmap to LTE Advanced. Specifically identify existing network elements which are re-used, enhanced for LTE Advanced operation, or require replacement. Also identify and describe any modifications required at the cell site (SW and HW).3.1.3 Please provide a network diagram and associated description reflecting the inter-working between:

LTE/SAE and earlier 3GPP releases.3.1.4 Please provide IOT information and/or trial results on LTE/SAE Inter-RAT testing with GSM and UMTS.

3.1.5 Please indicate whether your company has any device IoT and IoDT plans and if yes provide detailed information including vendors.3.1.6 Please confirm that all your products are future-proof, in the sense that future-proof means that the HW platform is both flexible enough and equipped with sufficient processing resources to support future releases of standardized features without the need to swap HW.3.1.7 Provide details of any proprietary interfaces your solution supports and any plans to move these to standard interfaces. 3.1.8 Please describe your solution for general measurements of the service quality and user experience, and the tracing of mobility and session behavior of specified users and terminals.

3.1.9 Please describe your security solution for LTE/SAE system.3.1.10 Please describe your emergency and legal intercept solution for LTE/SAE system.4 LTE Radio Functionality4.1 Capacity and Licensing4.1.1 Please describe how the resources (carriers, connected users, baseband, and cell throughput) are configured for network capacity (HW or SW licenses)?4.1.2 Please describe how network capacity may be expanded.

4.1.3 Please describe how your network elements/products are future proof.

4.1.4 Please confirm that your system is scalable and flexible and specify any limitations.

4.1.5 Please explain your license structure in relation to HW and Radio features.

4.1.6 Which capacity elements are under SW license, and what granularity is applied for each of them?4.1.7 Please explain how Baseband capacity may be expanded at the eNodeB (for example: SW license key).4.1.8 Please state maximum number of attached mobiles, both active and idle, supported for each carrier bandwidth.4.1.9 Please explain any pooling capabilities/advantages of capacity elements offered by your solution.4.1.10 Please describe your Baseband Unit capacity structure.4.1.11 Please explain your Baseband Unit capacity upgrade policy (SW license key?).4.2 Mobility

4.2.1 The system shall support RAT selection priority for LTE, UMTS, GSM and CDMA-eHRPD broadcast in system information. Please provide roadmap details.

4.2.2 IRAT re-selection: The system shall support broadcast speed dependent reselection parameters. Please provide roadmap details.

4.2.3 The system shall support Intra and Inter eNodeB handover with neighbor cell-specific handover parameters

4.2.4 The system shall support neighbor cell-specific blacklists for Inter eNode B handover.

4.2.5 The system shall support IRAT handover for UE with multiple EPS bearers by using handover parameters per QCI. The handover shall be done when the first EPS bearer triggers.

4.2.6 For intra-frequency handover procedures, the system shall support handover to best cell based on DL Reference Symbol Received Power (RSRP) measurements and thresholds.

4.2.7 For intra-frequency handover procedures, the system shall support handover to best cell based on DL Reference Symbol Received Quality (RSRQ) measurements and thresholds.

4.2.8 The system shall support Non Gap-assisted handover measurements for intra-frequency handover.

4.2.9 The system shall support blind handover as inter-frequency handover.

4.2.10 The system shall support gap-assisted handover measurements for inter-frequency handover.

4.2.11 The system shall support configurable gap patterns for gap-assisted handovers.

4.2.12 For inter-frequency handover, the system shall support bad coverage method based on RSRP and RSRQ with below triggers:

Based on bad coverage

Based on load

Based on service

Based on subscription (SPID information from MME)

Please specify roadmap details.

4.2.13 Please provide roadmap details about support for Contention-free RACH for intra-LTE handover.

4.2.14 The system shall support Intra eNB handover.

4.2.15 The system shall support Inter eNB handover: over S1 interface (no X2 interface between serving and target eNB)

4.2.16 The system shall support Inter eNB handover: over X2 interface.

4.2.17 The system shall support forward historical UE information from serving to target eNB over X2 or S1 during handover.

4.2.18 The system shall support connection re-establishment procedure (Source eNB maintain context; ready for UE return; until UE confirmed on target cell).

4.2.19 The system shall support following types of Intra eNB handover:

intra frequency,

inter frequency: same band

inter frequency: different band

Please specify roadmap details.

4.2.20 The system shall support following types of Inter eNB handover:

intra frequency

inter frequency: same band

inter frequency: different band

intra MME and SGW

inter MME

inter MME and SGW

inter SGW

Please specify roadmap details.

4.2.21 The system shall support cell reselection based on:

broadcast priority indication

broadcast cell-specific reselection parameters

broadcast cell-specific blacklists

Access class baring parameters

Please provide roadmap details.

4.2.22 The system shall support Inter frequency reselection priority based on:

Broadcast of system information

per UE (priority signaling to UE at RRC release with validity time specified)

Please provide roadmap details.

4.2.23 The system shall support Inter PLMN reselection.

4.2.24 The system shall support GAP-assisted or Configurable GAP patterns for IRAT handover measurements. Please state roadmap details.

4.2.25 In regards to configurable IRAT measurement and handover priority per QCI class, the system shall support the below scenarios:

Measure on preferred RAT if the UE supports it, otherwise select lower prioritized RAT until UE supports it.

4.2.26 Please provide details based on your roadmap about the support of blind handover for IRAT using pre-configured neighbors.

4.2.27 Blind handover without measurements should be supported.

4.2.28 Please detail your roadmap regarding blind IRAT handover to different RATs.

4.2.29 Please state your support for the below LTE to GSM handover:

PS (non-voice)

VOIP to CS voice (VCC)

4.2.30 Please detail your roadmap about the capabilities to secure efficient configuration and consistency of IRAT parameters

4.3 QoS

4.3.1 Please describe the end to end QoS solution, which types of bearers are supported and how the QoS is controlled and managed in your LTE/SAE solution.

4.3.2 How is the quality of low priority broadband services supported in the presence of voice services?4.3.3 The eUTRAN shall support that the QoS requirements signaled to the eNodeB over the S1 interface are used to determine how the bearers should be handled in a resource limited situation. 4.3.4 Which QoS parameters are supported over the S1 interface?4.3.5 The behavior of each QoS Class shall be controllable by the operator.

4.3.6 The system shall provide the ability for a user to have several simultaneous data bearers with different QoS. Please state number of simultaneous data bearers.

4.3.7 The system shall be capable of differentiating data flows towards same user.

4.3.8 The system shall support differentiation of subscribers based on maximum bit rate. Please provide roadmap details.

4.3.9 Describe how Access and Retention Priority (ARP) is used to handle subscriber priority.

4.4 Scheduler

4.4.1 The system shall support QoS based scheduler. Please provide roadmap details.

4.4.2 The eUTRAN shall support a flexible scheduler scheme that shall provide the flexibility of trading system capacity with fairness among users on cell level. The scheduler shall support, but not be limited to, below functionality:

Max CQI,

Proportional Fair - low fairness

Proportional Fair - medium fairness

Proportional Fair - high fairness

Equal bit rate

4.4.3 The eUTRAN shall support scheduling of users in the frequency domain. By using measurement from the UE the scheduler shall be able to allocate the resourcesto usersthat have the most favorable conditions.4.5 Voice Support

4.5.1 Please describe your current or planned voice solutions for LTE/SAE and its inter-working with 2G/3G CS voice, please state if these solutions are proprietary or standard, for example: SR VCC

CS Fall back

VoLGA

Call flows for above items

4.5.2 The eUTRAN shall support IMS/MMTel as defined in 3GPP.The MMTel shall be supported with, but not be limited to, below functionality:

Optimized VoIP bearer

SRVCC

Support for emergency call with location information4.5.3 The eUTRAN shall support CS fallback as defined in 3GPP.

4.5.4 The Vendors equipment shall provide adequate support of Voice over IP services. If this support is not present in the current release, the Bidder shall include a roadmap for the availability, stating the eventual HW needed.

4.6 Interference Coordination (ICIC)4.6.1 The vendor shall state and describe the interference coordination features/algorithms in UL. Clearly indicate when these features will be available (currently commercially available or future SW release)4.6.2 The vendor shall state and describe the interference coordination features/ algorithms in DL. Clearly indicate when these features will be available (currently commercially available or future SW release)4.6.3 From what release will you support Interference Coordination via the X1 interface?4.6.4 The system shall support Interference Rejection Combining (UL and DL). Please provide roadmap details.

4.6.5 What other Interference Coordination or Rejection mechanisms are implemented or will be available (state in which release)?5 eNodeB5.1 General

5.1.1 Provide a full roadmap for all your commercially available radio products, including all eNodeB types and associated sub-unit products (i.e. RRU, BBU etc), frequency bands and bandwidth, antennas, tower mounted amplifiers, external power/battery backup solutions, RET products etc.5.1.2 Provide an overview description of the eNode B portfolio, including current/future commercial deployments.5.1.3 The eNodeBs shall support combinations of GSM, WCDMA, and/or LTE in the same cabinet. State your options for eNodeBs in your portfolio.

5.1.4 Please describe eNodeB HW expansion paths 5.1.5 Please describe the eNodeB SW capacity upgrade possibilities5.1.6 What is the Upgrade path from existing GSM/UMTS radio equipment to LTE?

5.1.7 Please state the functionality and the SW release, for a full working MSR radio module.

The supplier shall state the MCPA IBW (Instantaneous Bandwidth, i.e. how much BW does the RU support) What IBW is supported when running mixed mode configuration GSM+LTE or WCDMA+LTE? The supplier shall state the MCPA nominal output power ifit is used for onecarrier configuration.

The supplier shall state the MCPA aging marginal taken into the consideration in the design

The supplier shall state the MCPAFilter loss compensationmarginal taken into the consideration in the design

The supplier shall state the MCPATemperature driftmarginal taken into the consideration in the design

The supplier shall state the MCPA power saturation taken into the consideration in the design

The supplier shall state the MCPA power accuracy

The supplier shall state if the MCPA has a power back off if 64 QAM modulation is used

5.1.8 Please state which is the maximum radio configuration that can be done within the same cabinet in case of Multi-standard e.g. UMTS/LTE.5.1.9 Please state yourHW life cycle plan and state valid proof points on how your legacy equipment has been capable or can bemodernized to meet future enhancements?

5.2 Performance and Air Interface5.2.1 State the total TX power constantly available at full load at the top of the cabinet (or at the RF connector in case of RRH).

5.2.2 State the RX sensitivity and Noise Figure of the different eNodeBs at the top of the cabinet (or for distributed eNodeBs at the RF connector) for 5, 10, 15 and 20MHz FDD bandwidth

5.2.3 Is any RX Sensitivity degradation expected when running mixed mode configuration GSM+LTE or WCDMA+LTE?5.2.4 Is any RX Sensitivity degradation expected when running multi standard site with GSMand WCDMA or LTE co-located?5.2.5 State the power back-off in dB required for 64-QAM in DL under full load. Also state the total TX power constantly available under this condition.

5.2.6 Please state operating spectrum options, including 700, 850, 1900, 1700/2100 and 2600 MHz.

5.2.7 Please state carrier bandwidth options including 1.4, 3, 5, 10, 15 and 20 MHz5.2.8 Describe SISO and MIMO (STTD, S-CPICH, etc) options supported.

5.2.9 Please state the Peak data rates for uplink and downlink for each carrier bandwidth and different MIMO configuration supported.

5.2.10 Support for the following downlink modulations:

QPSK

16QAM

64QAM

5.2.11 Support for the following uplink modulations: QPSK

16QAM

64QAM

5.2.12 Do you support for Extended Cyclic Prefix (512 Ts), if so in what release?5.2.13 How many carriers can be supported, how many sectors/cells and whether carrier resources can be shared across sectors?

5.2.14 What MIMO (UL and DL) and Beam forming (UL and DL) schemes will be supported, including space-time/frequency transmit diversity and multi stream schemes

5.2.15 What is the maximum TX power? Per port etc

5.2.16 Describe the maximum number of supported users, by the HW, in state RRC Connected (LTE_active) per eNodeB.

5.2.17 Maximum simultaneous idle users, active users and active + idle users supported per eNodeB configuration

5.2.18 Max cell range supported and any features that limit the range and plans to extend the range

5.2.19 Describe any offered capability allowing an eNodeB to autonomously discover, identify or measure any neighboring nodes?

5.2.20 The vendor shall describe how zero downtime can be achieved when replacing or adding radio units in their macro eNodeBs.

5.2.21 The vendor shall describe how zero downtime can be achieved when replacing or adding remote radio heads in their distributed eNodeBs.

5.2.22 The eNodeB shall be able to constantly operate in conditions up to 40 degrees Celsius (Indoor) and 45 degrees Celsius (Outdoor) at full capacity and without impairing its operation.

5.2.23 The vendors eNodeBs shall comply with 3GPP TS25.113.

5.2.24 The Radio Units and Remote Radio Heads (as applicable) shall support VSWR measurement / monitoring.

5.2.25 The Radio Units and Remote Radio Heads (as applicable) shall support faulty antenna determination together with the O&M system.

5.2.26 eNB support for MME in pool with S1 FLEX with up to X S1 connections

5.2.27 eNB support for SGW in pool with S1 FLEX with up to X S1 connections

5.2.28 Automatic MME and S1 selection, configuration and load balancing

5.2.29 Supported eNodeB features for location based services

5.2.30 Provide performance targets on transition times for fast transition from LTE-Idle to LTE-Active.

5.2.31 Provide details of the Radio Admission Control and Congestion Control procedure implemented.5.3 Installation and Antenna Configuration

5.3.1 The eNodeB shall support 3GPP compliant TMAs by complying to 3GPP specification TS25.466.

5.3.2 The eNodeB shall support 3GPP compliant RET antennas by complying with 3GPP interface specifications TS25.460, TS25.461, TS25.462, and TS25.466.5.3.3 For each hardware component, what inter-working will be possible between new LTE equipment and existing W-CDMA/GSM equipment?

Is it possible to share low noise tower mounted/mast-head amplifiers (TMAs)?

Is it possible to share power components?

Is it possible to share RF feeders?

Is it possible to share physical transport interfaces? Is it possible to share other items?5.3.4 Provide details for the following eNodeB characteristics, noting variations across various models in the eNodeB portfolio.

Height

Width

Depth

Free access space required for different cabinet scenarios Weight

Total weight, fully configured

Per cabinet

For each range of battery backup capacity offered For main-remote state the weight of its individual main components State the volume of your Remote Radio Head Backhaul connectivity options

Radio cabinet mounting and cable entry options and compatibility with legacy equipment Different mounting alternatives available for the eNodeB types. All macro eNodeB shall allow back-to-back and side-to-side installation.5.4 Reliability

5.4.1 List the MTBF for each element at the lowest field-replaceable module level.

5.4.2 List recommended maintenance schedule, servicing duration, and any service outage impacts.

5.4.3 Identify redundant elements and type such as 1+1. N+1, and describe resource pooling for each element. If service interruption occurs during failover, provide the interruption time.5.5 Power Supply

5.5.1 Please describe the power supply inputs for each eNodeB type.

5.5.2 Please describe the power efficiency of for the eNodeB.

5.5.3 Please state the power consumption for different eNodeB types under different RF load conditions including both typical and maximum values. Please indicate conditions assumed for typical consumption, including transmit power levels, carrier bandwidths, operating spectrum, ambient temperature, or other factors with significant impact on power consumption.

5.5.4 The Outdoor eNode B shall include a battery backup within the cabinet.

5.5.5 Please describe the power backup solution for outdoor eNodeB types.

5.5.6 Please confirm that the maximum radio configuration (configuration of radio and baseband units) in a RBS cabinet does not depend on the power supply type (e.g. if is 24V DC or -48V DC) or battery configuration (half or full equipped) in the same RBS cabinet.

5.5.7 The O&M system shall in a Multi Standard Radio (MSR) ensure that the Power System is used in the most cost-efficient and environmentally friendly way.5.6 Synchronization

5.6.1 Detail your eNodeB synchronization concept in an all-IP network.

5.6.2 Synchronization using GPS or Galileo (or both) shall be supported.

5.6.3 The system shall support the NTP synchronization over IP in the eNodeB

5.6.4 The system shall support synchronization via external interface in the eNodeB

5.6.5 If multiple methods for synchronization are supported, comment on which is recommended and why.

5.6.6 The vendor shall state and describe the type of synchronization mechanisms supported by the eNodeB. 5.6.7 Specify holdover time provided after loss of external timing signal.5.7 Environmental Conditions

5.7.1 Provide details for the following eNodeB environmental characteristics, noting variations (if any) across various models in the eNodeB portfolio

Environmental management system employed i.e. air conditioning, free air, and any related options

Regulatory: Any eNode B configuration shall be compliant with the latest version available of the Release 8 of the 3GPP TS 36.104 and 3GPP TS 36.113 (EMC) for the relevant sections of the Product Configuration and supported Features and have gone through conformance Testing according to 3GPP TS 36.141 by June 30, 2009

Minimum and maximum temperatures

Relative humidity

List environmental protection standards compliance such as NEMA or IP (Ingress Protection) by rating level. For example IP55 for limited dust and water protection.

Lightning/surge protection ratings.

Number of alarm inputs available for customer application, including electrical characteristics.

5.7.2 The eNode B shall conform to the environmental standards listed below:

5.7.2.1 eNode B Indoor version

a) Storage Requirements:

ETS class 1.2 Weather Protected, Not Temperature Controlled Storage Locations in ETS 300 019-1-1

b) Product safety:

LVD 73/23/EEC and 93/68/EEC

EN 60950 / IEC 950

EN 60215 / IEC 215

EN 60952 / IEC 529

Code of Federal Regulation 21 CFR 1040.10 and 1040.11

ANSI/UL 60 950-1 / CSA C22.2 No.60950-1-03

c) The eNode B shall conform to the following standards on earthquake protection:

IEC/EN 60 068-2-57

d) The Indoor Node B shall comply with ETS class 2.3 Public Transportation in ETS 300 019-1-2.

e) The Indoor eNode B shall comply with the requirements for normal operation in the climate conditions of class 3.1 of ETS 300 019-1-3 according to IEC/EN 721-3-3.

5.7.2.1.1 Outdoor version

a) Storage Requirements

ETS class 1.2 Weather Protected, Not Temperature Controlled Storage Locations in ETS 300 019-1-1

b) The Outdoor eNode B shall comply with ETS class 2.3 Public Transportation in ETS 300 019-1-2.

c) The Outdoor eNode B shall be compliant with ETS class 4.1 (extended to 45 C). Non Weather Protected Locations as follows: ETS 300 019-1-4: -33C to +45 C

d) The eNode B shall conform to the following standards on product safety:

LVD 73/23/EEC plus 93/68/EEC

EN 60950 / IEC 950

EN 60215 / IEC 215

EN 60 529 / IEC 529

Code of Federal Regulation 21 CFR 1040.10 and 1040.11

ANSI/UL 60 950-1 / CSA C22.2 No.60950-1-03

ANSI/UL 60950-22 / CSA C22.2 No. 60950-22

e) The eNode B shall conform to the following standards on earthquake protection:

IEC/EN 60 068-2-57

f) Ingression, IP55 requirements according to the standard IEC/EN 60 529g) Acoustic Noise: Measured according to ISO 7779 and ETS 300 753 with max 54 dB (A)

6 eUTRAN Transport

6.1 General6.1.1 Please describe your roadmap for eUTRAN Transport feature/functions

6.1.2 Provide an overview description of the proposed solutions backhaul and transport capabilities across the eNode B portfolio.

6.1.3 Describe the transport solution for an eNodeB co-sited with GSM and WCDMA nodes.6.1.4 What physical interfaces for X1/S2 and O&M does the eNodeB provide?

6.1.5 The system shall support Native Ethernet in the eNodeB.

6.1.6 The system shall support IPv4 and be hardware prepared for IPv6 for all traffic interfaces in the eNodeB.

6.1.7 From which release will the system support IPv6 on IP (X1, S2) interface?

6.1.8 The system shall support Gigabit Ethernet optical and/or electrical port in the eNodeB.

6.1.9 Describe the number and type of local craftsperson communications ports (e.g. Optical, Ethernet, T1/E1).

6.1.10 Describe the number and type of communications ports available for customer use (e.g. Optical, Ethernet, T1/E1).

6.2 eNodeB (eNB)6.2.1 The system shall support traffic separation and Quality of Service (QoS) on the IP respective Ethernet layer for all eNB traffic in the eNodeB; this shall be described in detail.

6.2.2 The system shall support IPsec and IKEv2 for the traffic according to the 3GPP specification in the eNodeB.

6.2.3 Describe support for Call Admission control to manage backhaul limited traffic conditions.

6.2.4 Describe the standards supported for the eNodeB transport solution.

6.2.5 Describe the requirements on the backhaul from an X2 interface connectivity and characteristics perspective.6.2.6 Describe the synchronization solutions supported by the eNB for LTE FDD.

6.2.7 The O&M system shall monitor the real-time IP traffic measurements.

6.2.8 Specify maximum number of interfaces an eNB can support?

6.2.9 Specify the commercial solution for traffic aggregation from eNBs before it terminates on SGW/PGW?

6.2.10 Describe the QoS handling in the eNodeB.6.2.11 How does the traffic classification and marking and QoS enforcement work on eNB S1 and X2 interfaces? Can this mapping be configurable via OA&M?

6.2.12 Do the eNodeB S1 and X2 scheduler support different QoS categories as specified in 3GPP standards? And support queuing and forwarding using priority information?

6.2.13 Does the eNodeB S1 and X2 interfaces support traffic shaping taking into account end-to-end delay budget?

6.2.14 Specify maximum and minimum downstream/upstream peak bandwidth support on eNB S1 and X2 interfaces?

6.2.15 Does eNB support IP header compression and payload compression in order to improve bandwidth efficiency? (Do not mean RoHC for VoIP header)

6.2.16 Does your eNB plan to perform admission control based on current availability and performance of transport backhaul resources?

6.2.17 Specify redundancy mechanisms available on S1/X2 link failures

6.2.18 Can your eNB act as the transport consolidation/sharing platform for eNB from another vendor? Or for networks consolidation, do you recommend the use of a cell site?

6.2.19 Specify maximum number of GigE, optical, electrical ports available on S1/X2 links of the eNodeB?

7 Self Optimizing Network (SON)

7.1.1 Please describe your roadmap for Self Optimizing Network (SON) feature/functions. 7.1.2 Please indicate support for Automatic LTE Neighbor Relation Management support as specified by 3GPP; also indicate support for Black and White lists.

7.1.3 Please indicate support for Handover (HO) Parameter Optimization

7.1.4 Please indicate support for Mobility Load Balancing

7.1.5 Please indicate support for Self Establishment of new eNodeBs

7.1.6 Please indicate support for Automated download of site specific information from OSS

7.1.7 Please indicate support for Automated download of correct software

7.1.8 Please indicate support for Automatic PCI configuration

7.1.9 Please indicate support for Inter-Cell Interference Control (ICIC) Optimization

7.1.10 Please indicate support for RACH Optimization7.1.11 Please indicate support for Capacity and Coverage Optimization

7.1.12 Please indicate support for Cell Outage Compensation, for example:

Automatic neighbor relation function: event-based tuning due to neighboring cell outage (loss of X2 heartbeat) Automatic neighbor relation function: notify X2 neighbors of upcoming outage so they may proactively reconfigure neighbors.8 O&M 8.1 General

8.1.1 The same O&M system shall concurrently support the various radio technologies when running Multi Standard Radio, MSR.

8.1.2 The same O&M system shall concurrently support a mixed single- and multi-band radio environment with SCPA, MCPA, and MSR for backward compatibility.

8.2 Fault Management

8.2.1 Please provide detailed information on the configuration management aspects of the O&M system for your LTE/SAE

8.2.2 Please provide full details of the support for self-healing of the LTE/SAE network (including interfaces). Provide full details of the distribution of functions between the O&M solution and the LTE/SAE nodes to support this, and the functional interaction between the LTE/SAE nodes and O&M solution.

8.2.3 Please provide a full description of the basic LTE/SAE network fault management capability provided by the O&M solution.

8.2.4 Please provide information as to how alarms can be managed (e.g. priorities, storage, graphical management, filtering, correlation, and customization).

8.3 Configuration Management8.3.1 Please indicate whether self configuration is supported and if yes provide detailed information on it.

8.3.2 Please provide details of the support for self organization of the LTE/SAE network. Provide details of the distribution of functions between the O&M solution and the LTE/SAE nodes to support this, and the functional interaction between the LTE/SAE nodes and O&M solution during the configuration process. Include a description of how the O&M users are notified/advised of changes by the self organizing function.

8.3.3 Please provide details of Software Management capability provided for the LTE/SAE network nodes by the O&M solution. Provide a description of support for automatic SW update.

8.3.4 Please provide a description of the licensing and feature management capability provided in the O&M solution for the LTE/SAE nodes.

8.3.5 Please provide a description of the Hardware Management capability provided by the O&M solution.

8.3.6 Please provide a description of the Inventory Management (Auto Inventory) capability provided by the O&M solution.

8.3.7 Please provides details on the capability for LTE/SAE IP network configuration

8.4 Performance Management

8.4.1 Please provide detailed information on the performance managements aspects of your O&M system

8.4.2 Describe necessary measurements required to support the self optimization function.

8.4.3 Please provide details of the support for Cell level Tracing (real time and non-real time).

8.4.4 Please provide details of the support for subscriber level tracing (real time and non-real time).

8.4.5 Please provide details of the support for threshold based PM Alarming and notifications.

8.4.6 PM acquisition functions

The vendor shall describe the features available for collection of PM Counters and Events, such as:

PM Counters statistics

Cell trace

UE trace9 CORE

This section covers the Evolved Packet CORE network as described by 3GPP specification and covers the following components: PDN Gateway (PDN-GW), Serving Gateway (S-GW), and Mobility Management Entity (MME)9.1 General

9.1.1 The EPC network entities (MME, Serving GW, and PDN-GW) shall comply with specifications defined in 3GPP Release 8.

9.1.2 Describe the mapping of the logical LTE network elements to the proposed hardware platform.

9.2 Hardware Requirements: PDN-GW, S-GW, MME

For each product within your LTE EPC solution: PDN-GW, S-GW, and MME, please provide the following information regarding hardware requirements

9.2.1 Provide hardware architecture diagrams.

9.2.2 Provide hardware descriptions of the major components. Include descriptions of physical dimensions, maximum weight, and layout.

9.2.3 Describe the interface modules supported.

9.2.4 Describe the supported connectivity interfaces to other network elements

9.2.5 Are all hardware elements redundant, such that the failure of a single element does not impact the operational performance of the equipment?9.2.6 Provide the following equipment characteristics:

Height

Width

Depth

Free access space required (for door clearances)

Weight

Total weight, fully configured

Per cabinet

For each range of battery backup capacity offered

Electric power facilities required. Descriptions shall include whether AC or DC, allowable voltage range, allowable frequency range. For AC, power provide the Power Factor (PF).

Power consumption including both typical and maximum.

Provide cabinets modularity (e.g. number of blades, growth of shelf etc)

9.3 Software Requirements: PDN-GW, S-GW, MME

For each product within your LTE EPC solution: PDN-GW, S-GW, and MME, please provide the following information regarding software requirements.

9.3.1 Describe the software platform required by the product.

9.3.2 Describe the software features/capabilities available at deployment.

9.3.3 Describe the software features/capabilities and timeline of future releases.

9.3.4 The product shall support software upgrades, patches and backup without service interruption.

9.4 Capacity & Performance: PDN-GW, S-GW, MME

For each product within your LTE EPC solution: PDN-GW, S-GW, and MME, please provide the following information regarding capacity and performance requirements.

9.4.1 Specify the products supported capacity as listed below:

Simultaneously attached users

Maximum number of default bearers

Maximum number of dedicated bearers

Throughput: Packets per Second (PPS)

Transactions per Second (TPS)

Concurrent Traffic Flows

Provide units active Capacity, e.g. max active customers, eNBs, signaling transactions per hour, S1 interface pages/hours, maximum number of S1 interface SCTP connections, maximum number of Tracking Areas per MME, etc.

Provide units virtual capacity, e.g. maximum dormant customers, eNB, etc.

Provide units mix capacity, e.g. maximum active and dormant customers and eNB

Provide units Software redundancy capabilities

Provide units Hardware redundancy capabilities

Provide units interface connectivity types, e.g. Gig E, Ethernet, etc.

Provide number of IP addresses assigned to the cabinet and details of purpose of each address

Provide units Session redundancy capability

Provide type of redundancy provided by the unit, e.g. local vs. geographical redundancy

9.4.2 Provide the MTBF / availability numbers for all applicable component, module, or equipment.

9.4.3 Describe the products session redundancy capability. Are sessions preserved?