TIP OpenRAN OpenRAN Technical Requirements v0.1 October … · 2021. 4. 15. · OpenRAN –...

OpenRAN

Technical Requirements Document

OpenRAN Project Group

Version 0.1

July 14, 2020

OpenRAN – Technical Requirements Document v0.1

TIP CONFIDENTIAL This document contains TIP Confidential Information as defined in Section 1.3 of the TIP Bylaws. Subject to Sections 16.1 and 16.2 of the TIP Bylaws, use and disclosure of the document and its contents are strictly prohibited. Copyright © 2020 Telecom Infra Project, Inc. All rights reserved. The Telecom Infra Project logo is a trademark of Telecom Infra Project, Inc. (the “Project”) in the United States or other countries and is registered in one or more countries. Removal of any of the notices or disclaimers contained in this document is strictly prohibited. The publication of this document is for informational purposes only. THIS DOCUMENT IS PROVIDED “AS IS,” AND WITHOUT ANY WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY EXPRESS OR IMPLIED WARRANTY OF NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. UNDER NO CIRCUMSTANCES WILL THE PROJECT BE LIABLE TO ANY PARTY UNDER ANY CONTRACT, STRICT LIABILITY, NEGLIGENCE OR OTHER LEGAL OR EQUITABLE THEORY, FOR ANY INCIDENTAL INDIRECT, SPECIAL, EXEMPLARY, PUNITIVE, OR CONSEQUENTIAL DAMAGES OR FOR ANY COMMERCIAL OR ECONOMIC LOSSES, WITHOUT LIMITATION, INCLUDING AS A RESULT OF PRODUCT LIABILITY CLAIMS, LOST PROFITS, SAVINGS OR REVENUES OF ANY KIND IN CONNECTION WITH THE SUBJECT MATTER OR USE OF THIS DOCUMENT.


Authors:


Contributors:


Change Tracking

Date Revision Author(s) Comment

8/31/2020 V 1 Chris Bourgea Changed all ‘shall’ to ‘must’


Table of Contents

1 Introduction 131.1 Why OpenRAN? 131.2 Document Scope 141.3 Document Structure 14

2 Requirements 162.1 General 162.2 Platform 162.3 Radio Functionality 182.4 Fronthaul 182.5 2G Requirements 19

2.5.1 Energy Efficiency 192.5.2 2G – M2M 202.5.3 2G – MCPA Algorithms 212.5.4 2G – Mobility 222.5.5 2G – Security 232.5.6 2G – Refarming Enabler 232.5.7 2G – Sharing 242.5.8 2G – Smartphones 252.5.9 2G – Total Comms 252.5.10 2G – Transmission 26

2.6 3G Requirements 282.6.1 3G – Capacity 282.6.2 3G – Energy 372.6.3 3G – Mobility 392.6.4 3G – Quality of Service 412.6.5 3G – Sharing 422.6.6 3G – Smartphones 432.6.7 3G – Speed 442.6.8 3G – Total Comms 492.6.9 3G – Transmission 51

2.7 4G Requirements 542.7.1 4G – Capacity 54


2.7.2 4G – Energy Efficiency 582.7.3 4G – Mobility 652.7.4 4G - Security 672.7.5 4G – Quality of Service 672.7.6 4G – Sharing 692.7.7 4G – Smartphones 732.7.8 4G – LTE Downlink Speed 732.7.9 4G – LTE Uplink Speed 782.7.10 4G – LTE Total Comms 792.7.11 4G – Transmission LTE 812.7.12 4G – SON LTE 87

2.8 Remote Radio Head (RRH) 872.8.1 RRH 700 Frequency Division Duplexing (FDD) 872.8.2 RRH 850FDD 882.8.3 RRH AWSFDD 902.8.4 RRH PCSFDD 912.8.5 RRH 800FDD 922.8.6 RRH 900FDD 932.8.7 RRH 1800FDD 952.8.8 RRH 2100FDD 982.8.9 RRH 2300TDD 992.8.10 RRH 2600FDD 1012.8.11 RRH Weight 1032.8.12 RRH Volume 1032.8.13 RRH Power Efficiency 1032.8.14 RRH Stack 1042.8.15 RRH Environmental 1042.8.16 RRH Physical 1052.8.17 RRH MIMO 1052.8.18 Common Regulatory 106

2.9 BBU 1092.9.1 Baseband Unit Architecture 1092.9.2 BBU Physical 1102.9.3 BBU Multi-RAT 111


2.9.4 BBU Software 1122.9.5 BBU Rec Diversity 1132.9.6 BBU Connectivity 1142.9.7 BBU Capacity 1172.9.8 BBU Future Proof 120

2.10 BSC & RNC 1212.10.1 SRAN Controller Hardware 1212.10.2 SRAN Controller RNC Capacity 1222.10.3 SRAN Controller RNCBSC 1232.10.4 SRAN Controller Overload 1232.10.5 SRAN Controller Performance 1232.10.6 SRAN-Controller BSC Capacity 124


Glossary

3GPP Third Generation Partnership Project

8PSK eight-phase shift keying

AI/ML artificial intelligence/machine learning

ASIC application-specific integrated circuit

BBU baseband unit

BCCH broadcast control channel

BPF bandpass filter

BSC base station controller

BSS business support system

BTS base transceiver station

CE customer edge

COTS commercial off the shelf

CP control plane

CSFB circuit-switched fallback

CU central unit: a logical node hosting RRC, SDAP, and PDCP protocols

DDC digital down conversion

DFE digital frontend

DOCSIS Data Over Cable Service Interface Specification

DPD digital predistortion

DSP digital signal processing

DTM dynamic synchronous transfer mode

DU distributed unit: a logical node hosting RLC/MAC/High-PHY layers based on a lower-layer functional split

DUC digital up conversion

E2E End-to-End

EAB enhanced access barring


EGPRS enhanced GPRS

EMS element management system

eNB E-UTRAN Node B, a.k.a., Evolved Node B

EPC evolved packet core

FEC forward error correction

FPGA field programmable gate array

GMSK Gaussian minimum shift keying

GPP general-purpose processor

GPRS general packet radio service

HSDPA high-speed downlink packet access

HSPA high-speed packet access

HSUPA high-speed uplink packet access

IC interference cancellation

IRC interference rejection combining

IRP integration reference points

LCLS Linac Coherent Light Source

LNA low noise amplifier

M2M machine to machine

MCPA multi-carrier power amplifier

MEC multi-access edge computing (formerly mobile edge computing)

MME Mobility Management Entity

MSC mobile switching center

MTU maximum transmission unit

multi-RAB multiple radio access bearer

NAS non-access stratum

near-RT RIC near-real-time RAN intelligent controller


NETCONF Network Configuration Protocol

NMS network management system

non-RT RIC non-real-time RAN intelligent controller

NRI network resource identifier

NSA non-standalone

OAM operations, administration, and maintenance

OpCo operating company

OpenRAN A vendor-neutral disaggregation of RAN at both the hardware and software levels on general purpose, processor-based platforms

OSS operations support system

PA power amplifier

PDCP Packet Data Convergence Protocol

PGW packet data network gateway

PS packet switching

PSU power supply unit

QoS quality of service

RAB radio access bearer

RAN radio access network

RAT radio access technology

RFFE radio frequency frontend

RLC radio link control

RNC radio network controller

RR ready to receive

RRC radio resource control

RRH remote radio head

RRU remote radio unit

RU radio unit: a logical node hosting low-PHY layer and RF processing based on a lower-layer functional split


SA standalone

SACCH slow associated control channel

S-CCPCH secondary common control physical channel

SCPA

SDAP Service Data Adaptation Protocol

SDN software-defined network

SDR software-defined radio

SGSN serving GPRS support node

SGW serving gateway

SON self-organizing network

SRS sounding reference signals

TBF temporary block flow

TCH traffic channel

UMTS Universal Mobile Telecommunications System

UE user equipment

UNI user network interface

UP user plane

URA UTRAN registration area

UTRAN UMTS terrestrial radio access network

VAMOS voice services over adaptive multi-user channels on one slot

vRAN virtualized radio access network


1 Introduction This document describes the technical specification for an OpenRAN device that operators can deploy in current and future generations of mobile transport networks. It describes the requisite hardware, software, and regulatory requirements a device needs to meet to be deployed in networks of those operators participating in this specification.

1.1 Why OpenRAN? Telecom Infra Project (TIP) has created an OpenRAN project group that focuses on developing a vendor-

neutral, 2G, 3G, and 4G hardware and software-defined technology based on open interfaces and

community-developed standards. Unlike traditional RAN, OpenRAN decouples hardware and software.

This gives operators more flexibility as they deploy and upgrade their network architecture in various

deployment scenarios and geographies.

OpenRAN focuses on two fundamental aspects of RAN development—software-defined radio (SDR)-

based software and general-purpose processor (GPP)-based hardware. It features multiple architecture options:

● An integrated RAN with disaggregation at the hardware and software levels

● A split RAN with RU, BBU (DU/CU)

● A split RAN with RU, DU, and CU

Figure 1 – OpenRAN at a glance


The flexibility of multivendor solutions enables a diverse ecosystem for operators to choose best-of-breed

options for their 2G/3G/4G deployments. Solutions can be implemented on bare metal as well as on

virtualized or containerized platforms.

Figure 2 – OpenRAN developments

Figure 3 – OpenRAN use cases

With OpenRAN:

● OEMs can develop single-solution equipment that will interoperate

with deployed hardware by any vendor who chooses to adopt TIP technologies.

● Multi-vendor flexibility provides best of breed RRUs and virtual BBUs compatible

with GPP hardware options for a diverse set of deployment scenarios.

● Expands RAN vendor ecosystem and drives innovation, thereby becomes more

cost-effective than traditional integrated platform solutions.

The specifications presented herein in response to an RFI will help guide operators

toward the selection of a shortlist of vendors. Only RAN nodes that demonstrate open interoperability

from the perspective of the baseband processing platform, radio hardware, software and business model are considered.

1.2 Document Scope The aim of this document is:

● To describe the OpenRAN technical specifications that will need to be met by the system in terms

of hardware and software features.

● To describe the end-to-end network architecture covering interconnecting aspects between an

OpenRAN and the remainder of a network.

● To describe the management of OpenRAN combined with SDN controllers.

1.3 Document Structure This document is structured as follows:

● Section 1: Introduction

● Section 2: OpenRAN Requirements


o Subsection 2.1: General

o Subsection 2.2: Platform

o Subsection 2.3: Radio Functionality

o Subsection 2.4: Fronthaul

o Subsection 2.5: 2G Requirements



o Subsection 2.8: Remote Radio Head (RRH)

o Subsection 2.9: Baseband Unit (BBU)

o Subsection 2.10: Base Station Controller (BSC) & Radio Network Controller (RNC)


2 Requirements

2.1 General

OR-GE-01-001 An OpenRAN platform must run on GPP COTS hardware and enable separation of hardware and software vendors in the provision of the vRAN platform.

2.2 Platform

OR-PF-01-001 Based on a fully virtualized E2E vRAN platform

OR-PF-01-002 All 3GPP functions such as eNB, MME, SGW, PGW are to run as network virtual functions

OR-PF-01-003 Capable of supporting cloud-based architecture and infrastructure

OR-PF-01-004 The virtualized platform must support VMware

OR-PF-01-005 The virtualized platform must support KVM Hypervisor

OR-PF-01-006 The virtualized platform must support OpenStack

OR-PF-01-007 The virtualized platform must support hardware sharing via virtual machines

OR-PF-01-008 The virtualized platform must support self-scaling and self-healing features

OR-PF-01-009 The virtualized platform must support automated NW function deployment

OR-PF-01-010 The virtualized platform must be agnostic to the server platform vendor, e.g., HP, Dell

OR-PF-01-011 The product should be based on an industry standard GPP platform, e.g., X86 architecture

OR-PF-01-012 Must support the decoupling of the control and user planes

OR-PF-01-013

All L1, L2, L3 must be based on a GPP platform using COTS hardware. If not fully compliant, please specify which layer can be based on GPP (e.g., layer 1, 2, 3). Where a software layer is not GPP-supported, specify the silicon implementation (e.g., ASIC, FPGA, DSP)

OR-PF-01-014 There should be no dependency on ASICs, or specific silicon customization to support RAN platform functionality

OR-PF-01-015 Where supplementary performance accelerators are required, e.g., L1 processing, the preference is for software-based implementations

OR-PF-01-016

Where supplementary performance accelerators are required, e.g., L1 processing, hardware-based implementations (where used) should fully leverage any embedded GPP acceleration capability before additional silicon solutions are implemented


OR-PF-01-017 The platform must support a flexible vRAN architecture enabling highly centralized – high distributed implementations defined by operators’ requirements and local market topologies

OR-PF-01-018 The platform must support an Option 2 architectural split as defined by 3GPP/NGMN

OR-PF-01-019 The platform must support an Option 7 architectural split as defined by 3GPP/NGMN

OR-PF-01-020 Please describe all other 3GPP architectural splits supported in the OpenRAN implementation

OR-PF-01-021 The platform must simultaneously support all access product types and deployment scenarios, e.g., pico – macro, outdoor and in-building, without requiring platform segregation or additional gateways

OR-PF-01-022 The platform must be vendor agnostic in its 2G radio hardware support, e.g., remote radio heads




OR-PF-01-026 The interface between a CU and DU must be open, fully defined, documented, and available

OR-PF-01-027 The platform must be capable of running hardware and software from disparate vendors (including baseband and RRH). Please specify the partners in each layer (e.g., Layer 1, 2, 3, RRH)

OR-PF-01-028

Where a platform contains proprietary components or in essence is not fully open, application programming interfaces (API) must be made available with full documentation to permit interconnectivity of primary and subcomponents—thereby enabling full interoperability to be achieved between hardware and software component vendors

OR-PF-01-029 Should be fully scalable, with capacity and capability expansion achieved by further introduction of COTS hardware and/or more powerful GPPs

OR-PF-01-030 Any form of capacity or technology enhancement must be seamless to all “in-service” platform components, e.g., no customer service impact

OR-PF-01-031 Once a platform is in service it can evolve to “fully open” capability but must not devolve from “fully open” or “semi-open” to a closed or proprietary implementation

OR-PF-01-032 The platform must support multi-access edge computing (MEC) and third-party applications from vendors independent of the primary RAN platform software vendor. No additional hardware should be required to support this functionality


OR-PF-01-033 The vendor must make available an open interface/API to enable the integration of third-party MEC solutions. The interface must be clearly documented and available upon request

OR-PF-01-034 The OAM interface must expose modern programmatic interfaces to collect KPI in an automated environment (e.g., SNMP, HTTP REST) and must not be limited by any licensing scheme

OR-PF-01-035

The OAM interface must expose modern programmatic interfaces to configure and provision MME/IPSec settings in an automated environment (e.g., YANG, RESTCONF using XML or JSON format) and must not be limited by any licensing scheme

2.3 Radio Functionality

OR-SW-01-001 The GPP COTS platform must support 2G functionality as defined in 3GPP. Please state the supported 2G 3GPP release

OR-FU-01-002 The GPP COTS platform must support 3G functionality as defined in 3GPP. Please state the supported 3G 3GPP release

OR-FU-01-003 The GPP COTS platform must support LTE functionality as defined in 3GPP. Please state the supported LTE 3GPP release

OR-FU-01-004 The GPP COTS platform should support 5G functionality as defined in 3GPP. Please state the supported 5G 3GPP release

OR-FU-01-005 The platform must support multi-technology implementations, in any combination of those above. Please state any combination not supported

OR-FU-01-006 The GPP COTS platform must manage all servers as a dynamic pooled resource. No specific hardware must be allocated and limited to a specific technology

OR-FU-01-007 The GPP COTS platform must manage all servers as a dynamic pooled resource for the management of network capacity

OR-FU-01-008 A multi-technology implementation must be able to support RAN software from more than one vendor

2.4 Fronthaul

OR-FH-01-001 Fronthaul connectivity between platform and radio components should support IP Ethernet

OR-FH-01-002 Fronthaul connectivity between platform and radio components should support optical connectivity

OR-FH-01-003 Fronthaul connectivity between platform and radio components should support non-ideal transport mediums, e.g., satellite, microwave, DOCSIS


OR-FH-01-004 Data compression techniques must be applied to the fronthaul, such that the transmission overhead must be no more than 10% with respect to payload

OR-FH-01-005 Please state the maximum latency that can be tolerated on the fronthaul to maintain service on the air interface. Please state this against the disparate supported fronthaul solutions

2.5 2G Requirements

2.5.1 Energy Efficiency

Energy_2G_01 MCPA bias adaptation

MCPA can be intelligently adjusted according to the real-time based RF load, i.e., its working voltage can be dynamically adjusted based on traffic load criteria to improve performance and power efficiency.

Vendor can remotely activate this feature. There is no legacy hardware restriction and feature should have no impact on QoS.

Vendor must indicate if:

– this feature can also be supported in SCPA

– bias can be adapted at a time-slot level

– this feature can also be activated during specific time periods

Energy_2G_02 Carrier

switch off

Dynamic shutdown of 2G carriers in the case of multi-carrier sites, with several carriers for the same coverage area and based on the current traffic load.

Vendor must indicate:

– which physical resources are shutdown

– if this feature is implemented in RAN or in OSS

– if statistics per cell regarding number of handover and dropped calls due to this traffic steering are available through OSS

– if deactivation can be configured based in both traffic load and time period

– if this feature requires additional hardware components

Energy_2G_03

Transceiver (TRX) and power

amplifier (PA) shutdown

Automatic shutdown of individual TRX and PA devices based on current traffic load. Feature should be supported by legacy hardware and there should be no impact on hardware reliability and performance. Power consumption should be 0 watts when bias is switched off. Maximum reaction time is 0.5 seconds.

It should support both SCPA and MCPA products.

Vendor must indicate if:


– PA bias shutdown can be performed at a time-slot level.

– partially compliant because of a higher average reaction time, it should be indicated (in seconds)

Energy_2G_04 MCPA dynamic power sharing

between carriers

Each carrier must be possible to be configured in two different modes: fixed output power or dynamic power. Carriers in dynamic power mode will dynamically share all power not used by fixed power carriers.

Fixed output power must be possible to be configured in 0,2dB steps.

Total output power can be shared between GMSK and 8PSK carriers without any impact in the performance. For fixed output power carriers, maximum output power must be at least 20W for GMSK and 15W for 8PSK, no matter the number of active carriers (assuming that total amount of power is not surpassed).

Energy_2G_05

Broadcast control channel (BCCH) power consumption

reduction

BCCH carrier output power can be decreased up to 3dBs for all empty or traffic timeslots, and output power reduction can be configured in 1dB steps.

The power reduction can be performed in both SCPA and MCPA radio products.

In cells with multiple PAs, unused Pas should be off.

There should be no legacy hardware restriction.

2.5.2 2G – M2M

M2M_2G_01

Network overload control—

extended access barring

Feature for controlling originating access attempts from mobile stations (MSes) configured for EAB—specifically M2M devices—to prevent overload of 2G access network and/or core network. Rel-11 compliance required

M2M_2G_02

Network overload control—low priority MS indication counter

Counters to assess the following KPIs must be supported:

– Number of mobile stations reporting NAS signaling low priority indicator

– Number of 2G MSes indicating low priority indication in EGPRS packet channel request

No additional monitoring equipment, but common OSS needed to obtain KPIs shown above.


M2M_2G_03

Network overload control—MTC

reception: congestion

control

Network must use the following indicators to manage congestion in the RAN specified in 3GPP Rel-10:

– NAS signaling low priority indication for NAS level mobility management congestion

– Packet resource request (see GP-111432, GP-111344)

If a RAN node is congested or configured to prevent access for low priority devices, the network must reject or release the MS connection request and/or release established connection based on the low priority indication from the MS.

If a RAN node is aware of a MSC or SGSN dedicated for MTC devices (e.g., GDSP), the network must be able to release (with extended wait time, if supported) new low-value M2M connection establishments or active low-value M2M connection in the event of RAN congestion.

This includes low-value, data-only devices.

M2M_2G_04

Network overload control—MTC transmission: congestion

control

Network must support the implicit immediate assignment reject procedure in the event of RAN node congestion, as specified in Rel-10.

2.5.3 2G – MCPA Algorithms

MCPA_2G_01 MCBTS—

Dynamic power sharing

• Each carrier must be possible to be configured in two power modes: Fixed output or dynamic

• Carriers configured in dynamic power mode will dynamically share all unused power not used by fixed power carriers

• Fixed output power must be able to be configured in 0,2dB steps

• Total output power can be shared between GMSK and 8PSK carriers without any performance impact

• For fixed output power carriers, maximum output power must be at least 20W for GMSK and 15W for 8PSK, no matter the number of active carriers (assuming that total amount of power is not surpassed)

MCPA_2G_02 MCBTS—Admission

control

• Power margin at admission control will be defined to allow power variances due to power control algorithm

• At admission control, power required by the new user will be considered to allocate the best channel

• Initial power used at admission control must be able to be configured as: maximum power (BCCH) or estimated

• Initial power mode must be configurable by operator


MCPA_2G_03 MCBTS—

Congestion control

• Power congestion algorithms will be triggered whenever the power required in a timeslot period is close to the maximum output power of the PA

• Power congestion margin will be defined to start power congestion algorithms. It must also be configurable by an operator.

• Power congestion algorithm will consist of disparate actions to be prioritized by the operator

✔ Power congestion action (I). Reallocate users to other TS where more power is available

✔ Power congestion action (II). Relax power control algorithm to reduce power needed by each user

✔ Power congestion action (III). Reduce power used by packet data users

✔ Power congestion action (IV). Reduce power f or all users homogeneously

• When power congestion phase is over, altered algorithms will revert to original status

MCPA_2G_04

MCBTS—Dynamic power sharing for BSS

sharing

• Each operator can be allocated a fixed power amount

• Dynamic power-sharing algorithm can be used inside each operator’s allocated power

• Underlay/overlay cells can be defined for each operator

• Each operator can define independent BCCH and TCH output power from other operators

• Minimum 20 W BCCH output power must be available for each operator in any configuration (assuming total amount of power is not surpassed)

• Shared power pool can be defined and that power can be shared dynamically between operators

MCPA_2G_05 MCBTS—Data

power adaptation

• Output power allocated to data users must be able to differ from the one correspondent to an equivalent BCCH output power (as with SCPA technology)

• Data power adaptation must be available for all data modulations and technologies

• Output power allocated to data users must be possible to be configured to a higher level than the one correspondent to a normal BCCH output power if there is spare power not used for voice calls

2.5.4 2G – Mobility

Mobility_2G_01 Traffic steering—

Dual transfer mode

BTS must support the allocation of simultaneous RR connection and a TBF resource. Intra-RAT DTM handover must be supported.


Mobility_2G_02 Traffic steering—

Fast return to LTE

On channel release, a mobile station (MS) configured with LTE as the highest priority RAT must return immediately to LTE. If LTE coverage is not available, the MS must return to LTE as soon as it’s within LTE coverage.

Mobility_2G_03 Load Balancing—

SPID Support

The subscriber profile ID (SPID) for RAT/frequency priority parameter must be supported. The BSC must process the SPID and set the dedicated MS priorities accordingly.

2.5.5 2G – Security

SEC_2G_01 Ciphering

Algorithm— A5/3 and GEA3

KASUMI 64-bit ciphering key encryption for control channels, circuit switched voice traffic channels and GPRS data

SEC_2G_02 Ciphering

Algorithm— A5/4 and GEA4

KASUMI 128-bit ciphering key encryption for control channels, circuit-switched voice traffic channels and GPRS data. It must be software upgradeable from A5/3, i.e., there must be no hardware limitation if an OpCo has already deployed A5/3

SEC_2G_03

Cryptanalysis countermeasure—

Randomize L2 dummy bits

Padding bits used in access stratum layer 2 messages not reaching the N201 length limit must be random (GP-081417, GP-081418). The first padding octet must remain 0x2B for backward compatibility with legacy MS (GP-100282). There must be no legacy hardware limitation

SEC_2G_04

Cryptanalysis countermeasure—

Randomize SI6 padding bits

Padding bits used in system information type 6 message must be random. Compliance to GP-110384 and GP-110969 is required. There must be no legacy hardware limitation

SEC_2G_05

Cryptanalysis countermeasure—Change content of SI5, SI5bis, SI5ter as ciphering starts

Change the format and/or the set of ARFCNs in the neighbor cell description IE and the neighbor cell description 2 IE. Compliance to GP-110968 is required. There must be no legacy hardware limitation

SEC_2G_06

Ciphering Algorithm—

Ciphering Counters


● Ciphering Usage (e.g. % calls handled in A5/1, A5/3) ● NW performance in terms of ciphering type (e.g., Call

Setup Success Rate differentiated for A5/1, A5/3) No additional monitoring equipment other than common OSS must be needed to obtain above KPIs

2.5.6 2G – Refarming Enabler

COV_2G_01 Circuit switched voice capacity—

Quad rate

Pre-3GPP VAMOS solution must allow the pairing of two non-VAMOS mobiles on a half rate channel to increase voice capacity. There must be no limitation on activating


quad rate on more than one carrier simultaneously for all new and existing MCPA-based RRU products

COV_2G_02 Circuit switched voice capacity—

VAMOS

3GPP-compliant VAMOS solution must support the pairing of MSes on a half rate channel to increase voice capacity and/or hardware efficiency

Pairing of any combination of MS type, including VAMOS Type 1 and VAMOS Type 2 MSes, must be possible

Shifted-SACCH must be supported as specified in 3GPP

There must be no limitation on activating VAMOS on more than one carrier simultaneously for all new and existing MCPA-based RRU products

COV_2G_03

Circuit switched voice capacity—

VAMOS DL optimized pulse

An alternative to the use of a GMSK pulse shape on the DL has shown to further increase circuit switched voice capacity in 3GPP. The BTS must support an optimized pulse shaping filter on the DL that meets existing spectral emission requirements. This feature must have no hardware impact if VAMOS has already been deployed by an OpCo.

COV_2G_04

Circuit switched voice capacity—

VAMOS MS counter


● % penetration of VAMOS Type 1 MS ● % penetration of VAMOS Type 2 MS No additional monitoring equipment other than common OSS must be needed to obtain above KPIs

COV_2G_05

Circuit switched voice capacity—Local switching

support for VAMOS

Proprietary local switching solution or 3GPP-compliant LCLS solution must support VAMOS

2.5.7 2G – Sharing

Sharing_2G_01 Basic MORAN

for 2G It must be possible to support MORAN in 2G

Sharing_2G_02 2G MORAN—Different NRI

lengths

Shared BSCs must be able to operate with different NRI lengths per operator

Sharing_2G_03

2G operability—2G

performance management

The BSC must generate independent call performance statistics for each shared operator

Sharing_2G_04 2G

operability—Each operator must be able to independently access, read, and configure the parameters of its own cells (when


independent write rights on own cells

dedicated), w/o having any visibility of the cells of other operators—unless the accessing user is also master user of the OSS system managing the shared eNodes

Sharing_2G_05

2G MORAN beamforming—

Different tilts per operator

If an active antenna is capable to support beamforming, it must be possible to be set differently per operators (e.g., tilts per RAT and per uplink/downlink)

Sharing_2G_06 2G baseband

expansion

2.5.8 2G – Smartphones

Smartphones_2G_01 CS

Paging Priority

In paging congestion scenarios, CS paging must be prioritized over PS paging. CSFB from 3G/LTE must have the highest priority.

Smartphones_2G_02 RACH storms

A) Rogue devices can create consecutive RACH access with similar access information. Algorithm in place must reject such consecutive access to reduce SDCCH congestion

Feature should comply to algorithm below:

• Random accesses must be monitored for each cell, with a table storing last x random accesses (x being at least 20)

• Whenever a random access arrives to cell, it’s considered if it’s duplicated. To consider duplications random access information (RA) and timing advance (TA) are considered.

• If at least y accesses are found in cell table (y being configurable and at least = 4), then that random access is considered to be duplicated and won’t be considered

B) RACH storms created by UL interference can be interpreted by radio network as RACH accesses creating huger SDCCH congestion. Feature must identify such consecutive RACH accesses and reject them

Smartphones_2G_04 PS DL Power control

BTS power control for MCS-9 and dummy bits blocks must be supported

2.5.9 2G – Total Comms

TotalComms_2G_01 Basic fallback CS Fallback (CSFB) – basic w/o SIBs

TotalComms_2G_02 CS fallback with RIM

CS Fallback (CSFB) – w/ 2G SIBs via RIM

TotalComms_2G_03 Basic CS fallback

CSFB 3GPP CR improvements for indication toward BSC. GP-120444

CSFB indication in paging response message

Commented [1]: Appears as both UL and UI in tech spec spreadsheet)


“CR0959 to 44.018

TotalComms_2G_04 CS fallback—Fast return

to LTE Fast return from GSM to LTE

TotalComms_2G_05

VoLTE mobility—

SRVCC from LTE to 2G

SRVCC from LTE QCI 1 to GERAN (with and without DTM)

TotalComms_2G_06 Call

reestablishment Call reestablishment

2.5.10 2G – Transmission

TX_2G_01 Abis Compression/

Optimization

• TX resource pooling at site level

• No resource allocation if no data is being transmitted

• Silence suppression for voice

• Data compression techniques

• Resource pooling

• BTS Abis compression hubbing—Compression techniques can be applied to a group of BTS sharing a TX link

• BTS integrated (embedded) solution; i.e., no external hardware required for all BTS families: macro, RRH, Diet BTS

TX_2G_02 Abis over IP—

Ethernet interfaces Minimum number of electrical/optical Ethernet interface: 2 × 10/100Base-T

TX_2G_03 IP addressing

All options should be remotely configurable:

● All traffic carried over the same IP address ● OAM traffic carried over one IP address

and the remainder carried over another address ● OAM traffic carried over one IP address, signaling

traffic carried over a second address, and user traffic carried over a third address

TX_2G_04 VLAN

The eNB must support the operator configurable use of up to 8 VLANs compliant to IEEE802.1Q

Each defined VLAN must support different CoS (802.1p) to distinguish between disparate traffic types and ensure E2E QoS through the IP/MPLS network on any Ethernet interfaces:

1 VLAN per radio technology (2G/3G/4G). If X2 is unencrypted it could be useful to be able to map S1 and X2 on different VLANs


1 VLAN for O&M (providing it’s feasible to have a common VLAN for management of each of 2G/3G/4G)

1 VLAN for authentication/access control (802.1x over LAN/EAP-TLS)

1 VLAN for autoconfiguration (DHCP)

TX_2G_05 IP synchronization

IEEE1588V2 The BTS will support IEEE1588v2 version G.8265.1 (UDP/IP unicast)

TX_2G_06 IP synchronization with synchronous

Ethernet The BTS will support synchronous Ethernet

TX_2G_07 Synchronization

resiliency

The BTS must support a synchronization priority scheme. Here the network operator must be able to freely assign a priority to each possible synchronization source; the BTS must recover timing from the highest-priority available source that meets the required quality targets.

In the event of active clock source failure the BTS must recover synchronization from the next highest-priority source

TX_2G_08 IPv6 at transport layer hardware

IPv6 hardware readiness of offered equipment

TX_2G_09 Dual stack IPv4 and

IPv6 at transport layer

The BTS must support simultaneous IPv4 and IPv6 dual stack on the transport interfaces

TX_2G_10 Gb flex over PS with load balancing up

to 32 SGSN Gb flex over PS with load balancing up to 32 SGSN

TX_2G_11 A flex over CS with load balancing up

to 32 MSC A flex over CS with load balancing up to 32 MSC

TX_2G_12 Single RAN

independence resiliency

If one of the other RATs (LTE or 3G) fails, the BTS will be running without interruption in the data received and transmitted and the synchronization continuing without service outage


TX_2G_13 Aggregation of disparate RATs traffic

The BTS must be able to aggregate traffic from 2G as well as from LTE and/or 3G. Bandwidth is dynamically allocated to the arriving calls independent of the technology. Every technology can use up to the full amount of bandwidth and the QoS differentiation between traffic flows must be configurable by the operator, mapping between QoS parameters (QCI, TC, ARP, THP, MBR, GBR) and type of PS call: (GPRS, R99, HSPA, LTE) to the used transport layer (ATM classes of services or IP DSCP, 802.1Q)

2.6 3G Requirements

2.6.1 3G – Capacity

Capacity_3G_01 Capacity

HSPA scheduler capacity # users

UTRAN must support a minimum of 100 simultaneous users with an HSDPA and HSUPA PS RAB per cell in cell_DCH able to be served immediately by the HSPA scheduler without enhanced fractional DPCH, SRB on HSDPA, and CPC DTX/DRX features (all features OFF).

The vendor must specify the supported value according to its product roadmap.


cell_DCH capacity # users

UTRAN must support a minimum of 100 simultaneous users with an HSDPA and HSUPA PS RAB per cell in cell_DCH able to be served immediately by the HSPA scheduler with Enhanced Fractional DPCH, SRB on HSDPA, and CPC DTX/DRX features (all features ON).



cell_FACH capacity # users

UTRAN must support a minimum of 100 users simultaneously in cell_FACH state per cell, i.e., 100 users able to use RACH/FACH resources.




cell_PCH/URA_PCH capacity # users

UTRAN must support a minimum of 300 users simultaneously in cell_PCH. The same number of users must also be supported in URA_PCH state per cell.



Enhanced cell_FACH capacity # users

UTRAN must support a minimum of 200 users simultaneously in enhanced cell_FACH state per cell, i.e., 200 users able to use HS-RACH/HS-FACH resources (assuming 3GPP Rel'8 UE supporting enhanced cell_FACH in uplink and downlink).



HSPA scheduler NBAP signaling capacity

UTRAN must be able to support an aggregated NBAP signaling capacity at least equivalent to 1500 NBAP control messages per second including especially radio link setup, radio link addition, and radio link reconfiguration messages (e.g., a Node B must be able to support 1500 radio link setup messages per second).



HSPA scheduler RRC signaling capacity

UTRAN must be able to support 100 RRC requests per cell per second E2E (with no bottleneck neither in RNC nor Node B).




IC / IRC for control channels Rel'99 UL control channels

UTRAN must support interference cancellation (IC) or rejection (IRC) of individual DPCCH control channels operating on different sectors using same carrier frequency within a Node B.

IC or IRC must be applied on at least 50 active DPCCH channels simultaneously.



IC / IRC for control channels HSDPA UL control channels

UTRAN must support interference cancellation (IC) or rejection (IRC) of individual HS-DPCCH control channels operating on different sectors using same carrier frequency within a Node B.

IC or IRC must be applied on at least 4 active HS-DPCCH channels simultaneously (5 most impacting active channels).



IC / IRC for control channels HSUPA UL control channels

UTRAN must support interference cancellation (IC) or rejection (IRC) of individual E-DPCCH control channels operating on different sectors using same carrier frequency within a Node B.

IC or IRC must be applied on at least 4 active E-DPCCH channels simultaneously (5 most impacting active channels). INTRA-NODEB


IC / IRC for control channels PRACH

UTRAN must support interference cancellation (IC) or rejection (IRC) of individual PRACH channels operating on different sectors using same carrier frequency within a Node B.


IC / IRC for data channels HS-PRACH

UTRAN must support interference cancellation (IC) or rejection (IRC) of individual HS-PRACH channels operating on different sectors using same carrier frequency within a Node


B.

(Enhanced cell_FACH 3GPP Rel'8 feature).



Special Events – Unplanned High level principle

UTRAN must support an automatic feature to detect high concentration of smartphones in a cell or a cluster of cells based on operator-configurable triggers; it must act upon the congestion through disparate sets of actions to minimize performance impact to users in the cell.


Special Events – Unplanned Triggers

UTRAN must support at least the following threshold triggers for the detection of an unplanned event and the monitoring of the load during the duration of the event:

- average number of connected HSDPA users

- average number of active HSDPA users- average number of connected HSUPA users

- average number of active HSUPA users

- average number of PS Rel'99 uplink users

- average number of cell_FACH users

- average number of enhanced cell_FACH DL users

- average number of enhanced cell_FACH UL users


Special Events – Unplanned Cell level configuration

UTRAN must support activation of the automatic feature for unplanned event at cell level and cell level definition of parameters, including triggers and actions.


Special Events – Unplanned Action - Grouping

UTRAN must support the grouping of actions to be taken when detecting an unplanned event in two different sets:

1st-level actions set and 2nd-level actions set.

Note that 2nd-level actions are more drastic actions that an operator would like to activate in case of very serious congestion.


Special Events – Unplanned Action - Grouping

UTRAN must support for each set of actions (1st- or 2nd-level) the possibility to configure the activation one by one of the different possible actions.



Special Events – Unplanned Action – Grouping

UTRAN must support specific load thresholds (according to the triggers defined for unplanned events) for the activation and deactivation of each set of actions:

- 1stSetON/1stSetOFF thresholds to allow the activation/deactivation of the 1st-level actions

- Similarly 2ndSetON/2ndSetOFF thresholds to activate/deactivate the 2nd-level actions

A configurable timer must also be supported to control the time over which the load is measured.

All 1st level actions must remain active when the 2nd-level actions are triggered unless an incompatibility is identified between features from the two sets.


Special Events – Unplanned Action – Access Class Barring

UTRAN must support the use of full access class barring and PS domain access class barring at cell level as part of the group of automated actions for unplanned events. The number of access classes in the access class group to be barred—as well as the duration of the barring for one given group—must be configurable. The access class group should be rotated to have uniform distribution of users barred.


Special Events - Unplanned Action - CPICH power reduction

UTRAN must support the reduction of CPICH power at cell level as part of the group of automated actions for unplanned events to improve accessibility and user experience for users in the cell. The reduction of CPICH power aims at reducing the number of users handled by the cell and reduce overlaps between (SHO ratio).


Special Events – Unplanned Action – 2ms TTI deactivation

UTRAN must support the automatic deactivation of 2 ms TTI at cell level for HSUPA during the duration of the unplanned event. All new calls should be set up with 10 ms TTI for HSUPA


radio bearers. Existing HSUPA 2 ms TTI calls should be reconfigured to 10 ms TTI to ensure that no 2 ms TTI users remain in the cell after this feature gets triggered.

Capacity_3G_22

Capacity Special Events – Unplanned Action – Adaptive RRC state

configuration

UTRAN must support the adaptation of all state transition parameters at cell level to configure the use of the RRC states over the duration of an unplanned event (cell_DCH, cell_FACH, cell_PCH/URA_PCH).

Capacity_3G_23

Capacity Special Events – Unplanned

Action – Load Balancing enforcement

UTRAN must support the enforcement of load balancing in cell/URA_PCH and idle mode between all carriers by means of cell reselection parameters ensuring equal number of users in the different carrier. This feature must ensure that no carrier is barred, that neighbor relations are correctly defined for all carriers, and that the relevant idle/connected and neighbor cell reselection parameters are defined to ensure equal load balancing.

Capacity_3G_24

Capacity Special Events – Unplanned

Action – 3G CS voice redirection to 2G

UTRAN must support the automatic redirection of 3G CS voice calls to 2G during the duration of the unplanned event. The feature must support both CS RAB´s and CS+PS multi-RAB redirection to 2G CS.


Special Events – Unplanned Action – reduced SRB rate

UTRAN must support reconfiguration of the signaling radio bearer SRB 13.6 kbps to SRB 3.4 kbps during the duration of the unplanned event for the PS RRC connections only.


Special Events – Planned Uplink receiver desensitization

UTRAN must support uplink signal attenuation to minimize interference from UE close to the antenna (e.g., UE with SIR superior to SIR target when SIRtarget=SIRtargetmin).


Paging capacity CS over PS paging priority

RNC must prioritize CS paging over PS paging at cell level in case of congestion of the configured PCH paging channel(s). This prioritization must be supported in a multi-RAN-CN vendor scenario.



Paging capacity Sequential paging in URA_PCH

RNC must support sequential paging, allowing to page user in a first step in the last known cell as well as neighboring ones and in a second step to page user over the whole URA if first step not successful.


RRC Load Control RRC storm protection

UTRAN must support activation of RRC load control feature, triggered based on operator-configurable triggers—including RRC connection rejects to protect RNC and Node Bs from RRC signaling storms. At Node B-level the feature should allow to protect from overload due to the high amount of RL setups.


cell_FACH capacity cell_FACH traffic handling

UTRAN must prioritize SRB signaling over PS data traffic when facing congestion on S-CCPCH when sharing S-CCPCH between SRB signaling and PS data.


cell_FACH capacity SRB & RAB setup

UTRAN must allow the establishment of the SRB and RAB assignment in cell_FACH state (without the need to use cell_DCH state), thereby allowing the user to be allocated a data RAB in cell_FACH directly from cell_PCH/URA_PCH.


cell_FACH capacity cell_FACH load control

UTRAN must support a load control mechanism in cell_FACH when reaching a given congestion threshold of the FACH resources to balance load in cell_FACH based on intra-frequency and inter-frequency cell reselection parameters.


cell_FACH capacity cell_FACH load control

UTRAN must support a load control mechanism in cell_FACH when reaching a given congestion threshold of the FACH resources to allocate no (or minimum) RACH/FACH resources to part of the users in cell_FACH or coming from cell_PCH or URA_PCH (sort of barring in RACH/FACH resources).


Special Events - Planned SRB & RAB phase load control

UTRAN must support operator configurable SRB and RAB allocation based on cell load (e.g., number of


users, DL power) independently for SRB and RAB establishment. Operator must be able to configure cell_FACH or cell_DCH (including PS0) load control in both SRB and RAB phases.

For example, for low load the SRB and RAB would be established in cell_DCH; for medium load SRB would be established in cell_DCH and RAB in cell_FACH; for high load both would be established in cell_FACH.

PS0 could be used in cell_DCH as an alternative for RAB phase to fully mute the user.


Combined DL cells Software support

UTRAN must support the configuration of up to six RRUs as a unique downlink cell, where uplink reception is independent per RRU and downlink transmission is synchronous across all RRUs.


2.6.2 3G – Energy

Energy_3G_01 Energy Efficiency

PA bias adaptation

Automatic adaptation of PA bias voltage, i.e., its working voltage can be dynamically adjusted based in RF load to improve performance and efficiency.

Vendor can remotely control whether this feature is activated or not. There is no legacy hardware restriction. This functionality should be supported in Node B, RRH, and AAS.


- Minimum time to adapt the voltage to the traffic load (in seconds)

- Indicate if this feature is directly implemented in Node B or if it’s an OSS-based implementation.

Energy_3G_02

Energy Efficiency Dynamic power sharing

between carriers -

In the case of multiple 3G carriers mapped to the same PA, if one isn’t using all the allocated power then it can be used by the others. This functionality allows dynamic sharing of DL power between two carriers belonging to the same sector.

This functionality should be supported in Node B, RRH and AAS.

Vendor must indicate if this feature can be supported in case of BSS sharing.


Energy_3G_03 Energy Efficiency

Carrier deactivation -

Dynamic shutdown of 3G carriers in the case of multi-carrier sites, with several carriers for the same coverage area, based on the current traffic load. Traffic steering is performed before the carrier is turned off.

Before carrier shutdown, it’s analyzed if dual carrier-capable terminals are connected. If so, shutdown would not take place.

This functionality should be supported in Node B, RRH, and AAS.


- Minimum time required for enabling again the carrier (in seconds)

- If deactivation can be configured based in both traffic load and time period

- If specific statistics per cell regarding number of HO and dropped calls due to this traffic steering are available through OSS

- If additional hardware components are needed for this feature


Energy_3G_04 Energy Efficiency Cell shut down

-

Shutting down of physical 3G resources such as individual RRUs when low or no traffic. Assumes multi-frequency 3G bands deployed on the same eNB, such that one frequency band (e.g., 2.1GHz 3G) can be shut down, leaving 900MHz 3G active. Traffic steering is performed before the carrier is turned off.

This functionality should be supported in Node B, RRH, and AAS.


- Which physical resources are shut down

- Minimum time required for reenabling the carrier (in seconds)

- If deactivation can be configured based in both traffic load and time period

- If specific statistics per cell regarding number of HO and dropped calls due to this traffic steering are available through OSS

- If additional hardware components are needed for this implementing this feature


Mobility_3G_01 Mobility

Load Balancing SPID Support

The subscriber profile ID for RAT/ frequency priority (SPID) parameter must be supported. The RNC must process the SPID and set the dedicated priorities accordingly.

Mobility_3G_02 Mobility

Traffic Steering Fast Return to LTE

On RRC connection release, a UE configured with LTE as the highest priority RAT must return immediately to LTE. If LTE coverage isn’t available, the UE must return to LTE as soon as it’s in LTE coverage.

Mobility_3G_03

Mobility Traffic Steering

3G->2G Directed Retry (CS domain only)

Where the RNC has no RAB configuration for a particular UE in the CS domain, and the RNC receives a RAB ASSIGNMENT REQUEST message for that UE requesting the


establishment of one RAB only, a directed retry to perform inter-system handover to GSM must be initiated (see 3GPP TS25.413 subclause 8.2.4). The context of PS bearers must be maintained.

Mobility_3G_04


3G->LTE PS Handover based on coverage

Where UE is configured with LTE as the highest priority RAT, the network must make it possible for a UE in connected mode to handover to LTE when within LTE coverage.

Where 3G coverage has fallen below a predefined threshold as measured by the UE, the network must be able to command a handover to LTE if no other 3G layer is available.

Mobility_3G_05


3G->LTE PS Handover based on load

The network must command a PS handover to a UE in connected mode when 3G is heavily loaded and there is capacity in LTE.

Mobility_3G_06

Mobility Traffic Steering Steer HSPA UE

based on DL Load

The network must be able to redirect a UE to another 3G DL layer when the current layer is heavily loaded and there is capacity in an overlapping DL layer with good EcNo and RSCP.

The network must be able to perform this function also in CELL_FACH.

Redirection must be possible during the RRC connection establishment procedure, cell change, and RAB assignment.

DL load must be measured based on the number of users, number of codes, and available power.

Mobility_3G_07

Mobility Traffic Steering Steer HSPA UE

based on UL Load

The network must be able to redirect a UE to another 3G UL layer when the current UL layer is heavily loaded and there is capacity in an overlapping DL layer with good EcNo and RSCP (UE measured).

The network must be able to perform this function also in CELL_FACH.

Redirection must be possible during the RRC Connection Establishment procedure, cell change and RAB


assignment.

UL load must be measured based on the number of users and available power.

Mobility_3G_08


Steer HSPA UE in connected mode to least congested cell

The network must steer a UE, in connected mode, to another cell when that cell is less congested compared to the current cell. Steering must be possible between any inter-frequency and intra-frequency bands.

2.6.4 3G – Quality of Service

QoS_3G_01

QoS HSDPA nominal bit rate

based on SPI (ARP and THP) -

A minimum QoS will be offered to each user (R.99&HSPA (HSDPA & EUL)). A limit on the minimum throughput (nominal bit rate) to be offered to each user will be configurable.

To be used in call admission (CAC), congestion and scheduling (radio and transport).

QoS_3G_02

QoS E-DCH Nominal Bit Rate based

on SPI (ARP and THP) -

A minimum QoS will be offered to each user (R.99&HSPA (HSDPA & EUL)). A limit on the minimum throughput (nominal bit rate) to be offered to each user will be configurable.

To be used in call admission (CAC), congestion and scheduling (radio and transport).

QoS_3G_03 QoS

QoS HSDPA flow control -

HSDPA flow control based on SPI (ARP/THP) and SPI weight when allocating the bandwidth to every user; including QoS differentiation between users of different cells of the NB (for ATM and IP).

QoS_3G_04

QoS Basic Counters to monitor

QoS (throughput) -

Specific counters must monitor the throughput per each QoS class as part of basic QoS package (i.e., per each SPI).


QoS_3G_05

QoS Fair management R99 vs.

HSDPA. HSDPA traffic -

R.99 doesn't preempt by default (throughput decrease or user release) HSPA traffic. A configurable fairness must be available to distribute the resources available between HSPA and R.99 traffic (nRT traffic) as a function of THP/ARP.

QoS_3G_06 QoS

Aggregated Maximum Bit Rate -

UTRAN must support an aggregated maximum bit rate per UE for HSPA (UL/DL) and R99.


Sharing_3G_1 Sharing

3G MORAN Basic

MORAN must be supported with up to three network operators, each of them with a number of independent UMTS carriers within the Node B limit. It must be possible to freely support a mix of UMTS900 & 2100 cells.


3G Operability 3G Performance Management

The RNC must generate independent call performance statistics for each shared operator.

Sharing_3G_3

Sharing 3G Operability

3G Independent write rights on own cells

Each operator must be able to independently access, read, and configure the parameters of its own cells (when dedicated), w/o having any visibility of other operators’ cells unless the accessing user is also master user of the OSS system managing the shared eNodes.


3G Baseband Baseband expansion

It must be possible to expand the BBU of the shared 2G/3G or LTE nodes, adding additional BBUs and maintaining the same logical Node B toward the BSC/RNC, core network nodes, and OSS system. Please highlight the maximum number of BBUs that can be connected with respect to this requirement.


3G MORAN Max number of cells

MORAN Node Bs must be able to support at least 18 cells, using up to two BBUs.


3G MORAN different NRI lengths

Shared RNCs must be able to operate with different NRI lengths per operator


Sharing_3G_7

Sharing 3G MORAN

Independent QoS per operator over the Iub

The RNC and Node B must permit combining the QoS parameters of the operator and derive a new set of parameters applicable to the common Iub to avoid a situation where a wrong/independent QoS setting of one operator always implies higher packet priority of one operator vs another.

Sharing_3G_8

Sharing 3G MORAN

Flexible power split between carriers

Carrier power within the same PA can be flexibly split between operators with a granularity of at least 10 watts

Sharing_3G_9

Sharing 3G MORAN

900 MHz: different UMTS bandwidth per operator

It must be possible to set the carriers of the operators sharing 900 to different carrier bandwidth within the same PA


3G MOCN MOCN basic

Spectrum sharing must be supported to up to four operators, sending multiple PLMN-Ids

Sharing_3G_11

Sharing 3G MOCN

MOCN: Shared and non-shared NodeBs supported under

the same RNC

It must be possible to connect both shared and non-shared Node Bs to the same RNC.


3G & 2G 900 Sharing Sharing 900 in both 2G and 3G

It must be possible to share the same RRU/AAS/PA in 900 in both 3G (MORAN or MOCN) and GSM, so that part of the iBW is dedicated to 2G sharing and another to 3G sharing.


Smartphones_3G_01 Smartphones

CPC

Enhanced HSPA always-on is a package of features that can significantly enhance the HSPA user experience. The enhanced always-on requires the following feature set:

• SRB on HSPA

• Enhanced fractional-DPCH (3GPP Rel’7 solution)

• UL DTX and DL DTX feature (3GPP Rel’7 gating solution) for interactive


and background


Fractional DPCH Release 7 with SRBs on HSPA

Fractional DPCH Release 7 with SRBs on HSPA


Fast Dormancy Rel8

This is an enabler for battery savings. UE informs the network it doesn’t plan to transfer any more data to allow the UE to be put in a battery-efficient state (CELL PCH and URA PCH)


Enhanced FACH DL

Feature necessary to carry the signaling with FACH over HSPA to improve flexibility for fast data transfer over FACH, and to remove needed transition to CELL_DCH when doing intermittent traffic.

• Rel 7: HSDPA in Cell-FACH

• Needed to have CQI feedback on UL

• E_Cell_FACH transition after inactivity or low data volume in Cell_DCH


Enhanced FACH UL

Ability to send RACH over HSUPA and allow data transfer via direct transition from Cell_PCH: • Rel 8: HSUPA in Cell-FACH

• Needed to have CQI feedback on UL

• E_Cell_FACH transition after inactivity or low data volume in Cell_DCH


Enhanced UE DRX in Cell_FACH

Battery saving while in FACH state; allows DRX in Cell_FACH state w/ some compromises to mobility performance


Direct Transition from PCH/URA to DCH

The network must be able to upswitch directly from PCH/URA to DCH. This reduces FACH congestion, signaling, and latency.

2.6.7 3G – Speed

Speed_3G_DL_01 Speed – DL

Dual Carrier Dual Band (HSDPA) Support dual carrier, where carriers are in the 900MHz and 2100MHz bands,


Two carriers: 1x900 + 1x2100 respectively.


Dynamic BLER support in HSDPA scheduler

UTRAN must support the ability to dynamically modify BLER target on a per user and cell basis given the variations in radio conditions while taking into account the reported CQI (CQI adjustment) resulting in an optimal BLER target.


Dynamic power sharing between carriers

Carrier power allocations should be able to be adjusted dynamically depending on carrier load.

Speed_3G_UL_01 Speed – UL

Dynamic BLER support in HSUPA scheduler

UTRAN must support the ability to dynamically modify BLER target on a per user and cell basis given variations in radio conditions and received grants resulting in an optimal BLER target.


Dynamic RoT for HSUPA

The RNC must be able to dynamically adapt the RoT target delivered to the Node B on a per cell basis. The RNC must also be able decrease ROT target (e.g., if negative impacts are observed on other (i.e., CS) users).

Speed_3G_UL_03

Speed – UL Interference Cancellation –

Inter Cell, Intra Node B Applicable to R99 – DPDCH

for up to ten users

UTRAN must support IC of individual DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to ten active DPDCH channels simultaneously.


Speed_3G_UL_04


Inter Cell, Intra Node B Applicable to HSUPA UP 2ms users (E-DPDCH),

up to five users

UTRAN must support IC of individual E-DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to five active E-DPDCH channels simultaneously.



Speed_3G_UL_05


Inter Cell, Intra Node B Applicable to HSUPA UP 10ms users (E-DPDCH),

up to ten users

UTRAN must support IC of individual E-DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to ten active E-DPDCH channels simultaneously.


Speed_3G_UL_06


Inter Cell, Intra Node B Applicable to R99 – DPDCH for up to ten users (4-way Rx Div)

UTRAN must support IC of individual DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to ten active DPDCH channels simultaneously—in a 4-way Rx Div antenna configuration.


Speed_3G_UL_07


Inter Cell, Intra Node B Applicable to HSUPA UP 2ms users (E-DPDCH), up to five

users (4-way Rx Div)

UTRAN must support IC of individual E-DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to five active E-DPDCH channels simultaneously —in a 4-way Rx Div antenna configuration.


Speed_3G_UL_08


Inter Cell, Intra Node B Applicable to HSUPA UP 10ms

users (E-DPDCH), up to 10 users (4-way Rx Div)

UTRAN must support interference cancellation of individual E-DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to ten active E-DPDCH channels simultaneously—in a 4-way Rx Div antenna configuration.



Speed_3G_UL_09


Inter Cell, Intra Node B FDIC (Full Decodification

Interference Cancellation) – additional iterations & full decodification of received

interference from up to five users

The vendor must specify the number of additional iterations and decodifications within its IC solution.

Speed_3G_UL_10

Speed – UL Interference Rejection

Combining Applicable to R99 users

(DPDCH), up to ten users

UTRAN must support interference rejection combining of individual DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to ten active DPDCH channels simultaneously.


Speed_3G_UL_11


Combining Applicable to HSUPA UP 2ms

users (E-DPDCH), up to five users

UTRAN must support interference rejection combining of individual E-DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to five active E-DPDCH channels simultaneously.


Speed_3G_UL_12


Combining Applicable to HSUPA UP 10ms

users (E-DPDCH), up to ten users

UTRAN must support interference rejection combining of individual E-DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to ten active E-DPDCH channels simultaneously.


Speed_3G_UL_13


Combining Applicable to R99 users

(DPDCH), up to ten users

UTRAN must support interference rejection combining of individual DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must


(4-way Rx Div) be applied to up to ten active DPDCH channels simultaneously—in a 4-way Rx Div antenna configuration.


Speed_3G_UL_14


Combining Applicable to HSUPA UP 2ms users (E-DPDCH),

up to five users (4-way Rx Div)

UTRAN must support interference rejection combining of individual E-DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to five active E-DPDCH channels simultaneously —in a 4-way Rx Div antenna configuration.


Speed_3G_UL_15


Combining Applicable to HSUPA UP 10ms users (E-DPDCH),

up to ten users (4-way Rx Div)

UTRAN must support interference rejection combining of individual E-DPDCH user plane channels operating on different sectors using same carrier frequency within a Node B, and must be applied to up to ten active E-DPDCH channels simultaneously—in a 4-way Rx Div antenna configuration.



HSUPA Time Division scheduling

UTRAN must support the scheduling of HSUPA users on a per time slot-basis (applicable only to 2ms users)


Enhanced L2 UTRAN must support configurable RLC PDU sizes

Speed_3G_UL_18

Speed – UL Reconfiguration HSUPA 2ms <=> 10ms based upon UL

Interference

UTRAN must dynamically switch from between 2ms and 10ms usage depending upon the UL interference (load) conditions at a given time.

Speed_3G_UL_19

Speed – UL HSUPA enhancements

at cell edge (Rel'8) E–DPDCH gain factor

UTRAN must be able to scale the "minimum reduced E-DPDCH gain factor," such that subsequent equal scaling of physical channels is applied.


Speed_3G_UL_20

Speed – UL Dual Carrier HSUPA (Rel'9) –

Software support Using QPSK

Support of "11.4 Mbps" in the UL using dual carrier and QPSK modulation scheme.

Speed_3G_UL_21

Speed – UL Dual Carrier HSUPA (Rel'9) –

Software support Using 16 QAM

Support of "22.8Mbps" in the UL using dual carrier and 16QAM modulation scheme.


Single Carrier HSUPA Using 16 QAM

Support of "11.4 Mbps" in the UL using single carrier and 16QAM modulation scheme.

2.6.8 3G – Total Comms

TotalComms_3G_09 Total Comms CS Fallback

Basic CS Fallback

CS fallback (CSFB) – basic w/o SIBs


CS Fallback DMCR

CS fallback (CSFB) – DMCR Rel8


CS Fallback with PS Handover

CS fallback (CSFB) – PS handover to 3G


CS Fallback with PS Handover

CS Fallback (CSFB) – PS handover with configurable 3G multi-RAB or single CS RAB setup. Operator must be able to configure the RAB setup in 3G depending on the LTE PS non-GBR previous UE status.

E.g., if the UE has a PS connection in LTE, then multi-RAB voice+HSPA will be set up in 3G directly after the handover.

If the UE was in idle mode in LTE, then voice+PS 0/0 will be set up in 3G after the handover to avoid waste of resources and call drop risk.

TotalComms_3G_14

Total Comms CS Fallback

Basic CS Fallback CRs improvements

CSFB 3GPP CR improvements for indication towards RNC. RP-120808, “Introduction of a CSFB Indicator in RRC Connection Request” CR5026 to 25.331 for R9


Fast Return from WCDMA to LTE


Fast Return to LTE

TotalComms_3G_16

Total Comms Mobility

PS handover LTE non-GBR to 3G non-GBR

PS Handover from LTE non-GBR QCI to UTRAN HSPA interactive background

TotalComms_3G_19

Total Comms Mobility

PS handover LTE non-GBR from 3G non-GBR

PS Handover from UTRAN HSPA interactive background to LTE non-GBR QCI

TotalComms_3G_22 Total Comms

Mobility SRVCC from LTE to 3G

SRVCC from LTE QCI 1 to UTRAN CS (with and w/o PS HO support)


Call Reestablishment Call Reestablishment intra-site

Configurable per TC, and fully parametrization configurable


Call Reestablishment Call Reestablishment inter-site



Call Re-establishment Call Reestablishment inter-RNC



Call Reestablishment Call Reestablishment triggers

Support call reestablishment for radio link failure and any SRB reset produced in the communication in DL and UL. Provide detailed description of the procedures and messages supported per release.


Multi-RAB Multi-RAB bearer

Voice over CS over DCH + 3 PS interactive background over HSPA


Multi-RAB Multi-RAB bearer

Voice over CS over DCH + PS Streaming over HSPA + 2 PS interactive background over HSPA

TotalComms_3G_33

Total Comms Multi-RAB

Multi-RAB mobility management

Differentiated control over compressed mode activation and inter-frequency hard handover for multi-RAB connections will permit tuning the mobility performance to the most suitable for MRAB


Multi-RAB Multi-RAB performance

The performance of the multi-RAB CS+HSPA must be similar to the performance of CS+R99 DCH


(UL and DL)

2.6.9 3G – Transmission

TX_3G_01 Transmission IP –

Ethernet interfaces Minimum number of electrical/optical Ethernet interface: 4x10/100BASE-T

TX_3G_02 Transmission IP addressing IP addressing

All option should be remotely configurable.

a. All traffic carried over the same IP address

b. OAM traffic carried over one IP address and the remainder of traffic carried over another IP address

c. OAM traffic carried over one IP address, signaling traffic carried over another IP address and user traffic carried over another address

TX_3G_03 Transmission

VLAN VLAN

The eNB must support the operator-configurable use of up to eight VLANs compliant to IEEE802.1Q; each defined VLAN must support different CoS (802.1p) to distinguish between different traffic types, thereby ensuring E2E QoS through the IP/MPLS network on any Ethernet interfaces—one VLAN per radio technology (2G/3G/4G).

If X2 is unencrypted, it could be useful to map S1 and X2 on different VLANs: one VLAN for O&M (providing it’s feasible to have a common VLAN for management of both 2G/3G/4G), one VLAN for authentication/access control (802.1x over LAN/EAP-TLS), and one VLAN for autoconfiguration (DHCP)


IP QoS mapping IP VLAN QoS handling

Support QoS management capabilities on Iub: Full flexibility to map the traffic (marked by the ARP/THP) onto any of the defined paths.

QoS at layer 2: Ethernet quality of services IEEE 802.1P standard/LAN layer 2 QoS/CoS protocol for prioritization and IEEE 802.1Q


standard VLAN tagging


IP QoS mapping IP DSCP QoS handling

Support QoS management capabilities on Iub: Full flexibility to map the traffic (marked by the ARP/THP) onto any of the paths defined at QoS at layer 3 using the DiffServ DSCPs


Synchronization IP Synchronization IEEE1588V2

The Node B will support IEEE1588v2 version G.8265.1 (UDP/IP unicast)

TX_3G_07

Transmission Synchronization

IP Synchronization with Synchronous Ethernet

The Node B will support synchronous Ethernet


Synchronization Synchronization resiliency

The NB must support a synchronization priority scheme, whereby the network operator must be able to freely assign a priority to each possible synchronization source and the NB must recover timing from the highest-priority available source (thereby meeting the required quality targets).

In the event of failure of the active clock source the NB must recover synchronization from the next highest-priority source.


IP multiplexing IP Multiplexing

The RNC and Node B will multiplex more than one user in the Iub interface over the same IP packet.

It must be possible to define a timer per IP pipe (by using different QoS management) from the upper layers to multiplex different users’ flow in the same IP packet. This timer will never be longer than the TTL defined in the IP header.

TX_3G_10

Transmission Link Aggregation

Link Aggregation in the RNC intra-boards

The RNC will support link aggregation intra-IP interface ports RNC card.

Link aggregation must allow one or more links to be aggregated together (either on the same or different boards) to form a link aggregation


group, such that a MAC client can treat this group as if it were a single link (from IEEE Standard 802.3).

TX_3G_11

Transmission Link Aggregation

Link Aggregation in the RNC inter-boards

The RNC will support link aggregation inter-IP interface ports RNC cards


IPv6 IPv6 at transport layer HW

IPv6 hardware readiness to be offered.

TX_3G_13

Transmission IPv6

Dual-stack IPv4 and IPv6 at transport layer

The RNC and the Node B must support simultaneous IPv4 and IPv6 dual-stack on the transport interfaces.


Ethernet OAM Ethernet OAM

Ethernet ports must support:

i. Maintenance association end point (MEP) on a per VLAN basis

ii. Loopback reply message (LBR) function toward its peer MEP(s) in response to both unicast and multicast loopback request message (LBMs)

iii. Generating continuity check messages (CCMs)

iv. Receiving AIS messages

v. The appropriate alarms for loss of continuity

vi. Turning off sending of CCMs while keeping the associated MEP active

TX_3G_15

Transmission MTU at Iu over IP

Support of MTU higher than 1600 bytes

The MTU size of the Iu over IP interfaces must be higher than 1600 bytes

TX_3G_16

Transmission Iu Flex

Iu flex over PS with load balancing up to 32 SGSN

Iu flex over PS with load balancing up to 32 SGSN

TX_3G_17

Transmission Iu Flex

Iu flex over CS with load balancing up to 32 MSC

Iu flex over CS with load balancing up to 32 MSC



RANAP overload RANAP Overload Support

RANAP overload defined by 3GPP support

TX_3G_19 Transmission resiliency –

IuCS multihoming

The RNC must provide with functionality (hereafter “IuCs multihoming”), where a single RNC is connected with a couple of MGWs. RNAP signaling refers to a single MSS (no full redundancy in R4 is achieved) therefore the two MGWs continue to have the STP functionality embedded for IP and ATM.

TX_3G_20 Transmission resiliency –

SCTP multihoming

The RNC must support SCTP multihoming functionality according to RFC2960

TX_3G_21

Transmission resiliency –

Single RAN independence resiliency

If one of the other RATs (LTE or 2G) fails, the Node B will be running without interruption in the data received and transmitted and the synchronization continuing without service outage.

TX_3G_22

Transmission Single RAN aggregation – Aggregation of different

RATs traffic

The Node B must be able to aggregate traffic from 3G and also from 2G and/or LTE. The bandwidth is dynamically allocated to arriving calls independent of the technology. Every technology can use up to the full amount of bandwidth and the QoS differentiation between different traffic flows must be operator-configurable, with mapping between QoS parameters (QCI, TC, ARP, THP, MBR, GBR) and type of PS call: GPRS, R99, HSPA, LTE) to the used transport layer (ATM classes of services or IP DSCP, 802.1Q).

2.7 4G Requirements

2.7.1 4G – Capacity

Capacity_LTE_01 Capacity

Uplink scheduler – FSS

High level principle

E-UTRAN must support interference-aware and channel-aware frequency selective scheduling (FSS) using SRS.

Capacity_LTE_02 Uplink Sound reference E-UTRAN must support sounding


Capacity scheduler – FSS signals (SRS) reference signals for FSS including all SRS bandwidth and subframe configurations from TS 36.211.



SRS E-UTRAN must support uplink reference signal hopping for SRS.



Frequency hopping

E-UTRAN must support PUSCH and PUCCH frequency hopping.


Uplink Receiver – IRC

IRC for PUCCH E-UTRAN must support IRC for uplink PUCCH control channel.


Uplink Receiver – IRC

IRC for PRACH E-UTRAN must support IRC for uplink PRACH channel.


Uplink Receiver – MU-MIMO

Software support E-UTRAN must support multi-user MIMO 2×2 and 2×4 (two users using same PRBs).



IC for PUSCH 2-way

E-UTRAN must support IC with 2-way Rx diversity between two single user MIMO users operating in multi-user MIMO mode (two users using same PRBs).



IC for PUSCH 4-way

E-UTRAN must support IC with 4-way Rx diversity between two single-user MIMO users operating in multi-user MIMO mode (two users using same PRBs).


Downlink – MU-MIMO

Software support E-UTRAN must support multi-user MIMO 2×2, 4×2, and 4×4 (two users using same PRBs).


Uplink Receiver – CoMP

Joint Reception – 2-way Rx

E-UTRAN must support joint reception of uplink channels over at least two cells of the same eNodeB (two cells with 2Rx each). The vendor must specify the support for each uplink channel, i.e., PRACH, PUCCH, and PUSCH.


Uplink Receiver – CoMP

Joint Reception – 4-way Rx

E-UTRAN must support joint reception of uplink channels over at least two different cells of the same eNodeB (two cells with 4Rx each). The vendor must specify the support for each uplink channel, i.e., PRACH, PUCCH, and PUSCH.



Uplink scheduler –

PUCCH PUCCH capacity

E-UTRAN must support dynamic adjustment of PUCCH size (physical resources) according to bandwidth or number of users. eNodeB can dynamically increase/decrease the PUCCH control overhead depending on the number of users.


4-way Rx diversity

Software support

E-UTRAN must support 4-way Rx diversity reception for all uplink channels, i.e., 4-way Rx diversity must be supported for PRACH, PUCCH, and PUSCH. Uplink receiver implementation supported for 2-way Rx diversity such as IC or interference rejection combining must also be supported with 4-way Rx diversity. The vendor must specify the support for each uplink channel.


Six sectors Software support

E-UTRAN must support 6×1 and 6×2 higher-order sectorization configurations for 10, 15, and 20 MHz LTE channel bandwidth.


Uplink Power Control

PUCCH/PUSCH

E-UTRAN must support dynamic closed loop power control for PUCCH/PUSCH channels based on received PUCCH/PUSCH quality measurements and PUCCH/PUSCH quality targets.


Uplink Power Control

SRS

E-UTRAN must support dynamic closed loop power control for SRS reference signals based on received quality measurements and optimized quality targets.


Admission & Congestion

Control Triggers

E-UTRAN must support uplink and downlink admission and congestion control based on the following resources:

- average number of users in RRC connected mode

- average number of active users

- average PRB utilization - hardware consumption




Control

Cell level configuration

E-UTRAN must support activation of admission and congestion control triggers and actions at cell level.



Control

Access class barring

E-UTRAN must support the use of access class barring at cell level. The number of access classes in the access class group to be barred, as well as the duration of the barring for one given group, must be configurable. The access class group should be rotated to have uniform distribution of users barred.



Control Redirection to 3G

UTRAN must support the automatic redirection of LTE PS calls to 3G PS together with a mechanism to avoid fast reselection to LTE (e.g., using Rel'8 dedicated priorities).


Interference Flexible PUCCH configuration

E-UTRAN must support flexible PUCCH configuration to improve protection of the PUCCH signaling by adapting location of the PUCCH resources.


Extended CP Extended cyclic prefix operation

The eNB must support extended cyclic prefix for large cell support.


2.7.2 4G – Energy Efficiency

Energy_LTE_01 Energy Efficiency

MIMO Adaptation – ON/OFF DL MIMO

adaptation

Automatic deactivation of transmit branches to dynamically reconfigure the cell from high-order MIMO to SIMO configuration, based on operator-configurable time window and traffic thresholds.

Vendor must provide information and state compliancy to the following items:

- If feature allows SIMO operation (e.g., allows traffic operation in SIMO mode)

- If feature allows 2×2 to 1×2 and 4×2 to 2×2 reconfigurations

- If feature can be configured on a time window

- If feature can be configured with thresholds to take into account real time traffic (e.g., number of users, presence of carrier aggregation capable users, average PRB utilization)

- Feature must be implemented in the RAN (no OSS)

- If feature implies impact on coverage (and state how many dBs)

- Feature must be able to work in a coordinated way with centralized SON

- Cell availability counters must not be affected during MIMO switch off time. No cell lock/unlock is required


Power amplifier – Power amplifier dynamic voltage bias adaptation

Power amplifier bias voltage can be automatically adjusted to real-time RF load allocated to suit real-time traffic needs to improve MCPA efficiency. The feature should have no relevant impact on QoS and network KPIs and should work on all single-mode MCPA products.

Vendor must indicate information/compliancy to:

- Feature code(s) and name(s) that cover this requirement

- If it can be also activated during specific time periods

- Feature is implemented in the RAN domain


(no OSS/SON)

- If adaptation is performed dynamically (i.e., not only when there is no traffic)

- If adaptation occurs on multiple voltage levels (i.e., no static ON-OFF adaptation)

- Indicate hardware not supporting the feature

- Indicate if MaMIMO FDD HW supports feature


Power amplifier – PA shutdown during idle

PDSCH symbols

The PA is powered down if there is no data to transmit in PDSCH resource blocks. This intense PA de-activation has no impact on its lifetime or reliability for HW models supporting this feature. Feature should be supported on RRH, RFM, and AAS.


- If PA activation/deactivation can be performed at a symbol level. Otherwise, indicate minimum number of timeslots needed.

- If feature includes intelligent algorithm to rearrange PRBs to maximize the contiguous idle blocks and maximize savings (DRX-like, or reconfiguring idle frames to MBSFN frames)

- If feature can be also activated during specific time periods

- If feature works also on RF sharing/mixed-mode scenarios (GSM1800-LTE1800, UMTS2100-LTE2100)

- Indicate if feature works in RAN sharing (two operators in same RRU)

- Indicate if feature works with NB-IoT configured


- Indicate any special scheduling mode that could maximize feature use by maximizing the number of contiguous idle PRBs. State if this scheduling mode can affect MBB service and if it can be activated during specific time periods

- Indicate if the feature is supported in


MaMIMO FDD


Automatic layer deactivation –

LTE layer switch-off in

multi-layer sites

Automatic shutdown of LTE layers for multi-layer LTE sites (e.g., in a 2600MHz+1800MHz LTE site, LTE2600MHz is shut down during low traffic periods, leaving LTE1800MHz active). Traffic steering must be performed before switching off the LTE layer.


- The feature must be implemented in RAN (no OSS)

- If traffic steering is performed

- If carrier deactivation can be prevented for some terminal categories (e.g., Cat 6, or carrier aggregation-capable) or certain QoS classes are connected to the cells

- If carrier deactivation/reactivation can be triggered both by real-time traffic and time period

- If the feature is compatible with carrier aggregation

- State layer reactivation times

- The feature must be able to work in a coordinated way with centralized SON

- Standard cell availability counters must not be affected during switch-off time. A separate counter must come with the feature



Counters – Power

consumption counters

Energy-related counters must be made available on the OSS providing the following indicators:

- Power consumption (in W or kWh, every 15 min, specific to each LTE RRU/BBU/AAS, resolution < 10W)

- Energy efficiency (in kWh/MB, every 15 min, specific to each LTE RRU/AAS)

These counters should be available for the following equipment:

- RRU/AAS counters: there should be a counter per each technology band (e.g., LTE800, GSM-LTE1800, LTE1800, LTE2600)

- BBU counters: if no system module sharing, there should be a dedicated LTE counter. If system module sharing, there should be one counter per site, aggregating all site BBU consumption). There should be no legacy hardware restriction

The total base station power consumption must also be provided (sum of all RRUs and BBUs installed in a multi-technology site).

There should be no additional hardware required. If not the case, the vendor must state what product is needed as an enabler

Indicate hardware not supporting direct counters from the unit


Automatic layer deactivation – UL/GUL multi- RAT shutdown

In a SRAN node with LTE and 3G deployed, or LTE and 2G/3G, the SRAN node can automatically turn off a RAT depending on traffic load conditions and time period. The shutdown order of resources and related thresholds (traffic, time, other) are operator-configurable. Resources are automatically restored if operator thresholds are reached. Traffic steering is performed in the shutdown process.


- If resource deactivation can be triggered both by real-time traffic and time period

- If resource reactivation can be triggered both by real-time traffic (on other active RATs) and time period


- If terminal type or QoS is considered as a trigger for activation/deactivation (e.g., LTE-capable terminals)

- If traffic steering is performed

- If feature is implemented in RAN or in OSS/SON

- If feature requires additional hardware

- Standard cell availability counters must not be affected during RAT switch-off time. A separate counter must come with the feature


Baseband – Baseband shutdown

Baseband processors can be automatically shut down based on traffic load.


- If deactivation/reactivation can be automatically triggered by real-time traffic load

- If deactivation/reactivation can be automatically triggered by time period

- If traffic steering is supported in the deactivation process

- Deactivation/reactivation time (i.e., <1 min) Feature must work in the following scenarios. Indicate compliance/steps required:

a. Single cell b. Multiple cells c. Multiple dual mode (i.e., UMTS2100-

LTE2100)

- Feature must be implemented in RAN (no OSS)

- Feature must be able to work in a coordinated way with centralized SON

- Indicate which baseband HW units support feature


Power amplifier – Dynamic power

allocation

Power amplifier operation can be automatically adjusted in dual-mode scenarios (i.e., UMTS2100-LTE2100) to satisfy power demand based on real-time traffic. Part of total radio power will be shared between both technologies and dynamically adjusted in near


real-time.


- Timescale of power adjustment (i.e., 1 ms)


- Feature is implemented in RAN (no OSS/SON)


Power amplifier – Envelope

tracking PA

Power amplifier operation can be automatically adjusted in near real-time by means of tracking signal envelope to suit real-time traffic needs. Feature should have no relevant impact on QoS and network KPIs.


- Timescale of voltage bias adaptation (i.e., 1 ms)


- If feature also works on dual-MCPA scenarios (i.e., UMTS2100-LTE2100)

- Feature is implemented in RAN (no OSS/SON)


- Indicate if MaMIMO FDD supports the feature


RRU deep sleep – Enhanced RF deep sleep

RRU can be automatically shut down after switching off all carriers to allow higher energy savings.


- If deactivation/reactivation can be triggered also by time period

- Deactivation/reactivation time (i.e., <1 min)

- Feature must work also in dual-mode MCPA scenarios (i.e., UMTS2100-LTE2100)

- Feature must be implemented in RAN (no OSS)

- Feature must be able to work in coordinated way with centralized SON

- Indicate hardware not supporting the feature - Indicate which RRU parts/blocks can be


switched off

- Indicate if feature is supported in MaMIMO products, and which MaMIMO antenna parts can be switched off



Mobility_LTE_01 Mobility

Traffic steering – LTE->3G PS

handover based on coverage

PS handover from LTE to 3G must be supported. If LTE coverage has fallen below a predefined threshold as measured by the UE, the network must be able to command a handover to 3G if no other LTE layer is available.


Traffic steering – LTE->3G PS

handover based on load

PS handover from LTE to 3G must be supported. If LTE load (for all LTE layers) is higher than a threshold, the network must command a handover to 3G.


Load balancing – SPID support

The subscriber profile ID for RAT/frequency priority (SPID) parameter must be supported. The eNodeB must process the SPID and set dedicated priorities accordingly.


Traffic steering – PS handover/

redirection parameters

per QCI

Different inter-RAT mobility parameters per QCI


Traffic steering – PS handover/

redirection parameters

per QCI

Different inter-frequency mobility parameters per QCI


Load balancing – Inter-frequency load balancing

The eNB will support inter-frequency load balancing with up to three different LTE frequency bands to distribute the load evenly with measurements or with blind handover


The eNB will support inter-frequency load balancing with to/from LTE TDD bands to distribute the load evenly


The inter-frequency load balancing algorithms will be based on source and target load considering the DL RB usage


The inter-frequency load balancing algorithms will be based on source and target load considering the UL RB usage


The inter-frequency load balancing algorithms will be based on source and target load considering the PDCCH resource usage



The inter-frequency load balancing algorithms will be based on source and target load considering the DL/UL system efficiency of each RB due to DL /UL interference


The inter-frequency load balancing algorithms will be based on source and target load considering the average data waiting time in the scheduler


Traffic steering – LTE TDD<-> LTE FDD PS

handover based on coverage

PS handover from LTE TDD to LTE FDD (or vice versa) must be supported



handover based on load

PS handover from LTE TDD to LTE FDD (or vice versa) must be supported. If the LTE TDD load (for all LTE layers) is higher than a threshold, the network must command a handover to LTE FDD.



blind redirection based on coverage

PS redirection from LTE TDD to LTE FDD (or vice versa) must be supported. If the LTE TDD coverage has fallen below a predefined threshold as measured by the UE, the network must be able to command a release with redirection to LTE FDD if no other LTE TDD layer is available without LTE FDD measurements


Traffic steering – LTE TDD<-> LTE FDD PS redirection

based on coverage

PS redirection from LTE TDD to LTE FDD (or vice versa) must be supported. If LTE TDD coverage has fallen below a predefined threshold as measured by the UE, the network must be able to command a release with redirection to LTE FDD if no other LTE TDD layer is available with LTE FDD measurements


2.7.4 4G - Security

SEC_LTE_01 Security

User data and signaling data

integrity – Removal of null integrity option

The network must remove or permanently disable the null integrity option (EIA0) for non-emergency calls. The removal/disabling must be possible on previous LTE software releases. EIA0 is only allowed for unauthenticated emergency calls as specified in 3GPP TS 33.401 v9.7.0 subclause 5.1.4.2.

SEC_LTE_02 Security

User data and signaling data

integrity – Support of PDCP

encryption

The eNB must support PDCP ciphering and integrity protection for LTE air interface

2.7.5 4G – Quality of Service

QoS_LTE_01 QoS

QoS basic – GBR QCIs 2

Support for GBR QCIs 2 (example app: video call)

QoS_LTE_02 QoS


Support for GBR QCIs 3 (example app: streaming)

QoS_LTE_03 QoS


Support for GBR QCIs 4 (example app: real-time gaming)

QoS_LTE_04 QoS

QoS basic – Maximum bit rate DL QoS parameter

supported

eUTRAN must support throughput capping using MBR

QoS_LTE_05 QoS

QoS basic – Maximum

bit rate UL QoS parameter supported

eUTRAN must support throughput capping using MBR

QoS_LTE_06 QoS

QoS advanced – UL QoS

Mapping of the different QoS packets into different DSCP values in the operator-configurable uplink from QCI/ARP values

QoS_LTE_07 QoS

QoS advanced – Multiple non- GBR bearers

Support for at least two non-GBR QoS bearer types concurrently per UE, excluding default bearer

QoS_LTE_08 QoS

QoS advanced – Combination

Support for at least two non-GBR QoS bearers and at least one GBR QoS bearer concurrently


of non-GBR and GBR bearer

per UE, excluding the default bearer

QoS_LTE_09 QoS

QoS advanced – Multiple GBR

bearers UTRAN must support multiple GBR bearers per UE

QoS_LTE_10 QoS

QoS advanced – UE aggregated

maximum bit rate

UTRAN must support an aggregated maximum bit rate per UE for UL/DL

QoS_LTE_11 QoS

QoS advanced – MBR different

to GBR for GBR users

UTRAN must support to different value configuration for maximum bit rate (MBR) and for guaranteed bit rate (GBR) for GBR users to support good quality video VBR service. Release 10 CR: TS 23.203 CR 0427 Account for MBR > GBR bearers TS 23.401 CR 1588 Allow MBR > GBR TS 23.401 CR 1589 ECN grace period

QoS_LTE_12 QoS

QoS advanced – Packet delay budget

as input in the scheduler for GBR/non-GBR

UTRAN must consider packet delay budget QCI as input in the scheduler for GBR/non-GBR users

QoS_LTE_13 QoS

QoS advanced – eRAB modification

EPC initiated modification of UE-AMBR and other QoS parameters (ARP, THP) in RRC connected mode

QoS_LTE_14 QoS

QoS advanced – QoS differentiation:

UL

Support for operator-configurable (absolute or relative) eNB uplink scheduler, weights based on subscriber QoS classes mapped to a different QCI (e.g., gold, silver, bronze)

QoS_LTE_15 QoS


DL

Support for operator-configurable (absolute or relative) eNB downlink scheduler weight,s based on defined subscriber QoS classes mapped to a different QCI (e.g., gold, silver, bronze)

QoS_LTE_16 QoS


scheduler inputs

Support for operator-configurable eNB scheduler algorithm based on:

- Subscriber QoS classes (e.g., gold, silver, bronze) as defined above

- Non-GBR QCI parameters (priority, PDB, PER).

- UE-AMBR - MBR & GBR (vendor must explicitly indicate if

either parameter is not supported

QoS_LTE_17 QoS

QoS advanced – QoS differentiation

Support of a minimum CQI (radio conditions) to apply QoS differentiation for non-GBR to avoid


minimum conditions

resource starvation due only to a few number of users

QoS_LTE_18 QoS

QoS advanced – eNodeB DL nominal

bit rate based on QCI for non-GBR

bearer

The purpose is to have a minimum bit rate give to the non-GBR bearer when the congestion is very high, but with lower priority than the GBR

QoS_LTE_19 QoS

QoS advanced – eNodeB UL nominal

bit rate based on QCI for

non-GBR bearer

Purpose is to have a minimum bit rate given to non-GBR bearer when congestion is very high, but with lower priority than GBR

QoS_LTE_20 QoS

QoS advanced – Basic counters to

monitor subscriber QoS classes

(throughput) for non-GBR bearer

Required specific counters as part of basic QoS package to monitor throughput per each QoS class (i.e., per each QCI).


Sharing_LTE_01 Sharing

LTE MORAN – 2-way sharing

with one carrier per operator

over same band

The supplier must support eNodeB sharing between two operators using a dedicated LTE carrier per operator with its own PLMN-Id. No use of dummy PLMN-ID is preferred


LTE MORAN – 2-way: Two LTE

carriers (one per operator)

supported over the same PA,

RRU, AAS, with different

bandwidth

All vendor AAS/RRH and PA products must be able to be used in 2-way sharing scenario, permitting configuration of at least two LTE carriers (one per operator) within the IBW of the AAS/RRH/PA products.

Carriers of the two operators can have differing bandwidth (e.g., 10 MHz for the first operator, 15 MHz the second)


LTE MORAN – Shared BBU

across operators

It must be possible to provide MORAN using a single BBU element shared between operators


LTE MORAN – Shared BBU

expandability

Capacity increase path for the BBU: Additional BBU units can be added to the site, all of them being shared across the operators within a 2-way sharing scenario



LTE MORAN – Differentiation: Independent activation of features per

operator when using a shared

BBU

It must be possible to activate and independently configure LTE features on a per operator basis. The supplier must provide the list of all features within the roadmap (up to the next two years) that cannot be activated and independently configured per operator


LTE MORAN – Option of using a dedicated BBU

per operator

It must be possible to support 2-way sharing using a separate BBU per operator. This should allow (e.g.) to provide the maximum level of feature activation/differentiation per operator


LTE MORAN – 2-way multi-

band with shared BBU

It must be possible to support multi-band LTE in a 2-way sharing scenario with a single shared BBU or with multiple shared BBUs. Multi-band LTE means each operator can have dedicated LTE carriers in more than one band


LTE MORAN – 2-way: LTE

carrier aggregation

supported via MORAN

It must be possible to activate carrier aggregation between LTE carriers of each operator


LTE MORAN – 3-way sharing

with one carrier per operator

over same band

The supplier must support eNodeB sharing between three operators using a dedicated LTE carrier having its own PLMN-Id per operator


LTE MORAN – 3-way: Three

LTE carriers (one per operator)

supported over same PA, RRU,

AAS

All vendor AAS/RRH and PA products must be able to be used in a 3-way sharing scenario, permitting configuration of three LTE carriers (one per operator) within their IBW. Carriers of the three operators can have different bandwidths.


LTE MORAN – 3-way: LTE

carrier aggregation

supported via MORAN

If multi-band LTE sites in MORAN, it must be possible to activate carrier aggregation between LTE carriers of each operator.


LTE MORAN – MORAN with independent

QoS per

The eNB must support independent QoS parameter settings for each operator.


operator


LTE MORAN – eNodeB capacity

partitioning: dedicated capacity

It must be possible to hard-partition eNB capacity to guarantee a minimum resource level on a per operator basis.


LTE MORAN – eNodeB capacity

partitioning: soft capacity split

The eNB must allow overbooking of the hard-partitioned capacity to permit instantaneous support of e.g. due to variable throughput from a non-GBR bearer.


LTE MOCN – MOCN basic

Spectrum sharing must be supported to up to four operators, sending multiple PLMN-Ids


LTE MOCN – MOCN with independent

QoS per operator

The eNB must support independent QoS parameter settings for each operator so as to avoid QoS settings of one operator always implying higher packet priority vs another operator. This can be achieved by being able to map the QoS setting of each operator into a new QoS table that manages all packets (similar to solutions used for the QoS over the IuB in 3G).


LTE MOCN – eNodeB capacity

partitioning: dedicated capacity

It must be possible to hard-partition eNB capacity to guarantee a minimum resource level on a per-operator basis.


LTE MOCN – eNodeB capacity

partitioning: soft capacity split

The eNB must allow overbooking of the hard-partitioned capacity to allow instantaneous support of e.g. due to variable throughput from a non-GBR bearer.


LTE MORAN & MOCN at same time – Support

of MOCN & MORAN within same Node B

and same band

The eNodeB must be able to support a 2-way sharing scenario with two LTE carriers over the same band, one being configured for use by one operator only (similar to a MORAN case), and a second being used in MOCN by two operators. Intra-band CA over these two carriers must be possible.


LTE MORAN & MOCN at same time – Support

of MOCN & MORAN within

A single eNodeB must be able to support a 2-way sharing scenario in which one band is shared with a dedicated carrier per operator (MORAN), and the other with a shared carrier across multiple operators (MOCN). Carrier aggregation must be possible so


same Node B over different

bands, with CA support

each operator can aggregate in CA the dedicated carrier and the shared one. It must be possible to activate CA at the same time for both operators, and the number of BBUs needed must be equal or less than 2.


LTE transport – Minimum of 8

VLANs in 2-way sharing and 11

in 3-way sharing

It must be possible to support a minimum of eight per operator), + another for O&M, + another for other usage), and 11 in a 3-way case. Each defined VLAN must support different CoS (802.1p) .


LTE transport – number of IPsec tunnels: Min 6

IPsecs

At least six different IPsec tunnels must be supported by the LTE eNodeBs


LTE security – Supports

connectivity to at least three

security gateways

Each eNodeB must support connectivity to at least (and up to) three security gateways


LTE security – Multi-PKI

certificates BBUs must support up to three PKI certificates


LTE & 2G 1800 sharing –

Sharing 1800 in 2G and LTE

It must be possible to share the same RRU/AAS/PA in 1800 in LTE (MORAN or MOCN) and GSM, so that part of the IBW is dedicated to 2G sharing and another to LTE sharing


LTE operability – LTE

performance management

The eNB must generate independent call performance statistics for each shared operator.


LTE operability – LTE:

Independent write rights on

own cells

Each operator must be able to independently access, read, and configure the parameters of its own cells (when dedicated), w/o having any visibility of other operators’ cells unless the accessing user is also master user of the OSS system that manages the shared eNodes.


LTE Baseband – Baseband expansion

It must be possible to expand the BBU of the shared 2G/3G or LTE nodes, adding additional BBUs and maintaining the same logical Node B towars the BSC/RNC, core network nodes, and OSS system. Highlight the maximum number of BBUs that can be connected with respect to this requirement.



Smartphones_LTE_01 Smartphones

RRC-Connected to RRC-Idle

dormancy timer granularity

eNodeB RRC-Connected to RRC-Idle “dormancy timer' with the following range and granularity:

Range: 100ms – 5,000,000ms

Granularity: 100ms

Default: 10 seconds (10,000ms)

A setting of 0 disables the dormancy timer


DRX – Long DRX

cycle length support

Operator-configurable long DRX cycle with full range as specified in 3GPP


DRX – Short DRX

cycle length support

Operator configurable short DRX cycle with full range as specified in 3GPP


Smart DRX – Different DRX

per QCI

eNodeB must be able to configure different DRX settings to different QCIs profiles.

Operator must be able to configure all 3GPP-defined DRX parameters with full range:

- Operator-configurable DRX inactivity timer per QCI

- Operator-configurable long DRX cycle time per QCI

- Operator-configurable short DRX cycle time per QCI

- Operator-configurable on-duration timer per QCI

- Operator-configurable retransmission timer per QCI

- Operator-configurable SR-pending Timer per QCI

2.7.8 4G – LTE Downlink Speed

Speed_LTE_01 Speed - DL

Scheduler – Proportional fair

scheduler DL

As a tradeoff between channel-dependent scheduling leading to higher cell throughput and fairness among users in their resource allocations, proportional fair scheduler in DL is required to allocate more resources to a user with relatively better channel quality, thereby offering high cell throughput and satisfactory fairness.


Scheduler – DL frequency

selective scheduling

The scheduler should exploit radio channel variations (e.g., fading, interference) and select the most optimal subcarrier(s) in any given time domain (frequency diversity gain).

Speed_LTE_03 Scheduler – The eNB must support cross-carrier scheduling when


Speed - DL Cross-carrier scheduling

carrier aggregation is implemented in the node.


MIMO – 2×2: Closed loop

spatial multiplexing

2×2

E-UTRAN must support MIMO 2×2, where the eNodeB selects the precoder matrix indicator(s) based on feedback from the UE.


MIMO – Automatic switching

between spatial multiplexing &

Tx diversity

E-UTRAN must support (when and where radio conditions dictate) the ability to interchange between transmission modes 2, 3, and 4.


MIMO – 4×2: open loop


E-UTRAN must support MIMO 4×2, where the eNB selects the precoder matrix indicator(s) (PMI).


MIMO – 4x2: closed loop




MIMO – 4×4: open loop


E-UTRAN must support MIMO 4×4, where the eNB selects the precoder matrix indicator(s) (PMI).


MIMO – 4×4: closed loop spatial multiplexing



Prescheduling – Basic support

On/Off

E-UTRAN must support prescheduling of resources to UEs (access grants), even if not required.


Prescheduling – Based upon

load

E-UTRAN must support prescheduling of resources to UEs (access grants), even if not required, which can be activated if certain load thresholds are reached.


Prescheduling – Based upon QoS, others

E-UTRAN must support prescheduling of resources to UEs (access grants), even if not required, which can be activated depending upon QoS parameters.


Carrier aggregation (intra-band)

using contiguous

E-UTRAN must support carrier aggregation (CA) and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using up to 30MHz of spectrum in the 1800MHz band.


spectrum – Band, Carrier: 1800, 30Mhz



using contiguous spectrum –

Band, Carrier: 1800, 40Mhz

E-UTRAN must support CA and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using up to 40MHz of spectrum in the 1800MHz band.




Band, Carrier: 2600, 30Mhz





Band, carrier: 2600, 40Mhz



Carrier aggregation (multi-band)


Bands, carrier size: 800+900,

10+5

E-UTRAN must support CA and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using 10MHz of spectrum from the 800 MHz frequency band and 5 MHz of spectrum from the 900MHz band.





20+10

E-UTRAN must support CA— across two operators —and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using 20MHz of spectrum from the 800 MHz frequency band and 10 MHz of spectrum from the 900MHz band.






10+10

E-UTRAN must support CA and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using 10MHz of spectrum from the 800 MHz frequency band and 10 MHz of spectrum from the 1800MHz band.





20+20

E-UTRAN must support CA—across two operators —and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using 20MHz of spectrum from the 800 MHz frequency band and 20MHz of spectrum from the 1800MHz band.




Bands, carrier size: 800+2600:

10+20

E-UTRAN must support CA and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using 10MHz of spectrum from the 800 MHz frequency band and 20MHz of spectrum from the 2600MHz band.





20+40

E-UTRAN must support CA— across two operators —and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using 20MHz of spectrum from the 800 MHz frequency band and 40MHz of spectrum from the 2600MHz band.





5+10







10+20






5+20





Bands, Carrier Size: 900+2600:

10+40

E-UTRAN must support CA— across two operators —and the combination of two or more LTE channels to form a common aggregated resource, over which a UE can be served using 10MHz of spectrum from the 900 MHz frequency band and 40MHz of spectrum from the 2600MHz band




Bands, Carrier Size:

1800+2600: 10+20





Bands, Carrier Size:

1800+2600: 20+40



2.7.9 4G – LTE Uplink Speed

Speed_LTE_29 Speed - UL

Coordinated multi-point (CoMP) – Intra eNB PUSCH

joint reception – 2-way Rx

eNB must support CoMP in the uplink, i.e., the coordinated processing of UE uplink signals from two or more sectors under the same eNB—thereby increasing cell edge throughput—using a 2-way Rx diversity antenna configuration.


Coordinated multi-point (CoMP) – Intra eNB PUSCH

joint reception – 4-way Rx

eNB must support CoMP in the uplink, i.e., the coordinated processing of UE uplink signals from two or more sectors under the same eNB—thereby increasing cell edge throughput—using a 4-way Rx diversity antenna configuration.


Coordinated multi-point (CoMP) – Inter eNB PUSCH

joint reception – 2-way Rx Div

eNB must support CoMP in the uplink, i.e., the coordinated processing of UE uplink signals from two or more sectors under more than one eNB—thereby increasing cell edge throughput—using a 2-way Rx diversity antenna configuration.


Coordinated multi-point (CoMP) – Inter eNB PUSCH

joint reception – 4-way Rx Div

eNB must support CoMP in the uplink, i.e., the coordinated processing of UE uplink signals from two or more sectors under more than one eNB—thereby increasing cell edge throughput—using a 4-way Rx diversity antenna configuration.


Scheduler – UL frequency

selective scheduling

The scheduler should exploit radio channel variations (e.g., fading, interference) and select the most optimal subcarrier(s) in the time domain (frequency diversity gain).


Interference rejection

combining

Suppression of interference from other cells to improve performance throughout the cell (particularly in medium to bad radio conditions) and cell capacity.


High order modulation –

64QAM support

(Cat 5 – 75

Support of 64QAM in the UL—Category 5 terminals—will permit maximum uplink throughput of 75Mbps in a SIMO UE.


Mbps)

2.7.10 4G – LTE Total Comms

TotalComms_LTE_01 Total Comms

VoLTE Voice over LTE (VoLTE) – QCI 1


VoLTE – Video over LTE

Video over LTE (ViLTE) – QCI 2


VoLTE – VoLTE RB

combinations

SRB1 and SRB2 for DCCH + (up to) 5× AM DRB + (up to) 2× UM DRB


VoLTE – VoLTE RB

combinations

All RB combinations defined in TS 36.523-1 and support the maximum number of DRB (8).


VoLTE – TTI bundling

for voice TTI bundling for voice.


VoLTE – VoLTE uplink segmentation

Support of VoLTE uplink segmentation packets to improve the UL coverage for VoLTE calls


VoLTE – VoLTE frequency

hopping

Support of quick change in frequencies used in uplink to improve the coverage of VoLTE calls


VoLTE – RoHC

Robust header compression


VoLTE – MBR different

to GBR

MBR different to GBR supported in eNodeB for VTLTE


VoLTE – Semi-persistent

scheduling

eNB must support semi-persistent scheduling to reduce control channel overhead when persistent radio resource allocations are needed (as in VoIP)


CS Fallback – Basic CSFB

CS fallback (CSFB) – basic w/o SIBs


CS Fallback – CSFB with RIM

CSFB – w/ 2G SIBs via RIM


CS Fallback – CSFB with PS

handover CSFB – PS handover to 3G



CS Fallback – CSFB with

equivalent TA/LA

CSFB – using equivalent TA/LA information to choose the best target cell


CS fallback – CSFB with

measurements CSFB with 3G measurements from UE



measurements CSFB with 2G measurements from UE



measurements

CSFB with 3G measurements and blind HO/redirection upon configurable timer expiration


CS fallback – Fast return to LTE

eNB must support fast return to LTE once the voice call has ended in 2G/3G


Mobility – PS handover LTE non-GBR to 3G

non-GBR

PS handover from LTE non-GBR QCI to UTRAN HSPA interactive background


Mobility – PS handover LTE non-GBR from 3G

non-GBR

PS handover from UTRAN HSPA interactive background to LTE non-GBR QCI


Mobility – PS handover parameters

per QCI

Different inter-RAT mobility parameters per QCI


Mobility – PS handover parameters

per QCI

Different inter-frequency mobility parameters per QCI


Mobility – SRVCC from

LTE to 2G

SRVCC from LTE QCI 1 to GERAN (with and w/o DTM)


Mobility – SRVCC from

LTE to 3G

SRVCC from LTE QCI 1 to UTRAN CS (with and w/o PS HO support)


VoLTE Mobility – Different A3

per QCI

The eNB will permit different A3 threshold per QCI or per service


VoLTE Mobility – Successful

handover when

If a handover to a cell where a PCI conflict has been detected, then the eNB will ask the UE to read the CGI (cell-id) before doing the handover


PCI conflict detection

so that a call drop is avoided.


VoLTE Mobility – Force CSFB at call setup

To avoid the blocking call during the pre-alerting phase in poor LTE radio conditions, it’s better to force the CSFB. When the VoLTE call is set up, the eNB based on LTE coverage provides a failure to the MME—forcing the UE to retry the call with a CSFB.

UE is considered in poor LTE coverage, e.g., based on LTE signaling strength and/or SINR


VoLTE Mobility – PS handover LTE TDD GBR to LTE

FDD GBR and vice versa

PS handover from LTE TDD GBR QCI to LTE FDD GBR (or vice versa)


Call reestablishment –

Call reestablishment

intra-site

Configurable per QCI, and fully configurable parametrization




inter-site

Configurable per QCI, and fully configurable parametrization




triggers

Describe all procedures/timers/algorithms that triggers the call reestablishment procedure in eNodeB

2.7.11 4G – Transmission LTE

TX_LTE_01 Transmission

eNodeB interfaces –

Ethernet interfaces

Minimum number of electrical/optical Ethernet interface: 4 × 10/100 fast Ethernet or 2 Gigabit Ethernet ports.

The vendor will provide the maximum number of ports supported.


IP addressing

All of the option should be configurable remotely.

- All traffic carried over the same IP address - OAM traffic carried over one IP address and the

remainder of traffic carried over another address

- OAM traffic carried over one IP address, signaling


traffic carried over another address and user traffic over yet another IP address


VLAN

The eNB must support the operator-configurable use of up to 8 VLANs compliant to IEEE802.1Q. Each defined VLAN must support different CoS (802.1p) to distinguish between different traffic types and ensure E2E QoS through the IP/MPLS network on any Ethernet interfaces:

- 1 VLAN per radio technology (2G/3G/4G). If X2 is unencrypted, it could be useful to be able to map S1 and X2 on different VLANs.

- 1 VLAN for O&M (providing it’s feasible to have a common VLAN for management of 2G/3G/4G)

- 1 VLAN for authentication/access control (802.1x over LAN/EAP-TLS)

- 1 VLAN for autoconfiguration (DHCP)


IP QoS mapping –

IP VLAN QoS handling

The eNB must be able to flexibly map traffic onto one or more VLANs. At a minimum the eNB must support the mapping of all X2 traffic on one configurable VLAN and the core facing destined on another. It must also be possible to separately map the X2, S1_U, S1_MME, and OAM traffic onto different VLANs (any of these may/may not have IPsec protection).


IP QoS mapping – IP DSCP QoS

handling

The eNB must be able to flexibly map traffic onto one or more DSCP layer 3 values


Synchronization – IP

synchronization IEEE1588V2

The eNodeB will support IEEE1588v2 version G.8265.1 (UDP/IP unicast)


Synchronization – IP

Synchronization with synchronous

Ethernet

The eNodeB will support synchronous Ethernet


Synchronization – Synchronization

resiliency

The eNB must support a synchronization priority scheme, whereby the network operator must be able to freely assign a priority to each possible synchronization source, and the eNB must recover timing from the highest-priority available source


meeting the required quality targets.

In the event of failure of the active clock source, the eNB must recover synchronization from the next highest-priority source.


Hubbing – Synchronous

Ethernet generation at eNodeB for

Ethernet switching

The eNB will support the delivery of SyncE to the next base station connected through the hubbing feature.


Link aggregation – Link

aggregation in the eNodeB

The Node B must allow one or more links to be aggregated to form a link aggregation group, such that a MAC client can treat the group as if it were a single link (from IEEE Standard 802.3).


Load sharing – Load sharing for different Ethernet

boards

In case of different physical paths (Ethernet interfaces) for any interface, the eNodeB will balance traffic according to the number of allocated users on each path; the vendor must explain the criteria regarding how the system balances the connections.


IPsec

IPsec without any capacity degradation of the eNodeB

The mechanism follows IPsec RFC ( 4301 al 4309). IPsec must be able to be activated per each IP address.

- Encryp/decrypt must not introduce significant latency into traffic path (<1ms)

- Configuration will be performed remotely

- IPsec must be operator-configurable and support AES encryption algorithm (NIS FIPS-197) and key lengths variants.

- IPsec must support independent tunnel use or transport mode for any IPsec instance

- IPsec must support independent use of AH and/or ESP, or both for any IPsec instance

- Ech IPsec must support the use of IKEv2 to mutually agree keying data with its IPsec peer.

- eNodeB must support up to two IPsec tunnels.


IPsec – OCSP

The product must support OCSP for authenticating received certificates; at least one unique OCSP session must be supported per PKI instance.

TX_LTE_14 IPsec – Certificate Management Protocol (CMPv2). It’s


Transmission CMPv2 specified by 3GPP to maintain X.509 certificates. It must be able to communicate with the operator CA.


IPsec – Certificate revocation

When digital certificates are used there must be a means to allow the issuing CA to revoke any certificate on an ad-hoc basis


IPsec – Multi-mode BS common IPsec (LTE TDD and

FDD)

Multi-mode BS common IPsec (LTE TDD and FDD)


IPsec – IPsec tunnel

reinitialization

If the discarded IPSec packet rate on eNodeB exceeds a certain limit (a configurable parameter), then eNodeB should automatically reinitialize the IPSec tunnel toward the same destination


IPsec – IPsec tunnel

reinitialization

If IPsec reinitialization fails (after n times, a configurable parameter), eNodeB must reinitialize the IPsec tunnel to a different SecGW. Since the inner IP remains unchanged, the IPsec payload reaches the MME without problems via the new SecGW.


IPv6 – IPv6 at transport

layer HW IPv6 hardware readiness offered by the equipment.


IPv6 – Dual stack IPv4

and IPv6 at transport layer

The eNodeB must support simultaneous IPv4 & IPv6 dual stack on the transport interfaces


Ethernet OAM

Any Ethernet ports must support:

- Maintenance association end point (MEP) on a per VLAN basis.

- Loopback reply message (LBR) function toward its peer MEP(s) in response to both unicast and multicast loopback request message (LBMs).

- Generating continuity check messages (CCMs). Receiving AIS messages.

- The appropriate alarms for loss of continuity.

- Turning off sending of CCMs, while keeping the associated MEP active


MTU at S1, X2 – Support of MTU

higher than 2000 bytes

The MTU size of the S1 and X2 interfaces must be higher than 2000 bytes



MME pooling – MME pooling up to 32 MME

MME pooling up to 32 MME


Resiliency – Single RAN

independence resiliency

If the other RATs (2G or 3G) fails, the eNodeB will be running without interruption in the data received and transmitted and the synchronization will continue without service outage.


Single RAN aggregation – Aggregation of different RATs

traffic

The eNodeB must be able to aggregate traffic from LTE and also from 2G and/or 3G. The bandwidth is dynamically allocated to the arriving calls independent on the technology. Every technology can use up to the full amount of bandwidth. QoS differentiation between traffic flows must be configurable by the operator, with mapping between QoS parameters (QCI, TC, ARP, THP, MBR, GBR) and type of PS call: (GPRS, R99, HSPA, LTE) to the used transport layer (ATM classes of services or IP DSCP, 802.1Q).


eNodeB auto-configuration –

eNodeB Authentication

An authentication/access control process is mandatory to guarantee that only authorized equipment can access to the transport network. Only when the process is successful can the eNB get the IP configuration data and start to communicate with other LTE network elements (MME, S/P-GW, etc.

eNBs will have to support the following for authentication/access control to the network:

- EAP over LAN/IEEE802.1x supplicant role with certificate support (candidate is EAP-TLS as it supports mutual authentication) will be mandatory to perform authentication and access control to the network.

- If subsequent authentication request fails (e.g., in case of RADIUS failure), service could prevail in the refresh process wrt security (configurable). Note: Even if EAP is negotiated at VLAN level then, at the end of the authentication process, the entire Ethernet port must be granted/denied depending on authentication process result.

- One dedicated VLAN needs to be supported at Node B side for the authentication process


eNodeB auto-configuration – IP addressing at

eNBs will have to support a client for dynamic configuration to bring the disparate IP addresses (MME@, SAE-GW@, default GW@ etc. or possibly


autoconfiguration list of addresses ordered by priority).

DHCP client is the preferred option (over a VLAN) for eNB auto-configuration support.


2.7.12 4G – SON LTE

SON_LTE_01 Distributed SON

Primary cell ID (PCI)

optimization

Optimize physical cell identification to reduce risk of having a UE simultaneously receive signals from two or more cells having the same cell ID.


ANR – Intra-frequency

Automatically optimize intra-frequency neighbor relations of existing cells


ANR – Inter-frequency

Automatically optimize inter-frequency neighbor relations of existing cells


ANR – Inter-RAT

Automatically optimize inter-RAT (e.g., 2G/3G/LTE) neighbor relations


Plug n Play

Plug n Play must support automation of new base station installation, commissioning, and operation. It includes automatic radio network configuration data handling, and self-configuration of new base station. It must also support creation of neighbor relation lists for new sites when they’re introduced in the network.


MLB – Intra Frequency

MLB identifies loaded cells and modifies cell footprint (e.g., power and mobility parameters) to balance traffic across different sites in the same frequency.


MLB – Inter Frequency

MLB balances the traffic across different frequencies in the same overlapping coverage area.


MRO – Mobility robustness

optimization

Automatically optimize handover parameters to minimize “too early,” “too late,” and “wrong cell” handovers.


RACH Optimization

2.8 Remote Radio Head (RRH)

2.8.1 RRH 700 Frequency Division Duplexing (FDD)

RRH700FDD SRAN-RRH-700-01

Band supported by

700 RRUs

An RRU must support operation in band 28 (3GPP TS 37.104)


Technology supported by

700 RRUs

The technology supported by any RRU in band 28 (3GPP TS 37.104) must be LTE.



Operating bandwidth of

700 RRUs

45MHz must be the total operating bandwidth (the frequency distance from lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be supported by any RRU working in band 28.


Instantaneous bandwidth of

700 RRUs

45MHz must be the total Instantaneous bandwidth (the frequency distance from the lower edge of lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be simultaneously supported in reception (instantaneous bandwidth reception with RX diversity (IBW RX)) and in transmission (power amplifier instantaneous bandwidth transmission (PA IBW TX)) by any RRU working in band 28.


Output power of 700 RRUs

2×40W must be the minimum output power provided by any RRU operative in band 28.

Effective downlink power must be limited by parameters, if necessary.

A minimum +/- 1 dB accuracy over temperature range and frequency band must be achieved.











2.8.2 RRH 850FDD


Band supported by

850 RRUs

An RRU must support operation in the full MSR band 5 (3GPP TS 37.104)



850 RRUs

Any RRU in the full MSR band 5 (3GPP TS 37.104) must support activation of any combination of W-CDMA, GSM, and LTE.




850 RRUs

25MHz must be the total operating bandwidth (the frequency distance from the lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be supported by any RRU working in MSR band 5 (3GPP TS 37.104).



850 RRUs

25MHz must be the total instantaneous bandwidth (the frequency distance from the lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be simultaneously supported in reception (instantaneous bandwidth reception with RX diversity (IBW RX) and in transmission (power amplifier instantaneous bandwidth transmission (PA IBW TX)) by any RRU working in MSR band 5 (3GPP TS 37.104).


Independent adjustment of the IBW in 850

RRUs

The total instantaneous bandwidth in transmission (PA IBW TX) and in reception (IBW RX with RX diversity) must be possible to be independently tuned in each power amplifier or pair of receivers available in an RRU.

This is applicable only to GSM and W-CDMA technologies (MIMO is not necessary).


1st output power

configuration of 850 RRUs

2×40W must be the minimum output power provided by any RRU operating in band 5.




1st output power






1st output power







2nd output power


In addition to the 2×40W model, vendor must provide an RRU operating in band 5 with an effective downlink power of 2×60W at antenna connectors.




Output power requirement

for GSM and 2×40W

Any RRU with a power configuration of 2×40W in GSM must ensure a total GMSK output power of all carrier in a sum that must be greater than or equal to 80W.



Output power requirement

for EDGE and 2×40W

Any RRU with a power configuration of 2×40W in GSM must ensure a total 8PSK output power of all carriers in a sum that must be greater than or equal to 55W, if all carriers transmit in 8PSK.



Output Power requirement for GSM and

2x80W




Output Power requirement for EDGE and

2x80W



2.8.3 RRH AWSFDD

RRHAWSFDD SRAN-RRH-AWS-01

Band supported by

AWS RRUs

An RRU must support operation in the band 4 (3GPP TS 37.104)



AWS RRUs

The technology supported by any RRU in the band 4 (3GPP TS 37.104) must be LTE.




AWS RRUs




AWS RRUs

45MHz must be the total instantaneous bandwidth (the frequency distance from the lower edge of lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be simultaneously supported in reception (instantaneous bandwidth reception with RX diversity (IBW RX)) and in transmission (power amplifier instantaneous bandwidth transmission (PA IBW TX)) by any RRU working in band 4.


Output power of AWS RRUs














2.8.4 RRH PCSFDD

RRHPCSFDD SRAN-RRH-PCS-01

Band supported by

PCS RRUs




PCS RRUs





PCS RRUs




PCS RRUs



Output power of PCS RRUs














2.8.5 RRH 800FDD


Band supported by

800 RRUs




800 RRUs





800 RRUs




800 RRUs




2×40W must be the minimum output power provided by any RRU operative in band 20:













2.8.6 RRH 900FDD


Band supported by

900 RRUs

An RRU must support operation in the full MSR band 8 (3GPP TS 37.104)



900 RRUs

Any RRU in the full MSR band 8 (3GPP TS 37.104) must support the activation of any combination of W-CDMA, GSM, and LTE.




900 RRUs

35MHz must be the total operating bandwidth (the frequency distance from the lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be supported by any RRU working in MSR band 8 (3GPP TS 37.104).



900 RRUs

35MHz must be the total instantaneous bandwidth (the frequency distance from the lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be simultaneously supported in reception (instantaneous bandwidth reception with RX diversity (IBW RX)) and in transmission (power amplifier instantaneous bandwidth transmission (PA IBW TX)) by any RRU working in MSR band 8 (3GPP TS 37.104).


Independent adjustment

of the IBW in 900 RRUs

The total Instantaneous bandwidth in transmission (PA IBW TX) and in reception (IBW RX with RX diversity) must be possible to be independently tuned in each power amplifier or pair of receivers available in the RRU.

This is applicable only to GSM and W-CDMA technologies (MIMO is not necessary).


1st output power






1st output power






1st output power







2nd output power


In addition to the 2×40W model, vendor must provide an RRU operative in band 8 with an effective downlink power of 2×60W at antenna connectors.




Output power requirement for GSM and

2×40W




Output power requirement for EDGE and

2×40W

Any RU with a power configuration of 2×40W in GSM must ensure a total 8PSK output power of all carriers in a sum that must be greater than or equal to 55W, if all carriers transmit in 8PSK.




2×80W

Any RRU with a power configuration of 2×80W in GSM must ensure a total GMSK output power of all carriers in a sum that must be greater than or equal to 160W.




2x80W



2.8.7 RRH 1800FDD


Band supported by

1800 RRU

An RRU must support operation in the full MSR band 3 (3GPP TS 37.104).



1800 RRU

Any RRU in the full MSR band 3 (3GPP TS 37.104) must support the activation of any combination of LTE and GSM.



75MHz must be the total operating bandwidth (the frequency distance from the lower edge of the lowest


1800 RRU frequency to the upper edge of the highest frequency) over which two or more carriers may be supported by any RRU working in band 3 (3GPP TS 37.104).



1800 RRU



Independent adjustment

of the IBW in 1800 RRU

The total instantaneous bandwidth in transmission (PA IBW TX) and in reception (IBW RX with RX diversity) must be possible to be independently tuned in each power amplifier or pair of receivers available in the RRU.

This is applicable only to GSM technology (MIMO is not necessary).


1st output power






1st output power


The minimum output power provided by any RRU operative in band 3 must be: 2×20W.




1st Output power






2nd Output power


In addition to the 2x40W model, the vendor must provide an RRU operating in band 3 with an effective downlink power of 2×80W at antenna connectors.


A minimum +/- 1 dB accuracy over temperature


range and frequency band must be achieved.


3nd Output power


In addition to the 2×40W model, the vendor must provide an RRU operating in band 3 with an effective downlink power of 4×40W at antenna connectors.





2x40W



RRH1800FDD SRAN-RRH-1800- 12


2x40W





2x80W





2x80W




Receiver diversity

Options for 1800 RRUs

Any RRU operating in MSR band 3 (3GPP TS 37.104) must support four-way receiver diversity in the uplink.


2.8.8 RRH 2100FDD


Band supported by

2100 RRU

An RRU must support operation in the full MSR band 1 (3GPP TS 37.104).



2100 RRU

Any RRU in the full MSR band 1 (3GPP TS 37.104) must support the activation of any combination of W-CDMA and LTE.



2100 RRU

60MHz must be the total operating bandwidth (the frequency distance from the lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be supported by any RRU working in band 1.



2100 RRU



Independent adjustment of

the IBW in 2100 RRU

The total instantaneous bandwidth in transmission (PA IBW TX) and in reception (IBW RX with RX diversity) must be possible to be tuned independently in each power amplifier or pair of receivers available in the RRU.

This is applicable only to W-CDMA technology, i.e. MIMO is not necessary.


Output power of 2100 RRU
















2nd Output power of 2100

RRU





3nd Output power






Receiver diversity

options for 2100 RRUs

Any RRU operating in band 1 (3GPP TS 37.104) must support four-way receiver diversity in the uplink.

2.8.9 RRH 2300TDD

RRH2300TDD SRAN-RRH-2300-01

Band supported by

2300 RRU

An RRU must support operation in band 40 (3GPP TS 37.104).



2300 RRU

LTE TDD must be supported by any RRU in band 40 (3GPP TS 37.104).



2300 RRU





2300 RRU

The total instantaneous bandwidth (the frequency distance from the lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be simultaneously supported in reception, instantaneous bandwidth reception with RX diversity (IBW RX), and in transmission, power amplifier instantaneous bandwidth transmission (PA IBW TX), by any RRU working in band 40 must be tunable across all band 40 and the minimum supported value must be 100 MHz.


1st Output power






1st Output power






1st Output power






2nd Output power






Receiver diversity




2.8.10 RRH 2600FDD

RRH2600FDD SRAN-RRH-2600_FDD-01

Band supported by

2600 FDD RRU

Any RRU must support operation in band 7 (3GPP TS 37.104).



2600 FDD RRU

LTE technology must be supported by any RRU in band 7 (3GPP TS 37.104).



2600 FDD RRU




2600 FDD RRU

The total instantaneous bandwidth (the frequency distance from the lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be simultaneously supported in reception, instantaneous bandwidth reception with RX diversity (IBW RX), and in transmission, power amplifier instantaneous bandwidth transmission (PA IBW TX), by any RRU working in band 7 must be tunable across all band 7 and the minimum value supported must be: 70MHz.


1st Output power

configuration of 2600 FDD

RRUs





1st Output power


RRUs





1st Output power


RRUs






2nd Output power






Receiver diversity



RRH2600TDD SRAN-RRH-2600_TDD-01

Band supported by

2600 TDD RRU

An RRU must support operation in the band 38 (3GPP TS 37.104).



2600 TDD RRU

LTE TDD technology must be supported by any RRU in the band 38 (3GPP TS 37.104).



2600 TDD RRU




2600 TDD RRU

The total instantaneous bandwidth (the frequency distance from the lower edge of the lowest frequency to the upper edge of the highest frequency) over which two or more carriers may be simultaneously supported in reception, instantaneous bandwidth reception with RX diversity (IBW RX), and in transmission, power amplifier instantaneous bandwidth transmission (PA IBW TX), by any RRU working in band 38 must be tunable across all band 38 and the minimum value supported must be: 40MHz.


Output power configuration of 2600 TDD

RRUs





Receiver diversity




2.8.11 RRH Weight

RRHWeight SRAN-RRH-COM-01

Weight of single-band RRU 2×40W

All single-band 2×40W RRUs, independent of the frequency band, must weigh less than 10Kg.

RRHWeight SRAN-RRH-COM-02

Weight of single-band RRU 2×80W

All single-band 2×80W RRUs, independent of the frequency band, must weigh less than 15Kg.

2.8.12 RRH Volume

RRHVolume SRAN-RRH-COM-03

Volume of single-band RRU 2×40W

The volume of all single-band RRUs, independent of the frequency band, must be less than 10L (including connectors and sun shield).

RRHVolume SRAN-RRH-COM-04

Volume of single-band RRU 2×80W

The volume of all single-band RRUs, independent of the frequency band, must be less than 15L (including connectors and sun shield).

2.8.13 RRH Power Efficiency

RRHPowerEff SRAN-RRH-COM-07

Power efficiency of RRU

(single-band, multiband & wideband)

All RRU power efficiencies should reach a minimum of 36% for single-band or multiband products and 33% for wideband products having a GA date in Q2 2016 considered as a reference scenario:

- RRU working at a maximum output power

- RRU working at a maximum (100%) load

- Power efficiency (%) = output power at the antenna connector (watts)/DC power supplied to the RRU (watts)

- The target also applies to combined mode configurations involving any mix of technologies


Power efficiency

evolution of RRUs (single

band)

The vendor must commit to reach a minimum RRU power efficiency of 40% for products GA by June 2018.

- If the vendor isn’t fulfilling the previously mentioned yearly requirements for RRU power efficiency, then it must commit to an efficiency increase by at least a 6% per year until the requirement is fulfilled.



Power efficiency roadmap

evolution of RRUs

The vendor must commit to an efficiency increase of at least 6% per year. If the vendor cannot make this commitment, they must describe those efficiency roadmap improvements that it can be achieve.

2.8.14 RRH Stack

RRHStack SRAN-RRH-COM-10

Stackable RRU

The vendor must offer a mechanical mounting arrangement for RRH products that allow a minimum of six units to be physically installed, such that their visible appearance is that of a single physical unit.

The vendor must clearly describe the mounting arrangement, specifically showing how the installation space and complexity have been simplified as much as possible. Any frequency band combinations must be possible.

2.8.15 RRH Environmental

RRHEnvironmental SRAN-RRH-COM-11

RRU sun shielingd

Extra RRU sun shielding must permit the unit to support operation at an environment temperature of up to a minimum of +55ºC (including solar radiations at 1120 W/m2). Such additional protection is targeted for very specific hot environments.


Wind resistance

RRU design must be optimized to reduce the wind load; wind speed operability up to 200km/h.


Environmental capabilities

RRU must comply with outdoor capabilities from ETSI EN 300 019-1-3


Lightning protection

RRU equipment must fulfil lightning protection-related requirements from IEC 61312-1


Environmental tests

RRU equipment must fulfil humidity, shocks, and vibration-related requirements per ETSI 300 019-2-4 class T4.1E


Acoustic noise All RRU products must be silent in operation; i.e. convection-cooled (no fans).


2.8.16 RRH Physical

RRHPhysical SRAN-RRH-COM-17

Attenuation mechanism

The vendor must state if the Node B/RRU provides any means for input attenuation adjustment and consequent compensation of feeder loss. If so, vendor must state the steps and range of attenuation and the implementation.


Multiple RRU as a single cell

Repeater mode—the use of RRUs as repeaters (receiving transmitting the same logical cells) must be supported to permit deployment scenarios (e.g., railway tunnel coverage with multiple transmission points radiating and receiving the same signal).


RF connectors All RRUs must use RF type 4.3-10 female connectors.


RET support All RRUs must support remote electrical tilt (RET) through the 3GPP-compliant RET solution (minimum AISG v2.0)


RET connector

All RRH products must provide direct support of antenna RET—i.e., direct connection from the RRU to the antenna tilt servos, with no independent connection from the BBU. There should be a specific RET port, it being an AISG 8-pin female connector IEC 60130-9 (minimum AISG 2.0 compliant).

2.8.17 RRH MIMO

RRHMIMO SRAN-RRH-COM-22

RRH MIMO 4×2 support

All radios equipped with 4T4R configuration must support MIMO 4×4.

The vendor must indicate every hardware product supporting MIMO 4×2 and the corresponding software release.

RRHMIMO SRAN-RRH-COM-23

RRH MIMO 4×4 support

All radios equipped with 4T4R configuration must support MIMO 4×4.

The vendor must indicate every hardware product supporting MIMO 4×4 and the corresponding software release.


2.8.18 Common Regulatory

Common Regulatory HW-REG-01

Product Safety: Verification test certification, certification related to CE marking, etc.

The vendor must explicitly state compliance to the following product requirements required for all radio access products supplied to an operator. The vendor must also provide documentary evidence to support the compliance statements. This must be in the form of verification test certification, certification related to CE marking, RoHS etc. or other documents proving compliance and which may be audited by the operator if requested.

The following is a non-exhaustive list of compliance which must be provided by the vendor:

* Electrical safety surge/Lightning protection electromagnetic compatibility (EMC)

* Radio frequency interference (RFI)

* Environmental operating conditions

* Classification of protection of equipment enclosures (IP rating)

* CE marking (all applicable directives)

* Ventilation & cooling * Materials

* WEEE directive * Sharp edges

* RoHS directive * Structural

* Earthing * Acoustic noise

* Electrostatic protection

* Security and accessibility

* Flammability and fire retardancy

* Emissions of harmful gases

* Warning signage and labelling


Base Station System (BSS) equipment specification

All RRUs and active antenna radios must be compliant to the Essential Conformance and Complete Conformance test requirements for MCBTS as specified in 3GPP TS 51.021_Rel 14


Standard radio (MSR) base station (BS)

electromagnetic compatibility

(EMC)

The vendor must be compliant to the EMC compatibility as specified in 3GPP TS 37.113_ Rel 14



Multi-standard radio (MSR) base station

(BS) – Conformance

testing

All RRUs and active antenna system products must be compliant to Band Category 1 (BC1) or Band Category 2 (BC2) (see 3GPP TS 37.141 ). A manufacturer declaration of regional and optional requirements must be provided for each RRU and active antenna system product compliant to 3GPP TS 37.141_Rel 14


E-UTRA and UTRA carriers of different bandwidths

When operating in single-RAT mode, the RRU and active antenna system products must support E-UTRA and UTRA carriers of different bandwidths, e.g., an MSR base station must be able to simultaneously activate a UTRA carrier of 4.8MHz and another carrier of 5MHz.

The product must be compliant to single-RAT requirements specified in 3GPP TS 37.141 subclause 5.


LTE: RF transmission

and reception performance requirements

All LTE NR RRU and active antenna radios must be compliant with 3GPP wide-area BS RF transmission and reception performance requirements.

The RRU and active antenna radios when used together with the 19" BBU must meet these performance requirements defined by 3GPP.

Any performance requirement not met by the product must be declared.

Reference: TS 36.104_Release 14


LTE: spectrum emission mask

All LTE NR RRU and active antenna radios must be compliant with the spectrum emission mask as defined in 3GPP TS 36.104 for the single carrier mode.

For the multi-carrier mode when operating at maximum RF output power per carrier.

The vendor must be compliant to 3GPP TS 36.104_ Rel 14


LTE: receiver sensitivity

All LTE RRU products must be compliant with receiver sensitivity per branch as defined by 3GPP TS 36.104 (note that this also corresponds to the receiver sensitivity achieved by the BBU and active antenna combination).

The vendor must be compliant to 3GPP TS 36.104_ Rel 14



Wide-area BS RF transmission and reception performance requirements

All RRU and active antenna radios in MSR mode must be compliant with 3GPP wide-area BS RF transmission and reception performance requirements.

The RRU and active antenna radios when used together with the 19" BBU must meet these performance requirements defined by 3GPP.

Any performance requirement not met by the product must be declared.

Reference: TS 37.104_Release 14


Spectrum emission mask

All RRU and active antenna radios in MSR mode must be compliant with the spectrum emission mask as defined in 3GPP TS 37.104 for the single carrier mode.


Reference: TS 37.104 Release 14


Receiver Sensitivity – All RRU and

active antenna

Radios in MSR mode must be compliant with receiver sensitivity per branch as defined by 3GPP TS 37.104 (note that this also corresponds to the receiver sensitivity achieved by the BBU and active antenna combination).

Reference: TS 37.104 Release 14


W-CDMA – Wide-area BS

RF transmission and reception performance requirements

All W-CDMA RRU and active antenna radios must be compliant with 3GPP wide-area BS RF transmission and reception performance requirements.

The RRU and active antenna radios when used together with the 19" BBU must meet these performance requirements defined by 3GPP. Any performance requirement not met by the product must be declared.

Reference: TS 25.104 Release 7 (March 2008).

The active antenna when used together with the BBU must meet these performance requirements defined by 3GPP. Any performance requirement not met by the product must be declared.


W-CDMA: spectrum

emission mask

All W-CDMA RRU and active antenna radios must be compliant with the spectrum emission mask as defined in 3GPP TS 25.104 for the single carrier mode.




BS RF transmission

and reception performance requirements

All single-RAN products, including GSM when used together with the 19" BBU, must meet all performance requirements defined by 3GPP 45.005 and 25.104 and TS51.021 for all modes of operation.

Any performance requirement not met by the product must be stated.

2.9 BBU

2.9.1 Baseband Unit Architecture

BBUArchitecture—BBU-ARCH-01

Software-defined

baseband hardware

architecture

The BBU must support a software-defined hardware architecture. This must provide a common hardware platform that is configured by software to support GSM, W-CDMA, and LTE operation.

Configuration of the hardware must be by remote software download or by a local maintenance terminal on site.


Modular Hardware

Architecture

It’s permissible to support the hardware architecture with either a single hardware element, or two modular hardware elements consisting of a universal control processor hardware module and a universal baseband capacity hardware module.

Note: The principle requirement for modularity is to permit the configuration of BBU hardware to most efficiently serve base station configurations of varying capacity in addition to supporting one or more access technologies.


19" Indoor mounting rack

BBU

The vendor must provide BBU common hardware indoor elements, which must be housed in a 19" rack mount magazine assembly.


Outdoor mounting rack

BBU

An outdoor mounting version of the BBU common hardware elements must be offered.


Common plug-in modules: Indoor &

outdoor BBUs

Indoor and outdoor mounting versions of the BBU must use common hardware plug-in modules.


Pooling of downlink resources between boards

If the vendor offers a BBU that is configured by means of plug-in boards or submodules, then the BBU must support the pooling of downlink resources between boards, thereby permitting load balance control between the boards.

The vendor must confirm all necessary software features


required to support resource pooling across multiple physical baseband hardware elements are also available.


Pooling of uplink

resources between boards

If the vendor offers a BBU that is configured by means of plug-in boards or submodules, then the BBU must support the pooling of uplink resources between boards, thereby permitting load balance control between the boards.

The vendor must confirm all necessary software features required to support resource pooling across multiple physical baseband hardware elements are also available.


Pooling of carrier cell resources

If the vendor offers a BBU that is configured by means of plug-in boards or submodules, then the BBU must support the pooling of carrier cell resources (e.g., multiple boards must pool resources to support dual carrier or multi-carrier RF configurations.


Clock timing reference signal to

ensure stable phase

synchronization (1/2)

For the purposes of e.g. TDD operation in LTE, or other services such as eICIC, eMBMS, etc., the BBU must accept a clock timing reference signal to ensure stable phase synchronization from the following sources:

- From an external GPS based source

- From an optional (but integrated) GPS receiver system

- From an IP transport-derived IEEE 1588v2 timing signal


Clock timing reference signal to

ensure stable phase

synchronization (2/2)

To accelerate the synchronization lock and improve holdover when the 1588 source is temporarily lost or exhibits bad quality, the BBU must accept a clock timing reference signal from the following source:

SYNC-E protocol support (ITU-T Rec. G.8261/62/64).

2.9.2 BBU Physical

BBUPhysical— BBU-PHY-01

Temperature controlled

environment and MTBF

The BBU must support operation in a temperature-controlled environment, where the temperature set point is +35ºC.

Operation at this temperature must be possible without any degradation of the BBU MTBF (mean time between failure) that must be > 300.000 hr


BBUPhysical— BBU-PHY-02

Maximum temperature supported

Any BBU (indoor and outdoor model) product must operate at -20ºC to +55°C without suffering any severe degradation in MTBF performance.

Severe degradation must be considered as greater than 5% deterioration in MTBF performance when compared to operation at +35ºC.

2.9.3 BBU Multi-RAT

BBUMultiRAT— BBU-MRAT-01

Support GSM & W-CDMA & LTE FDD support in the same BBU

As an option for site configurations of limited capacity (but that requires the simultaneous use of GSM and W-CDMA or GSM and W-CDMA and LTE technologies), a single BBU magazine may support the simultaneous use of those multiple technologies with a minimum hardware configuration.


Frequency band agnostic BBU

operation

The BBU must support agnostic 3GPP 2G/3G/4G frequency band operation, i.e., there must be no limitations— other than processing capacity or physical connectivity limitations—imposed on BBU configuration to support either single or multi-frequency band operation.


Simultaneous multi-

technology operation

The BBU must support simultaneous multi technology operation independently of the frequency band or bands in operation.


2G/3G/4G multi-RAT

combination support

A single BBU magazine must be capable of being configured to support the following multiple access technology combinations:

- GSM and W-CDMA operation in the 900MHz frequency band (3GPP band 8)

- GSM, W-CDMA, and LTE FDD operation in the 900MHz frequency band (3GPP band 8)

- GSM and LTE FDD operation in the 1800MHz frequency band (3GPP band 3)

- W-CDMA and LTE FDD operation in the 900 and 2100MHz frequency band (3GPP bands 1 and 8)

- LTE TDD operation simultaneously with any combination of GSM, W-CDMA, or LTE FDD operation

NOTE: The vendor must indicate which BBU product from the portfolio can support every above combination and possible limitations for every product.



LTE FDD and LTE TDD support

The BBU must support both LTE FDD and LTE TDD operation. This must be achieved with the common hardware platform. Configuration must be by remote or local software download.


Simultaneous LTE FDD and LTE

TDD support

It must be possible to configure a single BBU magazine to simultaneously support LTE FDD and LTE TDD operation.


Simultaneous FDD and TDD mode support

The BBU magazine may be configured with multiple instances of the common hardware modules to achieve the traffic- or processing-capacity needed to support FDD and TDD RATs.


Simultaneous LTE TDD and

any other RAT in FDD support

A single BBU magazine must be capable of being configured to simultaneously support LTE TDD operation with any two FDD access technologies.

For example: simultaneous operation of LTE TDD with LTE FDD and GSM FDD or LTE TDD with LTE FDD and W-CDMA FDD.


Dynamic resource

pooling across technologies –

Single BBU

The baseband architecture must support dynamic resource pooling across technologies (LTE, W-CDMA, and GSM) in multi-technology configurations.

These capabilities must be clearly described by the vendor for every BBU product, understanding that this could be a single baseband module or a combination of specific plug-in boards inserted into a single baseband module.

NOTE: The vendor must explicitly state all limitations (if any) and restrictions on resource pooling in a cascaded configuration.

2.9.4 BBU Software

BBUSoftware— BBU-SW-01

Modular software

architecture support

Independent software modules must be provided for GSM, W-CDMA. LTE-FDD, LTE-TDD, and LTE-TDD operation.


Coordinated load of

software module support

It must be possible to assemble individual software modules into a single package for delivery, test, and deployment within an operational network. The combinations of software anticipated and rules related to the allowable delta between software releases are included in subsequent individual requirements.


Emergency software

The BBU must permit the loading of patches and emergency software corrections on a per-technology


basis.


Single-RAT software module

The BBU must permit the load of single technology software modules.


Single RAT software

module and no service outage for other RAT in same BBU

If the BBU magazine has been configured with dedicated common hardware modules for each supported technology, then the remote load of a single technology software module must not impact the other technology or technologies—i.e., there must be no service outage for the technologies not impacted by the software update.


Support of incremental

software load releases per

each RAT

The BBU must support an n±1 software load for each of the GSM, W-CDMA, and LTE technologies, where n is the reference technology release and ±1 is one incremental software release (either backward or forward).

The maximum number of incremental steps supported between all software loads must be two.


Software module must

be common to any type of radio (AAS, RRH, etc.)

connected to BBU

BBU software modules supporting GSM, W-CDMA, and LTE operation must be independent of radio hardware platforms connected to the BBU—i.e., each software module must be common to RRH, active antenna, and cabinet-based radio configurations. This must include both macro and all forms of small cell hardware.

2.9.5 BBU Rec Diversity

BBURecDiversity—BBU-RD-01

IC for W-CDMA

For W-CDMA, the BBU must not impose any restrictions on the ability to perform IC techniques for all applicable base station configurations. This must apply to both control and data channels.


IC for LTE

For LTE, the BBU must not impose any restrictions on the ability to perform IC techniques for all applicable base station configurations. This must apply to both control and data channels.

This requirement is applicable to multi-user MIMO (but not applicable to SU-MIMO).



IRC for W-CDMA

For W-CDMA, the BBU must not impose any restrictions on the ability to perform IRC techniques for all applicable station configurations. This must apply to both control and data channels.


No BBU restrictions

for IC support

Explicitly for IC techniques, the BBU must not impose any restrictions on the ability to cancel the interference signals under the following conditions:

- The case where the interferers to be cancelled are demodulated but not decoded

- The case where the interferers to be cancelled are demodulated and decoded.

NOTE: The vendor must explicitly state compliance or non-compliance to this requirement.


No BBU restrictions for

IC and IRC support

For both IC and IRC techniques, the vendor must state any restrictions that may be imposed if both 2-way and 4-way receiver diversity configurations are applied.

The following conditions must be explicitly stated:

- Multi User MIMO IC 2-way for LTE

- Multi User MIMO IC 4-way for LTE

- IC 2-way for W-CDMA

- IC 4-way for W-CDMA

- IRC 2-way for LTE and W-CDMA

- IRC 4-way for LTE and W-CDMA

2.9.6 BBU Connectivity

BBUConnectivity—BBU-CON-01

CPRI spec for fronthaul interface

As a minimum, the BBU must support the CPRI interface specification version V6.0 (2013-08-30), supporting LTE Advanced


Minimum no. of CPRI ports

The basic BBU hardware configuration must support a minimum of 6× 10G CPRI interface ports for the connection of RRHs or active antenna systems.


Expansion capability for

the number of interface (CPRI)

ports

The basic BBU hardware configuration must support an expansion capability for the number of interface (CPRI) ports provided.

Two stages of expansion must be provided:

- Stage one expands the basic capability to 12 ports

- Stage two expands the basic capability to 18 ports



Enhanced CPRI

The BBU must support the so-called enhanced CPRI interface. This might be the one under specification in CPRI Forum (http://www.cpri.info/press.html) or any other proprietary vendor solution aiming to provide:

New eCPRI standard makes sense only if allowing same performance as CPRI (not compromising on spectral efficiency) providing much lower AAU-BBU link rate demand.

The following minimum performance must be:

*2× 10Gbps eCPRI interfaces must support: 3×M-MIMO antenna cells* × 20 MHz Carrier

Notes:

- 64T64R M-MIMO antenna (16 DL/ 8 UL MIMO streams in MU-MIMO mode)

- Enhanced CPRI could imply to move processing of Layer 1 low from BBU RF protocol stack to antenna protocol stack


Minimum no. of eCPRI ports

The basic BBU hardware configuration must support a minimum of 6 × 10G eCPRI interface ports or 2×25G eCPRI interface ports for the connection of RRHs or active antenna systems.


Optical transceivers to support CPRI and enhanced

CPRI

Small form-factor-pluggable (SFP) must be by default an optical interface to support eCPRI and CPRI.

Eventually, Quad SFP (QSFP) or QSFP+ to support CPRI could be acceptable.


Multiplexing of more than one

access technology onto

a single CPRI/eCPRI port

The BBU must support the multiplexing of more than one access technology onto a single CPRI or enhanced CPRI (proprietary or standard interface) port and associated fiber connection.

This requirement target is a better support of massive MIMO with both eCPRI and CPRI options depending on available carrier BW, frequency band, and RAT.


Multiplexing of three access technologies onto a single CPRI port and

associated fiber

The BBU must support the multiplexing of three access technologies onto a single CPRI port and associated fiber connection (GSM, W-CDMA, and LTE).



Flexible and configurable

backhaul transmission

physical interface

The BBU must support a flexible and configurable transmission physical interface. The following options must be supported as a minimum:

- A minimum of 2x 1G Ethernet electrical connection ports

- A minimum of 2x 1/10G Ethernet optical connection ports


Flexible and configurable transmission

physical interface: Fast and Gigabit

Ethernet

The BBU must support a flexible and configurable transmission physical interface. The following must be supported as a minimum:

The electrical and optical transmission interface must be configurable to support the following interface standards:

- Fast Ethernet (100 Mbps)

- Gigabit Ethernet (1Gbps)


Flexible and configurable transmission

physical interface – IP format


The electrical and optical transmission interface ports must be configurable to support all IP transmission formats for GSM, W-CDMA, and LTE.


IP transmission interface

supporting GSM+W-

CDMA+ LTE

The BBU must support a flexible and configurable transmission physical interface. The following must be supported as a minimum;1. Co transmission of GSM, W-CDMA and LTE on a single transmission interface port when configured for All IP operation.


BBU supporting Abis for GSM,

Iub for W-CDMA and X2 and S1 for LTE


- The electrical and optical transmission interface ports must be configurable to support an Abis interface for GSM.

- The electrical and optical transmission interface ports must be configurable to support an Iub interface for W-CDMA.

- The electrical and optical transmission interface ports must be configurable to support X2 and S1 interfaces for LTE.

It must be possible to mix the configurations of individual transmission interface ports.



Configurable IPv4 for all IP

interfaces

The BBU must be configurable to support IPv4 for all IP interfaces.

Configuration of IPv4 on all related baseband hardware must only be by software update.


Allow the physical

interconnection of multiple BBU

magazines

The BBU must permit interconnection of multiple BBU magazines. This interconnection must be physically achieved using standard optical or electrical Ethernet-based connectors.


Transport backhaul Security

IPsec must be supported to provide security on top of the Ethernet backhaul connection.

2.9.7 BBU Capacity

BBUCapacity— BBU-CAP-01

BBU hardware architecture must

not impose a capacity bottleneck

The vendor must clearly describe how all requirements related to BBU hardware configuration (e.g., capacity dimensioning, modularity, connectivity parameters) can be achieved to ensure that the air interface is always the limiting factor.


Radio hardware configuration supported by

single BBU magazine

A single BBU magazine or entity must support a minimum of six sectors.

Each sector may contain one, two, or three physical antennas supporting the following radio hardware configurations:

800MHz (3GPP B20) - 2T2R

900MHz (3GPP B8) - 2T2R

1800MHz (3GPP B3) - 4T4R

2100MHz (3GPP B1) - 4T4R

2300MHz (3GPP B40) - 4T/4R

2600MHz (3GPP B7 and B38 and B41) – 4T4R, 4T/4R


BBU impact of antenna uplink and downlink configurations

In all BBU capacity requirements, the vendor must consider the impact of antenna uplink and downlink configurations. The following must be assumed:

- A GSM carrier is configured as 1T2R

- A W-CDMA carrier is configured as 1T2R

- Optionally a W-CDMA carrier may be configured as 2T2R configuration

- Optionally a W-CDMA carrier may be configured as 1T4R configuration


- An LTE carrier is configured as 2T2R TDD/FDD

- An LTE carrier is configured as 2T4R TDD/FDD

- An LTE carrier is configured as 4T4R in both TDD/FDD

BBUCapacity—BBU-CAP-04

2-way and 4-way Rx diversity

support

The BBU must provide sufficient processing capacity such that both 2-way and 4-way Rx diversity (dependent on RF unit capability) can be supported by all RF units connected to the BBU.

RF unit refers to any combination of:

- remote radio heads

- active antenna systems

- macro cabinet plug-in units


Capacity configuration #0

– Min. no. of carriers in 2G/3G/4G operation

A single BBU magazine must support the following minimum number of discrete carriers:

GSM = Twelve (12) TRX per site

W-CDMA = Three cells per site

LTE = Three carriers per site

BBUCapacity—B BU-CAP-06



A single BBU magazine must support the following minimum number of discrete carriers:

GSM = 18 TRX per site

W-CDMA = 18 cells per site

LTE = 12 carriers per site




It must be possible to configure the following high capacity site options:

GSM = 36 TRX per site

W-CDMA = 24 cells per site

LTE = 24 carriers per site

When the BBU(s) are configured for multi-technology operation at the site, it must be possible to dimension sufficient hardware to simultaneously support the above carrier capacities for each technology.



– Min. no. of users in

2G/3G/4G operation

BBU configuration #0 (BBU-CAP-05, above) must support the following minimum number of users per site:

GSM = 30 W-CDMA = 64 LTE = 64

"user" is defined as the following for each technology:

* GSM = voice circuit switched half- or quad-rate connection

* W-CDMA = connected user with HSPA RAB (HSDPA+HSUPA)


* LTE user = an RRC-connected user



– min. no. of users in

2G/3G/4G operation

BBU configuration #1 (BU-CAP-06, above) must support the following minimum number of users per site:

GSM = 300 W-CDMA = 500 LTE = 1000







– min. no. of users in

2G/3G/4G operation

BBU configuration #2 (BU-CAP-07, above) must support the following minimum number of users per site:

GSM = 750 W-CDMA = 1000 LTE = 2500






Maximum number of

W-CDMA users

The vendor must state the maximum number of W-CDMA users that may be simultaneously scheduled per cell by a single BBU.

If the base station composition (e.g., the number of carriers, sectors, and the antenna UL/DL configuration) affects the maximum number of users that the BBU can schedule per cell, then the vendor must state all such limitations and rules that must be applied to BBU hardware dimensioning.


Maximum no. of LTE users

The vendor must state the maximum number of LTE users that may be simultaneously scheduled per cell by a single BBU.

If the base station composition (e.g., the number of carriers, sectors, and the antenna UL/DL configuration) affects the maximum number of users that the BBU can schedule per cell, then the vendor must state all such limitations and rules that must be applied to BBU hardware dimensioning.


Maximum W-CDMA user

plane data throughputs for configurations

#1 and #2

For W-CDMA, the BBU must support the following maximum user plane data throughputs per cell for the Capacity Configuration#1 and Capacity Configuration#2 described above:

Configuration#1 DL: 200Mbps UL: 40Mbps




Maximum LTE user plane data throughputs for Configurations

#1 and #2

For LTE, the BBU must support the following maximum user plane data throughputs per cell for the Capacity Configuration#1 and Capacity Configuration#2 described above:



Configuration#1 must assume one 20MHz LTE carrier.

Configuration#2 must assume two 20MHz LTE carriers.


Maximum W-CDMA and LTE user plane

data throughputs plus GSM

capacity support

The vendor must state the maximum user plane data throughputs (Mbps) plus number of GSM TRX supported per cell by a single BBU product configured to support GSM, W-CDMA, and LTE traffic.

2.9.8 BBU Future Proof

BBUFutureProof—BBU-FP-01

BBU support of CA for LTE

carriers (FFD and/or TDD) in

CA mode

The BBU hardware must not impose any limitation either in the same BBU or in separated BBUs on the configuration of LTE carriers, and for either FDD or TDD, to operate in CA mode.

Any such limitations be imposed by the vendor these must be clearly stated.


Future proof: Minimum of five

(5) years

The BBU must be designed to support all relevant features and functionality planned by the vendor and in its roadmap for a minimum of five (5) years from the general availability date of the BBU hardware elements.


Five-year (min) forward

compatibility and two-year (min)

backward compatibility

The BBU must support all software modifications and have forward compatibility for a minimum period of five (5) years, and backward compatibility for a minimum period of two (2) years.


BBU design optimized to

ensure longest in-service life

The vendor must describe in detail the key hardware architecture blocks and the processor technology or technologies that have been employed to implement its baseband design, with specific attention to describe how the design has been optimized to ensure the longest possible in-service life for the baseband platform. It must also ensure its design is flexible, programmable, and that power efficiency has been optimized.


NOTE: It’s acceptable to refer to a document describing technology choices to ensure longest in-service life

2.10 BSC & RNC

2.10.1 SRAN Controller Hardware

SRAN-Controller-HW-001

Pooling of user plane hardware

This requirement applies to any hardware or processor within a hardware board that handles user plane traffic.


Pooling of hardware

handling control plane (including

NB control)

This requirement applies to the control plane, and therefore to all processors that handle RRC signaling, NBAP signaling, as well as RANAP/RNSAP signaling.

Resources handling all the aforementioned signaling must be in pool within the RNC machine, e.g., hardware resources handling RANAP signaling processing must be in pool with those handling RRC signaling.


Pooling of hardware common channels

processing resources

This requirement applies to common channels messages processing. All RNC hardware for this purpose must be in pool, or at least there must be a means to avoid overload in one of the processors while the remainder have free processing capacity.


Pooling/load balancing of

hardware handling external

transport interfaces: IP

This requirement applies to all IP interfaces used to interconnect with Node Bs, core network, and other RNCs.

There must be a means to avoid overload in one of the IP boards while the others have free processing capacity.


Flexible dimensioning

for control and user planes

It must be possible to independently dimension control and user planes so RNC dimensioning can be optimized to the actual traffic mix.

The RNC must permit capacity increase dedicated to the control plane w/o the need to purchase additional hardware/licensing for the user plane, and vice versa.


Same hardware card software-definable for CP/UP: either

control plane or user plane

The same hardware must be used to handle control and user planes; it must be possible to configure via software (i.e., without a physical visit to the RNC site).



Adaptive CP/UP resource

configuration based on

historical data

The RNC must be able to reconfigure the tasks assignment of its processor (e.g., the capacity dedicated to the control plane and that dedicated to the user plane)—based on historical data of the observed traffic mix—within the limits of the installed and licensed hardware types.


Manual adaptive CP/UP resource configuration by operator

It must be possible to select between automatic reconfiguration (w/o OSS intervention) and that suggested by the RNC through the OSS (the latter requiring explicit operator intervention).


The RNC will support n+1 redundancy mode for control plane and user plane processing boards.

2.10.2 SRAN Controller RNC Capacity

SRAN-Controller-RNCcapacity-001

Number of Node Bs

An RNC configuration that is able to support at least 1200 NodeBs


Number of cells An RNC configuration that is able to support at least 2700 Cells


RNC minimum capacity

requirement

An RNC configuration that is able to support at least 3.5 Gbps and 600.000 simultaneous RRC connections for the S40 traffic profile


Max Iu throughput for

S90 traffic profile

Provide the maximum Iu throughput with the biggest possible configuration taking into account the S90 traffic profile


Max Iu throughput for

S40 traffic profile

Provide the maximum Iu throughput with the biggest possible configuration taking into account the S40 traffic profile


Max number of supported PCH

users

Provide the maximum number of simultaneous users with an RRC connection opened per RNC configuration


Min. no. of processed RRC

connections

The RNC must support a minimum processing of 5000 RRC connections request per second


Avg. Iub Mpbs/KW for medium load and medium configuration


Avg. Iub Mpbs/m3 for medium load


and medium configuration

2.10.3 SRAN Controller RNCBSC

SRAN-Controller-RNCBSC-001

The controller platform will be ready to support both BSC and RNC.


Operation modes BSC only, RNC only. Each subrack should be able to work in the three available modes: RNC, BSC, RNC+BSC


2G/3G functionality

software upgrade at

subrack level – same hardware

Upgrade from BSC to RNC, from RNC to BSC, from BSC to RNC/BSC, and from RNC to RNC/BSC must be made only by software. No hardware upgrade is to be needed apart from extra cards to reassess capacity


Controller must support an n±1

software load for GSM, W-CDMA

technologies

Where n is the reference technology release and ±1 is one incremental software release, either backward or forward.

The maximum number of incremental steps supported between all software loads must be two.

2.10.4 SRAN Controller Overload

SRAN-Controller-Overload-001

Respecting QoS priorities in

discarding user plane packets

User plane packets of connections/users having a lower QoS profile will get lower priority/higher discard rate compared to those connections/users having a higher priority.

SRAN-Controller-Overload-002

Respecting QoS priorities in discarding

control plane packets

When signaling message handling is the cause of overload, higher priority will be given to messages of users having higher QoS profile.

2.10.5 SRAN Controller Performance

SRAN-Controller-Performance-001

Latency introduced by the RNC must not be higher than 2ms in the user plane with a channel fully allocated.

SRAN-Controller-Performance-002

Latency introduced by the BSC must not be higher than 2ms in the user plane with a channel fully allocated.


2.10.6 SRAN-Controller BSC Capacity

SRAN-Controller-BSCcapacity-001

Number of BTS A BSC configuration exists that is able to support at least 1500 BTSs.


Number of cells

BSC configuration exists that is able to support at least 4000 cells.


Max EDGE throughput

Provide the maximum EDGE throughput with the biggest possible configuration


Max TRX supported

BSC configuration exists that is able to support at least 8000 TRXs.


Max external neighboring cells support of 64000 cells.


Max supported Erlangs

Provide the maximum Erlangs with the biggest possible configuration.


Average Erlangs/KW for medium load


Average Erlangs/m3 for medium load


No. of E1s supported

Provide the maximum number of E1 with the biggest possible configuration


No. of STM-1 supported

Provide the maximum number of STM1 with the biggest possible configuration.


Max. no. of GE ports

supported

Provide the maximum number of GE with the biggest possible configuration.


SGC BSC must support physical and logical redundancy in an interface over IP.

TIP OpenRAN OpenRAN Technical Requirements v0.1 October … · 2021. 4. 15. · OpenRAN –...

Documents

Transcript of TIP OpenRAN OpenRAN Technical Requirements v0.1 October … · 2021. 4. 15. · OpenRAN –...