2012-04-03 Multi-Mobile Network Operator In-Building LTE Remote Radio Head Technical Requirements

Multi-Mobile Network Operator In-Building LTE Remote Radio Head Technical Requirements
Version 1.00 3 April 2012
Hotel Technology Next Generation 3 April 2012

About HTNG
Multi-Mobile Network Operator In-Building LTE Remote Radio Head Technical Requirements Version 1.00
Hotel Technology Next Generation (HTNG) is a non-profit association with a mission to foster, through collaboration and partnership, the development of next-generation systems and solutions that will enable hoteliers and their technology vendors to do business globally in the 21st century; to be recognized as a leading voice of the global hotel community, articulating the technology requirements of hotel companies of all sizes to the vendor community; and to facilitate the development of technology models for hospitality that will foster innovation, improve the guest experience, increase the effectiveness and efficiency of hotels, and create a healthy ecosystem of technology suppliers. Copyright 2012, Hotel Technology Next Generation All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. For any software code contained within this specification, permission is hereby granted, free-of-charge, to any person obtaining a copy of this specification (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the above copyright notice and this permission notice being included in all copies or substantial portions of the Software. Manufacturers and software providers shall not claim compliance with portions of the requirements of any HTNG specification or standard, and shall not use the HTNG name or the name of the specification or standard in any statements about their respective product(s) unless the product(s) is (are) certified as compliant to the specification or standard. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Permission is granted for implementers to use the names, labels, etc. contained within the specification. The intent of publication of the specification is to encourage implementations of the specification. This specification has not been verified for avoidance of possible third-party proprietary rights. In implementing this specification, usual procedures to ensure the respect of possible third-party intellectual property rights should be followed. The names Hotel Technology Next Generation and HTNG, and logos depicting these names, are trademarks of Hotel Technology Next Generation. Permission is granted for implementers to use the aforementioned names in technical documentation for the purpose of acknowledging the copyright and including the notice required above. All other use of the aforementioned names and logos requires the permission of Hotel Technology Next Generation, either in written form or as explicitly permitted for the organizations members through the current terms and conditions of membership.
Page 2
A special thanks to the HTNG members who have contributed to the development of this requirements document as well as supporting Cellular Coverage Workgroup efforts:
AT&T CISCO Corning MobileAccess Enseo Future Technologies Consulting Group, Inc. Hewlett Packard Hilton Hotels Hyatt Hotels InnerWireless Mandarin Oriental Hotel Group Marcus Hotels Marriott International Motorola Omni Hotels Ruckus Wireless SOLiD Technologies Sprint Starwood Hotels and Resorts
Page 3
Table of contents
1 2 INTRODUCTION ...............................................................................................................................................5 PROBLEM STATEMENT: TWO YEARS FROM NOW...............................................................................6 2.1 2.2 2.3 2.4 2.5 3 GUEST ............................................................................................................................................................6 HOTEL ............................................................................................................................................................6 MOBILE NETWORK OPERATOR (MNO) ..........................................................................................................6 PERFECT STORM .............................................................................................................................................6 WHAT DOES THIS MEAN FOR EXISTING WAN METHODS? ...............................................................................6
WHY CPRI? ........................................................................................................................................................7 3.1 BENEFITS OF C-RAN ARCHITECTURE .............................................................................................................7 3.1.1 Energy Efficient .....................................................................................................................................7 3.1.2 Cost savings on CAPEX/OPEX .............................................................................................................7 3.1.3 Capacity Improvement ...........................................................................................................................8 3.1.4 Adaptability to Non-uniform Traffic ......................................................................................................8 3.1.5 Smart Internet Offload ...........................................................................................................................8
SYSTEM OVERVIEW .......................................................................................................................................9 4.1 MRHU ......................................................................................................................................................... 10 4.1.1 Input Interfaces .................................................................................................................................... 10 4.1.2 Outputs................................................................................................................................................. 10 4.1.3 Connectors ........................................................................................................................................... 11 4.1.4 Management ........................................................................................................................................ 11 4.1.5 Enclosure ............................................................................................................................................. 11 4.2 RRU ............................................................................................................................................................. 12 4.2.1 Connectors ........................................................................................................................................... 13 4.2.2 Coverage & Capacity .......................................................................................................................... 13 4.2.3 Management ........................................................................................................................................ 14 4.2.4 Power ................................................................................................................................................... 14 4.2.5 Enclosure ............................................................................................................................................. 14 4.2.6 Environmental & Regulatory Requirements ........................................................................................ 15 4.2.7 Performance Metrics for both MRHU and RRU (minimum) ............................................................... 15
SOFTWARE REQUIREMENTS OVERVIEW: ............................................................................................ 16 5.1 5.2 6.1 6.2 6.3 6.4 MASTER REMOTE RADIO UNIT (MRRU) ...................................................................................................... 16 REMOTE RADIO UNIT (RRU) ........................................................................................................................ 17 A. CPRI AND 3GPP ORI SPECIFICATIONS .................................................................................................... 18 B. LTE SPECTRUM ....................................................................................................................................... 19 C. LTE CARRIER AGGREGATION - INFORMATIVE ......................................................................................... 22 D. LTE TERMINAL CATEGORIES .................................................................................................................. 24
Page 4
1 Introduction
2.3 million hotel rooms are represented by HTNG whose hotel members worked together with MNOs, DAS manufacturers/ integrators, providers of Wi-Fi, etc. to develop this requirements document which was created to give RAN/DAS manufacturers insight into hotel requirements to take an existing architecture (RRH) and adapt it for indoor use by multiple MNOs. This requirements document is intended to be additive to existing MNO requirement for in building LTE coverage. In other words, any MNO-specific in building coverage/capacity requirements should still be met. This requirements document is meant to address the additional requirements needed for an in building multi-MNO LTE environment. This document provides high level hardware and software system requirements for distributing LTE spectrum within a hotel. The notion is that the hotel owner will have participation from multiple mobile network operators (MNO) and there is a collective interest in improving LTE coverage and capacity at any given property. There are multiple models for the ownership and management of the system which are outside the scope of this document. For the purposes of this document it is assumed that the MNOs would connect to the system on a neutral host basis.
Page 5
2 Problem Statement: Two Years From Now

2.1 Guest
The mobile device is becoming integral in every aspect of their daily life to:
Conduct business Enjoy leisure time Purchase goods and services Ensure personal safety
2.2 Hotel
Personalized service includes providing connectivity to the network and services of the guests choosing:
Beyond basic Internet access provided by the hotel or its partners Support quality access to the guests subscribed mobile network Enable delivery of content and services from the Mobile Network Operator
2.3 Mobile Network Operator (MNO)

Service differentiation will come in the form of providing a user real-time control of their wireless experience:
Good coverage plus the ability to control/mitigate interference Maximum flexibility in allocating bandwidth High quality transport medium on premise
2.4 Perfect Storm

With the rollout of LTE, MNOs are looking at methods of efficient spectrum usage while keeping their capital costs in check. At the same time, hoteliers are looking to provide indoor LTE coverage while limiting on-premise LTE electronic equipment. Base station hoteling satisfies both the MNO and the Hotel. Base station hoteling is a method whereby remote radio units are deployed in the field or hotel and the remainder of the electronic equipment remains at the base station co-location site. This concept is analogous to C-RAN (please see below). To meet these requirements the document proposes an in-building solution based on the Common Packet Radio Interface (CPRI). An overview of CPRI and a description of the benefits offered are provided in the next section.
2.5 What does this mean for existing WAN methods?

The idea of using ethernet for cellular backhaul is becoming mainstay. However, the Base station hoteling concept cannot use ethernet. The CPRI (3GPP ORI) stack defines its own physical layer and logical layer (layers 1 and 2).
Page 6
3 Why CPRI?
Todays MNO networks are evolving. One network solution is the movement away from the traditional base station architecture to virtual base station architecture where the base station functionality is split between two elements - the Baseband Unit (BBU) and Remote Radio Unit (RRU). The migration to virtual base station architecture will most likely occur in stages starting with the clustering of BBUs to pooling of BBU resources to cooperative processing. The final stage is often referred to Cloud Radio Access Network (C-RAN).
3.1 Benefits of C-RAN architecture

3.1.1 Energy Efficient
With the C-RAN architecture, the number of base station sites can be reduced several fold. Secondly, because the BBU pool is a shared resource among a large number of virtual base stations, it means a much higher utilization rate of processing resources and lower power consumption. Lastly, the distance from the RRU to the users device can be decreased since cooperative radio technology can reduce the interference among dense RRUs.
3.1.2 Cost savings on CAPEX/OPEX

Because the BBUs and site support equipment are aggregated in a few big rooms, it is much easier for centralized management and operation, saving a lot of O&M cost associated with the large number of base station sites in a traditional RAN. Secondly, although the number of RRUs may not be reduced in C-RAN architecture, its functionality is simple and size/power are both small.
Page 7
3.1.3 Capacity Improvement

In the C-RAN architecture, the BBU pool can easily share the signaling, traffic data and channel state information of all active devices in the system. Hence its much easier to implement joint processing and scheduling to mitigate inter-cell interference and improve spectral efficiency.
3.1.4 Adaptability to Non-uniform Traffic

A C-RAN is also well suited for non-uniform traffic distribution by applying the load balancing functionality inherently available in pooled architectures.
3.1.5 Smart Internet Offload

The C-RAN architecture enables the break-out of internet traffic at the BBU consolidation point and therefore reducing core network traffic and gateway upgrade costs, as well as reducing latency to the user. The Common Public Radio Interface (CPRI) standard defines the interface between the BBU and RRU. The CPRI specification is focused on the hardware dependent layers ensuring simplicity, flexibility, and availability of a wide range of system architectures depending on the application, as we as, enabling independent upgrades via a standard interconnect. The adoption of CPRI for in-building solutions not only provides a flexible, scalable in-building network capable of supporting the unique characteristics of LTE/LTE-A (i.e., wide band, MIMO, interference mitigation via cooperative radio) for multiple MNOs, but provides a graceful evolution path to C-RAN
Page 8
4 System Overview
The proposed solution shall use a distributed base station architecture with remote radio heads installed inside the hotel property. The infrastructure for CPRI (or 3GPP ORI) link between the Baseband Unit and the Remote Radio Head Units will be the hotels fiber. From a hardware perspective the proposed solution comprises the following components: Master Radio Head Unit (MRHU) The purpose of the MRHU is to provide a demarcation point for the MNO on the property, aggregate CPRI feeds from multiple MNOs and manage the distribution of packet radio data to intelligent radio endpoints (termed remote radio units) located within the hotel. The MRHU may also be needed to provide hardware support for advanced features (e.g. dynamic resource allocation) which will be identified by the software team and incorporated into a later revision of this document. It is possible to have multiple Master Remote Radio Heads (MRRH). Remote Radio Unit (RRU) The purpose of the RRU is to convert the packet radio data from the MRHU into an analog RF signal to be propagated from an internal antenna.
Page 9
4.1 MRHU
4.1.1 Input Interfaces
The MRHU shall support four to eight CPRI ports of a type compliant with the CPRI specification. Input ports may be provided in a modular form factor to provide flexibility and cost control. Each CPRI port shall be capable of supporting the full CPRI line rate of 10Gbps and shall be fully configurable to support all line rates defined in the CPRI specification below the maximum line rate. Each port will be fed from an LTE baseband unit (BBU) that is expected to be owned by the MNO. The CPRI feed shall support up to two LTE uplink and downlinks channels of 10MHz and 20MHz respectively for up to two bands (e.g. 850MHz/1900MHz). It is recommended that the minimum line rate from the BBU is 4.9Gbps for one band and 9.8Gbps for two bands. The BBU may be either located at the MDF or remotely at the MNO switching office.
4.1.2 Outputs
The MRHU shall support up to 48 output ports of a type compliant with the CPRI specification. Output ports shall be provided in a modular form factor to provide flexibility and cost control. The number and type of ports required for any line card and number of line card variants is to
Page 10
be determined by the manufacturer. The MRHU shall aggregate the BBU inputs and multicast or simulcast the composite signal to each of the output ports. The composite signal consists of multiple CPRI channels carrying control and data signals to the RRUs installed in the property and shall support up to four EUTRAN Operating Bands as described in Appendix C, LTE Spectrum.
4.1.3 Connectors
All connectors shall be accessible from the front of the unit. All fiber connections shall use standard optics as specified in the CPRI specification. The fiber optics may be for single mode or multi-mode fiber. Support for multi-mode fiber is required to support the base of multi-mode fiber installed in hotel properties today. The selection of fiber type needs to consider the higher loss (and therefore lesser reach) of multi-mode fiber as well as future bandwidth requirements which may only be achievable with single mode fiber. Appendix B provides a table of the different characteristics of fiber type.
4.1.4 Management
The MRHU shall be managed by an element management system (EMS). It is envisioned that network management traffic will be carried over an optical supervisory channel (OSC) between the RRUs and the MRHU. The MRHU shall have a 1000BASE-T port for connecting to the EMS.
4.1.5 Enclosure
The MRHU will typically be deployed in the MDF of the hotel property being serviced. The MRHU shall be mounted in a standard 19 rack. The height of the MRHU shall not exceed 2U. The MRHU shall be powered from a standard AC source supplied at the rear of the unit and should support dual redundant, hot swappable power supply modules. In addition, the MRHU should be configurable to support backup power sources such as a generator or UPS to ensure continued operation in the case of an outage of the primary power source. Power modules shall be accessible from the front of the unit.
Page 11
4.2 RRU
RRUs can be deployed as standalone endpoints or as participants in one or more of the chaining topologies defined in the CPRI standard. Chaining RRUs allows the CPRI data to be distributed across the floor of a building. The purpose of the RRU or RRU chain is to convert the LTE CPRI input from the MRHU into RF and transmit that signal from a 2x2 MIMO antenna integrated with the RRU. The Remote Radio Unit can support up to 4 frequency bands with a minimum of 2 bands, each with 2x2 MIMO and support for carrier aggregation scenarios up to 20 DL/10 UL MHz per band (CPRI limitation). The RRU has to support adaptive line rate depending on whether it supports two, three or four frequency bands. The RF chains can be allocated one per MNO or concatenated together to provide higher order of MIMO and larger channel size. Each RF Chain in each Remote Radio Head will be uniquely addressable to support maximum flexibility for dynamic bandwidth allocation RRUs are expected to be manufactured in different configurations to allow optimization for different deployment scenarios i.e. the number of participating MNOs and bands to be supported. The following configurations have been identified:
Single MNO, single/dual band Single MNO, multiple bands Multiple MNOs, single/dual band Multiple MNOs, multiple bands
Page 12
THE CPRI standard supports interoperability across multiple RRU types. For example, when MNOs and/or bands cannot share the same RRU, the RRU chains can be configured using multiple RRU types separated on a fiber daisy chain by wavelength channels. Alternatively, RRUs may be separated using a physical fiber link.
4.2.1 Connectors
Each RRU shall have a primary CPRI fiber input. In addition, the RRU shall also support secondary CPRI ports for connecting to other chained RRUs. The supported line rates on the secondary port shall be same as the input line rate. The number of ports shall be determined by the type of chaining topology implemented by the equipment vendor, but a minimum of 5 RRUs per chain is required.
Tree and Branch Chain Ring
Primary and secondary CPRI ports shall use standard optics as specified in the CPRI specification. The fiber optics may be for single mode or multi-mode fiber. An RRU may also support connectors for an optional 2x2 MIMO antenna to cater to provide flexibility in deploying the solution in problematic coverage areas.
4.2.2 Coverage & Capacity

For any given CPRI line rate the actual data rates available to a hotel customer will be inversely proportional to the coverage area provided. In addition, the number of RRUs deployed in a chain will also impact actual data rates available to a hotel customer as the total CPRI capacity being presented to the chain will be shared. Remote Radio Head solution shall meet or exceed Base Unit vendors downlink and uplink spectral efficiency factor for the wireless environment listed above. Remote Radio Head solution shall meet or exceed the following delay specifications:
Downlink Remote Radio Head Delay Budget = Release 10 3GPP one way downlink budget - BBU delay - UE delay Uplink Remote Radio Head Delay Budget = Release 10 3GPP one way uplink budget - BBU delay UE delay Latency: The one-way transit time between a packet being available at the IP layer in either the UE or radio access network and the availability of this packet at IP layer in the radio access network/UE shall be less than 5 ms. Also C-plane latency shall be reduced, e.g. to allow fast transition times of less than 100 ms from camped state to active state management (3GPP TS 25.913 Standard).
Page 13
4.2.3 Management
The RRU shall be managed by the same network element management system (EMS) used for the MRHU.
4.2.4 Power
The RRU units shall be powered using Power over Ethernet (PoE) technology as defined by the IEEE in the 802.3af and 802.3at. Power over Ethernet technology describes a system to pass electrical power safely, along with data, on ethernet cabling. The IEEE standard for PoE requires Category 5 cable or higher for high power levels, but can operate with Category 3 cable for low power levels. Power is supplied in common mode over two or more of the differential pairs of wires found in the ethernet cables and comes from a power supply within a PoE-enabled networking device such as an ethernet switch or can be injected into a cable run with a midspan power supply. The original IEEE 802.3af-2003PoE standard provides up to 15.4 W of DC power (minimum 44 V DC and 350 mA to each device Only 12.95 W is assured to be available at the powered device as some power is dissipated in the cable. The updated IEEE 802.3at-2009 http://en.wikipedia.org/wiki/802.3at - cite_note-6 PoE standard also known as PoE+ or PoE plus, provides up to 25.5 W of power. The 2009 standard prohibits a powered device from using all four pairs for power. Due to the CAPEX and OPEX benefits offered, the preferred method of powering the units on the guest floors shall be 802.3af. Higher power may be the preferred method of powering the units in large common areas such as ballrooms and lobbies. While PoE may be the optimal method to power units over CAT5 or higher, the physical distance limitation with PoE is 300 feet. In many cases, DC -48v power is applicable and shall be considered by vendors. This may be required for lengths greater than 300ft and for optical equipment such as PON optical terminals in conjunction with the remote radio units. NOTE: RAN vendors to define output power options. Hotels will generally not allow standard power blocks in the guest rooms. For this reason, composite copper/fiber cable is recommended, to allow for remote power from central source.
4.2.5 Enclosure
The RRU shall be unobtrusive, appealing to the eye, and in colors conforming to hotel practices. The RRU shall be capable of being mounted in an IDF and underneath or above the suspended ceiling of hotel corridors.
Page 14
4.2.6
Environmental & Regulatory Requirements Alignment with Telcordia, or relevant EU specifications Compliance with applicable FCC, ITU, or EU regulations Compliance with relevant FCC OET65, or EU RF exposure guidelines for General Population Operating and storage temperature and humidity ranges
4.2.7 Performance Metrics for both MRHU and RRU (minimum)

The wireless system environment and usage condition shall be defined as:
Environment = Indoor Hotspot (InH) Mobility = Stationary (and pedestrian mobility needed for public areas) Traffic Model = Bursty Traffic Antenna Configuration = 2x2 MIMO with 20 MHz
Key Performance Indicator (KPI) parameters for MNO network shall include:
Measures of Capacity o Cell throughput o Average user throughput o Cell edge user throughput o Average users per cell Measures of Quality of Service o Latency o Packet Loss o Retransmissions Measures of Uniformity of Service o Ratio cell edge to average user throughput
Network options between MRRH and BBUs and BBU back to carrier core:
The Hotel shall specify a demarc between the MRRH and the input from the WAN. This demark shall be an optical interface. The protocol transferred over this demarc shall be CPRI or 3GPP ORI. The WAN from the base station hotel (of each MNO) shall be provided by the MNO and is considered outside of scope of this document. It is anticipated that from the BBU into the core the MNO shall adopt standard LTE interfaces for backhaul S1 and X2. However, these are considered out of scope of this document. The mechanism to provide the CPRI or 3GPP ORI to the hotel may be WDM PON. This is outside of scope of this document.
NOTE: SEEK ADDITIONAL INPUT from the MNOs on above options
Page 15
5 SOFTWARE REQUIREMENTS OVERVIEW:

The following Software Requirements Overview section provides an outline intended as a guideline for RAN manufacturers. Again, this section is intended to be additive to existing MNO requirement for in building LTE coverage. Any MNO-specific in building monitoring, maintenance and other software requirements should still be met. The software requirements should address the additional requirements needed for an in building multi-MNO LTE environment.
5.1 Master Remote Radio Unit (MRRU)

a. Management i. Support the following mode of operation per MNO 1. Pass Through Mode - BBU manages down to the RRU level how will this be managed if RRUs are shared among different MNOs each using their own BBUs? if box is shared, someone has to be the lead on what can and can't be done to it...other have read only access. 2. Pseudo BBU Mode BBU manages down to the Master RRU and the Master RRU manages the RRU level who do we see managing/having access to master RRU and everything downstream from there? ii. In the Pseudo BBU mode, provides: 1. Addressing down to the RF Chain level of the RRUwe should list what RF details we want to see at the RRU? Downlink and uplink RF power levels, gains 2. Dynamic bandwidth allocation 3. Monitoring and reporting internal fiber transport (e.g., loss, latency, jitter, etc.) b. External I/O i. Support up to four ports (i.e., one per MNO) ii. Support a mix of configurations including (e.g., MNO #1 dark fiber and all other MNOs are WDM over fiber): 1. Dark Fiber: probably single mode only 2. WDM over Fiber: CWDM and DWDM?? 3. PON c. Internal I/O NOTE: RAN vendors to specify following requirements i. Support up to X RRUs If the RRU supports a transport layer that can handle multiple chained RRUs, then the physical layer may be shared. The analogy of this is SSL/SSH in your computer applications. If the RRU does not support this, then WDM technology may also be used. In the first case, there has to be a built in scheduler so this becomes a TDD approach. Whereas in the WDM case, this is a separate physical path even though the fiber is common
Page 16
ii.
Support one of the following configurations: 1. Dark Fiber: single mode fiber 2. WDM over Fiber: probably CWDM only 3. PON: with and without WDM
5.2 Remote Radio Unit (RRU)

1) Management a) Programmable mapping RF Chains to MNO (e.g., one per MNO, two to single MNO, etc.) b) Support N+1 redundancy c) For Partial CPRI mode, provide local Control & Management functionality d) Setup, control and monitoring of RF parameters, Downlink and uplink RF power levels, gains, etc. 2) I/O a) Support the following configurations: i) Dark Fiber: single mode and multi-mode fiber ii) WDM over Fiber: probably CWDM only iii) PON: with and without WDM b) Support the following operational modes for the Digital-over-Fiber protocol known as CPRI: i) Full CPRI ii) Partial CPRI (e.g., IQ) iii) Customized per BBU requirements c) Daisy chaining 3) RF Chain a) Tunable parameters (e.g., output power, gain, etc.) b) Frequency agile c) Support multiple radio channel bandwidths up to 20MHz d) Support Carrier Aggregation configurations as defined by 3GPP Release 10
Page 17
6 Appendices
6.1 A. CPRI and 3GPP ORI specifications
CPRI Common Public Radio Interface (CPRI) Interface Specification v4.2 9-29-10 http://www.cpri.info/downloads/CPRI_v_4_2_2010-09-29.pdf NOTE: ORI is still in ISG status (Industry Specification Group) under ETSI
ETSI ORI Specifications http://portal.etsi.org/portal/server.pt/community/ORI/350
Open Radio Equipment Interface (ORI); ORI Interface Specification; Part 2: Control and Management (Release 1) Open Radio Equipment Interface (ORI); Open Radio equipment Interface (ORI) Requirements & C&M update for Release 1 Release 1 The ETSI ORI Industry Specification Group The interface which is being defined by the Industry Specification Group is an important step towards realizing these benefits through widespread deployment of distributed Radio Equipment for mobile communication networks. The specification that the group is preparing covers those layers of the OSI stack required to enable interoperability, and may refer to appropriate publicly available specifications. The interface is built on top of an interface already defined by the CPRI (Common Public Radio Interface) group. However, options are removed and functions are added with the objective of making the interface fully interoperable.
Page 18
6.2 B. LTE Spectrum

To support the ever increasing consumption of mobile broadband data the mobile industry is working to identify additional spectrum. The table below captures the bands approved for LTE at the time of this publication (January 2012). MNO deployment in these bands is subject to spectrum auctions and MNOs business priorities. From Tables 5.5-1 "E-UTRA Operating Bands" and 5.6.1-1 "E-UTRA Channel Bandwidth" of 3GPP TS 36.101,[the following table lists the specified frequency bands of LTE and the channel bandwidths each listed band supports: Uplink (UL) EUTRAN Operating Band Operating Band BS Receive UE Transmit I II 1920 MHz to 1980 MHz 1850 MHz to 1910 MHz 1710 MHz to 1785 MHz 1710 MHz to Downlink (DL) Operating Band BS Transmit UE Receive 2110 MHz to 2170 MHz 1930 MHz to 1990 MHz 1805 MHz to 1880 MHz 2110 MHz to FDD FDD 5, 10, 15, 20 1.4, 3, 5, 10, 15, 20 1.4, 3, 5, 10, 15, 20 1.4, 3, 5, UMTS IMT, "2100" PCS, "1900" Japan, Europe, Asia Canada, US, Latin America Finland,[16] III FDD DCS 1800, "1800" AWS, Hong Kong[17][18], Germany IV FDD
[19]
Duplex Mode
Channel Bandwidths (MHz) Alias Region(s)
Canada, US,
Page 19
Uplink (UL) EUTRAN Operating Band Operating Band BS Receive UE Transmit 1755 MHz
Downlink (DL) Operating Band BS Transmit UE Receive 2155 MHz 10, 15, 20 "1.7/2.1 GHz" Latin America Canada, US, Australia, Latin America Japan EU, Latin America EU, Latin America Duplex Mode Channel Bandwidths (MHz) Alias Region(s)
824 MHz to 849 MHz 830 MHz to 840 MHz 2500 MHz to 2570 MHz 880 MHz to 915 MHz 1749.9 MHz
869 MHz to 894 MHz 875 MHz to 885 MHz 2620 MHz to 2690 MHz 925 MHz to 960 MHz 1844.9 MHz to 1879.9 MHz 2110 MHz to 2170 MHz 1475.9 MHz to 1495.9 MHz 728 MHz to 746 MHz 746 MHz to 757 MHz 758 MHz to 768 MHz 734 MHz to 746 MHz 860 MHz to 875 MHz 875 MHz to
FDD
1.4, 3, 5, 10
Cellular 850, UMTS850 UMTS800 IMT-E, "2.6 GHz" GSM, UMTS900, EGSM900
VI VII
FDD FDD
5, 10 5, 10, 15, 20 1.4, 3, 5, 10
VIII
FDD
IX
to 1784.9 MHz 1710 MHz to 1770 MHz 1427.9 MHz
FDD
5, 10, 15, 20 5, 10, 15, 20
UMTS1700 UMTS, IMT 2000
Japan Uruguay, Ecuador, Peru Japan (Softbank, KDDI, DoCoMo)[20]
FDD
XI
to 1447.9 MHz
FDD
5, 10
PDC
XII XIII XIV XVII XVIII XIX
698 MHz to 716 MHz 776 MHz to 787 MHz 788 MHz to 798 MHz 704 MHz to 716 MHz 815 MHz to 830 MHz 830 MHz to
FDD FDD FDD FDD FDD FDD

Page 20
1.4, 3, 5, 10 5, 10 5, 10 5, 10 5, 10, 15 5, 10, 15
lower SMH blocks A/B/C upper SMH block C upper SMH block D
US US US US
Uplink (UL) EUTRAN Operating Band Operating Band BS Receive UE Transmit 845 MHz XX 791 MHz to 821 MHz 1447.9 MHz XXI to 1462.9 MHz XXII XXIII 3410 MHz to 3490 MHz 2000 MHz to 2020 MHz 1626.5 MHz XXIV to 1660.5 MHz XXV XXXIII XXXIV XXXV XXXVI XXXVII XXXVIII XXXIX XL 1850 MHz to 1915 MHz
Downlink (DL) Operating Band BS Transmit UE Receive 890 MHz 832 MHz to 862 MHz 1495.9 MHz to 1510.9 MHz 3510 MHz to 3590 MHz 2180 MHz to 2200 MHz 1525 MHz to 1559 MHz 1930 MHz to 1995 MHz FDD FDD 5, 10, 15, 20 1.4, 3, 5, 10 FDD 5, 10, 15 FDD 5, 10, 15, 20 EU's Digital Dividend 800 MHz EU Duplex Mode Channel Bandwidths (MHz) Alias Region(s)
FDD
5, 10 1.4, 3, 5, 10, 15, 20 5, 10, 15, 20 5, 10, 15 1.4, 3, 5, 10, 15, 20 1.4, 3, 5, 10, 15, 20 5, 10, 15, 20 5, 10, 15, 20 5, 10, 15, 20 5, 10, 15, 20 IMT-2000 China, India EU
FDD TDD TDD TDD TDD TDD TDD TDD TDD
1900 MHz to 1920 MHz 2010 MHz to 2025 MHz 1850 MHz to 1910 MHz 1930 MHz to 1990 MHz 1910 MHz to 1930 MHz 2570 MHz to 2620 MHz 1880 MHz to 1920 MHz 2300 MHz to 2400 MHz
Page 21
Uplink (UL) EUTRAN Operating Band Operating Band BS Receive UE Transmit XLI XLII XLIII
Downlink (DL) Operating Band BS Transmit UE Receive TDD TDD TDD 5, 10, 15, 20 5, 10, 15, 20 5, 10, 15, 20 Duplex Mode Channel Bandwidths (MHz) Alias Region(s)
2496 MHz to 2690 MHz 3400 MHz to 3600 MHz 3600 MHz to 3800 MHz
6.3 C. LTE Carrier Aggregation - Informative

Carrier Aggregation (CA) is one of the most distinct features for LTE-Advanced systems, which can support a much wider transmission bandwidth up to 100 MHz by aggregating two or more individual component carriers belonging to the same (intra-band) or different (inter-band) frequency bands. With CA, it is possible to schedule a device on multiple component carriers simultaneously. From a radio resource management perspective, the component carriers selection plays an important role in optimizing the system performance. The following tables show the current focus and the overall prioritization respectively of the CA scenarios.
Page 22
3GPP Carrier Aggregation Focus Scenarios
Page 23
6.4 D. LTE Terminal Categories

LTE Advanced / Release 10 added three new terminal categories highlighted in green below
Page 24

2012-04-03 Multi-Mobile Network Operator In-Building LTE Remote Radio Head Technical Requirements

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2012-04-03 Multi-Mobile Network Operator In-Building LTE Remote Radio Head Technical Requirements

Transféré par

Droits d'auteur :

Formats disponibles

Multi-Mobile Network Operator In-Building LTE Remote Radio Head Technical Requirements

Version 1.00 3 April 2012

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

2 Problem Statement: Two Years From Now

2.3 Mobile Network Operator (MNO)

2.4 Perfect Storm

2.5 What does this mean for existing WAN methods?

Hotel Technology Next Generation 3 April 2012

3.1 Benefits of C-RAN architecture

3.1.2 Cost savings on CAPEX/OPEX

Hotel Technology Next Generation 3 April 2012

3.1.3 Capacity Improvement

3.1.4 Adaptability to Non-uniform Traffic

3.1.5 Smart Internet Offload

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

Tree and Branch Chain Ring

4.2.2 Coverage & Capacity

Hotel Technology Next Generation 3 April 2012

Hotel Technology Next Generation 3 April 2012

4.2.7 Performance Metrics for both MRHU and RRU (minimum)

Hotel Technology Next Generation 3 April 2012

5 SOFTWARE REQUIREMENTS OVERVIEW:

5.1 Master Remote Radio Unit (MRRU)

Hotel Technology Next Generation 3 April 2012

5.2 Remote Radio Unit (RRU)

Hotel Technology Next Generation 3 April 2012

ETSI ORI Specifications http://portal.etsi.org/portal/server.pt/community/ORI/350

Hotel Technology Next Generation 3 April 2012

6.2 B. LTE Spectrum

Channel Bandwidths (MHz) Alias Region(s)

Hotel Technology Next Generation 3 April 2012

5, 10 5, 10, 15, 20 1.4, 3, 5, 10

to 1784.9 MHz 1710 MHz to 1770 MHz 1427.9 MHz

5, 10, 15, 20 5, 10, 15, 20

UMTS1700 UMTS, IMT 2000

Japan Uruguay, Ecuador, Peru Japan (Softbank, KDDI, DoCoMo)[20]

XII XIII XIV XVII XVIII XIX

FDD FDD FDD FDD FDD FDD

1.4, 3, 5, 10 5, 10 5, 10 5, 10 5, 10, 15 5, 10, 15

Hotel Technology Next Generation 3 April 2012

FDD TDD TDD TDD TDD TDD TDD TDD TDD

Hotel Technology Next Generation 3 April 2012

6.3 C. LTE Carrier Aggregation - Informative

Hotel Technology Next Generation 3 April 2012

3GPP Carrier Aggregation Focus Scenarios

Hotel Technology Next Generation 3 April 2012

6.4 D. LTE Terminal Categories

Vous aimerez peut-être aussi