TSDSI-SG1-WG1-SI10-WI1-V0.1.0-201606223

Work Item Report

Wireless Systems

Radio Network Evolution and Spectrum (RNES)

Relay enhancements to achieve good wireless backhaul


Intentionally left blank to fill information on:

  1. Secretariat address
  2. Editor with address
  3. Chair with address
  4. Vice-Chair with address
  5. Copyright information

Intentionally left blank to fill information on:

  1. Standard number
  2. Standard mnemonic
  3. Version [for status information]
  4. Draft date, if not published [for status information]
  5. Publication date of the standard [for status information]

Intentionally left Blank for Abstract

TBD

1 Intended Audience 6

2 Abstract 7

3 Definition, Abbreviations, Acronyms 8

4 Scope of the work/study item 9

5 References 10

5.1 TSDSI 10

5.2 External 10

6 Introduction 11

6.1 Purpose 12

7 Various Ways to Classify Relay Node 13

7.1 Classification based on Architecture A and B 13

7.2 Classification based on Layer 1, 2, and 3 14

7.3 Classification based on Type 1 and 2 14

8 Deployment concerns 16

9 Virtual eNodeB, a new Relay architecture 17

9.1 Multiplexers for V-NB 18

10 Message flow in VeNB based EPS 19

11 Protocol Stack 21

12 Phased VeNB Deployment Strategy 22

13 Deployment Examples of Virtual eNodeB 23

13.1 Deployment Example 1 23

13.2 Deployment Example 2: 24

13.3 Deployment Example 3: 25

14 Summary 26

15 Revision history 26

1  Intended Audience

Following are the intended audiences:

1.  TSDSI Members

2.  Others

  1. SSOs and SDOs
  2. Vendors
  3. Operators
  4. Academia
  5. R&D Centers
  6. Manufacturers

2  Abstract

<Chairman: This WI report is replica of SI report [12]. The version is 0.1.0 as this is the first Work Item Report.

This SI reportWI report highlights the various ways of classifying a Relay Node, addresses architectural concerns that add to cost of deploying Relay by the operators, proposes going beyond existing Relay Node architecture and proposes a new eNodeB, Virtual eNodeB. Virtual eNodeB architecture does not require any change to existing elements defined in 3GPP specification. The only network element that is new and different from Relay Node is the Virtual eNodeB. Further, the Virtual eNodeB is so designed to reuse existing 3GPP network elements within a new rearrangement of the RAN and CN. The report provides some of the deployment examples of Virtual eNodeB towards ultra-low cost Radio Access Element or Relay solution. Effort is made to restrict the fundamental changes, if any, required for this Study Item to be only localized within the Virtual eNodeB.

SI 10 [2] talks about Relay enhancements to achieve good wireless backhaul.

In the SG1-WG1 meeting, it was expressed that though the name Virtual eNodeB is appropriate for the proposed device, a new name be coined so that it can be differentiated and identified distinctly with respect to the Virtualized eNodeB. In Virtualized eNodeB scenario, eNodeBs are virtual systems carved out of systems maintained in a centralized Server Farm, perhaps specialized with Radio Access functions. Elsewhere Cloud RAN is the term used to signify the same behavior. Given the many names floating around, it was decided that a new distinct name for VeNB be arrived at TSDSI-SG1-WG1.

SWIP [11] was posted for the following two reasons and requirements:

First, to maintain our own naming convention and device list. For this a new document needs to be created. It will be appropriate that a new Study Item be created whose sole purpose is to reconcile naming conventions and associated confusion. A NIP to this effect can be created during the meeting and text can be drafted by SG1. This SI should maintain what network elements are developed and trademarked in which SDO and particularly at TSDSI.

Second, to arrive with a temporary name for VeNB so that we can start using it. We propose that the VeNB be prefixed with “Temporary” and called as “Temporary Node”. When the work item (WI1-SI10) matures into a standard, enough consensus will be available in the naming convention to rename the “Temporary Node” appropriately.

This naming issue will pose big hurdle even to TSDSI OP relation and the steps mentioned here would help towards resolving such hurdles and remove confusion to first time Members/attendees/contributors of TSDSI.

In future versions, Virtual eNodeB will be replaced with appropriate name. And this section will define it for the first time.

3  Definition, Abbreviations, Acronyms

v-NB Virtual eNodeB (This name will change as per SWIP [11])

4  Scope of the work/study item

The scope is as per the SI10

5  References

5.1  TSDSI

[1].  R&R

[2].  WP

i.  NIP

[3].  TSDSI-SG1-NIP58-V1.0.0-20150722

ii.  SWIP

[4].  TSDSI-SI11-SWIP6-V1.0.0-20150814 [Agreed to move this to SI10]

[5].  TSDSI-SI10-SWIP14-V1.0.0-20150901

[6].  TSDSI-SI10-SWIP15-V1.0.0-20150901

[7].  TSDSI-SI10-SWIP17-V1.0.0-20150901

[8].  TSDSI-SI10-SWIP19-V1.0.0-20150901

[9].  TSDSI-SI10-SWIP21-V1.0.0-20150901

[10].  TSDSI-SI10-SWIP59-V1.0.0-20160111

[11].  TSDSI-SI10-SWIP109-V1.0.0-20160615

[12].  SI

[13].  [12] TSDSI-SG1-WG1-SI10-V0.3.0-20150129

5.2  External

TBD

6  Introduction

LTE or Long term evolution is a 3GPP standard for mobile communication. LTE refers to the Evolved UMTS Radio Access Network (E-UTRAN), whereas System Architecture Evolution (SAE) refers to the Evolved Packet Core (EPC).

Network elements in LTE include eNodeB (Base Transceiver Station – BTS), UE (user equipment – used to connect to eNodeB for accessing or getting voice or data service), Relay Node and Repeater.

Network elements in SAE include MME (Mobility Management Entity), SGW (Serving Gateway), PDN-GW (Packet Data Network Gateway).

eNodeB is responsible for completing radio resource management when allowing UE to access services. eNodeB are connected to the EPC using MME for control plane signaling and using SGW for user plane data.

The SGW is connected to a PDN-GW or PGW for connectivity to external networks including the public internet.

eNodeB are of various types, e.g. Macro/Wide-area, Micro/local-area, Pico/Small-area, Femto/home, and can be called, for example as Macro BTS, Femto BTS, etc.

Repeaters are used to extend the coverage of an existing BTS. They re-transmit the uplink and downlink signals without having to decode any of the content. Repeaters have one antenna directed towards the donor cell, and a second antenna directed towards the target coverage area. The target coverage area could be an indoor location so the second antenna could be indoors.

Relays also rely upon an RF connection to a donor cell, but Relays differ from Repeater because Relays have their own cells and their own protocol stack. That is, a Relay is similar to a normal BTS but without a fixed transport connection. Relays decode signals and make radio resource management decisions.

PGW connects to packet data network, which could be an external network (either public or private), or could belong to the operator.

Other elements like HSS (Home Subscriber Server), EIR (Equipment Identify Register), PCRF (Policy and Charging Rules Function), etc. and interfaces connecting all the above/preceding elements are also defined in 3GPP specifications.

Various Relay Architectures are being considered by many Organizational Partners and SDOs, e.g. 3GPP. Many of the proposed architectures therein have dependencies on the eNodeB. If an eNodeB does not support Relay protocols then Relay cannot be deployed within the cell of such eNodeB. Due to this and various other issues, Relay Architecture is still a Study Item in 3GPP. In forthcoming chapters we present brief on the existing architectures. Following that, we look at new Relay Architecture, called Virtual eNodeB, by restricting the fundamental changes, if any, required for this Study Item to be only localized within the Virtual eNodeB.

6.1  Purpose

The purpose is to:

1.  Relook entire relay architecture (including signaling) and see if it can be modified for middle mile and/or backhaul options

2.  Reduce cost and impact on eNodeB and EPC elements

  1. Present the deployment concern and problem with Relay Nodes defined in 3GPP specifications
  2. Restrict the fundamental changes, if any, required for this Study Item to be only localized within the Virtual eNodeB.

7  Various Ways to Classify Relay Node

We provide ways of classifying a Relay Node. Additional details may be found from 3GPP specification and other published contents.

There are three primary ways of classifying a Relay node:

- Architecture A and B

- Layer 1, 2 and 3

- Type 1 and 2

7.1  Classification based on Architecture A and B

- Architecture A, with following variants:

1. Alt 1: Full-L3 relay, transparent for DeNB

2. Alt 2: Proxy S1/X2- Home eNB GW function at eNB

3. Alt 3: RN bearers terminate in DeNB;

- Architecture B, with following variant:

1. Alt 4: S1 UP terminated in DeNB.

- All alternatives in principle support multi-hop RN deployments

7.2  Classification based on Layer 1, 2, and 3

7.3  Classification based on Type 1 and 2

Type 1 LTE relay nodes: These LTE relays control their cells with their own identity including the transmission of their own synchronization channels and reference symbols. Type 1 relays appear as if they are a Release 8 eNB to Release 8 UEs. This ensures backwards compatibility. The basic Type 1 LTE relay provides half duplex with Inband transmissions.
There are two further sub-types within this category:

Type 1.a: These LTE relay nodes are out-of-band RNs which have the same properties as the basic Type 1 relay nodes, but they can transmit and receive at the same time, i.e. full duplex.

Type 1.b: This form of LTE relay node is an in-band form. They have a sufficient isolation between the antennas used for the BS-RN and the RN-UE links. This isolation can be achieved by antenna spacing and directivity as well as specialized digital signal processing techniques, although there are cost impacts of doing this. The performance of these RNs is anticipated to be similar to that of femtocells.

Type 2 LTE relay nodes: These LTE relaying nodes do not have their own cell identity and look just like the main cell. Any UE in range is not able to distinguish a relay from the main eNB within the cell. Control information can be transmitted from the eNB and user data from the LTE relay.

All architectures and types of Relay Node specified in 3GPP require enhancements to eNodeB and EPC elements and therefore in addition to cost of Relay Node, the operators have to pay heavily, for software and hardware upgrades in eNodeB and EPC elements.

8  Deployment concerns

The deployment concern and problem with Relay Nodes defined in 3GPP specifications are following:

  1. They are not transparent to eNB (this adds to deployment cost)
  2. eNB must support RN protocol stacks to allow signalling and the transfer of user plane data (adds to deployment cost)
  3. Modified air-interface – called as ‘Un’ interface for user and control plane
  4. RRC (Radio resource configuration) between RN and ENB (adds cost)
  5. NAS (Non-Access Stratum) between RN and MME (no change)
  6. RN subframe configuration information element (adds cost)
  7. TDD uplink and downlink subframe configuration pattern
  8. R-PDCCH that includes MBSFN and ABS, etc.
  9. Relay specific new Scheduler

All architectures and types of Relay Node specified in 3GPP require enhancements to eNodeB and EPC elements and therefore in addition to cost of Relay Node, the operators have to pay, for software and hardware upgrades in eNodeB and EPC elements.

It is generally preferred that network elements be allowed to be placed independently irrespective of other elements in the network. In other words, any placement of a new element should not require modifications in existing deployed elements.

9  Virtual eNodeB, a new Relay architecture

We provide architecture of new eNodeB.

The solution architecture is based on tunneling UE NAS and data traffic over EPS bearers (preferably dedicated) all the way to PGW. This avoids modification to existing elements. Only Relay Node needs change and therefore cost, architectural, protocol, etc. impact on existing network element is avoided. This Relay Node is new RNES element and has more features of eNodeB and therefore we call it Virtual eNodeB. The meaning of Virtual will become apparent as the behavior of this element and traffic flow is covered.

Figure 1 Virtual eNodeB working

·  The core idea is to tunnel out NAS and data till PGW.

·  Relay Node creates two tunnels or dedicated EPS bearers to prioritize control messages over data messages. Orange bearer has high priority or Quality of Service (QoS) compared to Green bearer. These bearers are created whenever UE that gets attached to RN needs to access voice or data service. Based on the queue or buffer status exchanged between UE and RN, an RN will create a bearer of a specific bit rate and QoS.

·  eNB:- unpacks NAS from RN and sends NAS to MME. eNB will be unaware of the NAS and data traffic from UEs attached to RN. UEs (or RN-UE) shown here are only attached to RN for clarity and simplicity.

·  RN:- sends, encapsulates or tunnels NAS message of RN-UE over dedicated EPS bearer (orange color) towards PGW#1. PGW#1 forwards the NAS message of RN-UE to MME (If encapsulation is performed at RN, then de-encapsulation is performed at PGW#1.) S5/S8 can be configured for roaming UEs. Similarly data traffic is sent by RN towards PGW#2 over dedicated EPS bearer (green color)

·  Various flavours are possible. E.g. Optionally HeNB GW can be placed between PGW#1 and MME; HeNB GW can decouple control and/or data traffic, send control/NAS messages towards MME and data traffic towards Internet. HeNB GW may be used when there is only one dedicated EPS bearer between RN and PGW. Alternatively we can replace the optional HeNB GW with SGW/PGW, etc.

·  Note: We assume only one MME in this network for simplicity in explanation. Also, in the figure, the coverage of RN is slightly extended beyond the coverage area of eNB.

As can be inferred, new Relay architecture is possible that will enable low cost roll out in any existing RAN without support from incumbent vendors and without any change to existing network elements and protocol stack. All changes are restricted to Relay Node design only