CFAM RP000770 Dual U-plane IPaddress

CFAM for common feature

Version: Current
Printed by: a20529
Printed on: Tue Mar 22 2016 07:44:16 GMT+0100 (CET)

View: CFAM View

Filtered by:

Template Version: 1.3.0

 Table of Contents
1 Feature Analysis
1.1 Introduction
1.1.1 Version History
1.1.2 Feature overview
1.1.2.1 LTE1771/RP000770 Dual U-plane IP addresses
1.1.2.2 Feature description
1.1.3 Open issues
1.1.4 Decisions
1.1.5 Common Feature analysis Module (CFAM) team members and their roles
1.1.6 Other stakeholders and their roles
1.1.7 Terms and abbreviations
1.1.8 References
1.1.9 IPR Notes
1.2 Stakeholder Requirements
1.2.1 Stakeholder Requirements (from Stakeholder Requirement module)
1.2.2 Additional Stakeholder Requirements (edited here)
1.3 Feature Description
1.3.1 Feature Scope
1.3.2 Definition on dependencies between features
1.3.2.1 Interdependent features
1.3.2.2 Affected features
1.3.2.3 Related features
1.3.3 Alternative Solutions and Selected Solution (in End User point of view)
1.4 Definition of User Scenarios
1.4.1 Operator Scenarios (Use cases)
1.4.2 Feature Management Scenarios
1.4.2.1 Feature Activation Scenarios
1.4.2.2 Feature Deactivation Scenarios (optional)
1.4.3 Impact on System Performance
1.4.4 Impact on System Capacity
1.4.5 Licensing
1.4.6 Other User Scenarios
1.5 Summary of Feature phasing
1.6 SyVe and I&V aspects
1.6.1 O&M System Performance
1.6.2 Feature Testability Analysis
1.6.3 Define the needed configurations
1.7 Impact to NE external interfaces
1.7.1 Interfaces between different NEs
1.7.1.1 Interfaces between BTS and RNC
1.7.1.2 Interfaces between RNC and OMS
1.7.1.3 Interfaces between OMS and NetAct
1.7.1.4 Interfaces between BTS and OMS
1.7.1.5 Interfaces between BTS and NetAct
1.7.1.6 Interfaces between RNC and NetAct
1.7.1.7 Interfaces between OMS and NetAct
1.7.2 Layer 1 - Layer 3 interface impacts between UE and RAN
1.7.2.1 RNC - UE interface
1.7.2.2 BTS - UE interface
1.7.3 Interface between RAN and CN
1.7.3.1 Iu-CS
1.7.3.2 Iu-PS
1.8 DFMEA
1.8.1 DFMEA Outputs
1.8.1.1 1st level DFMEA status
1.8.1.2 2nd level DFMEA status
2 RAN System Level Requirements
2.1 Requirements from OM_GEN_SFS_TNL
 2.1.1 High level requirements
2.1.1.1 Fault Management
2.1.1.1.1 LTE1771 - Dual U-Plane IP Addresses
2.1.2 Management requirements
2.1.2.1 Containment-Tree related to Transport Network Layer
2.1.2.1.1 Application related Object Model
2.1.2.2 Operational Use Cases (pooled in Operability Functional SFS)
2.1.2.2.1 Application related Operator Use Cases
2.1.2.2.2 LTE1771 Dual U-Plane IP Addresses
2.2 Requirements from TT_GEN_SFS_CAPACITY AND PERFORMANCE
2.2.1 Capacity, performance and overload control
2.2.1.1 Capacity
2.2.1.1.1 IP based S1/X2 - LTE Adapter
2.3 Requirements from TT_GEN_SFS_IP TRANSPORT
2.3.1 Functional requirements
2.3.1.1 IP Connection Admission Control
2.3.1.1.1 LTE
2.3.1.2 Dual Uplane IP addresses
2.4 Requirements from TT_GEN_SFS_LAYER 4
2.4.1 Functional requirements
2.4.1.1 LTE User Plane Transport
2.4.1.1.1 GTP-U Protocol Architecture
2.4.1.1.2 GTP-U Path Functions
2.4.1.1.3 GTP-U Tunnel Functions
2.5 Requirements from TT_GEN_SFS_NETWORK CONFIGURATION
2.5.1 Feature application scenarios
2.5.1.1 Dual U-plane IP-addresses
3 BTS Level Feature User Scenarios and Requirements/User Stories
3.1 BTS Level Feature User Scenarios
3.1.1 BTS level Feature User Scenario Relationships
3.1.2 BTS Level Feature User Scenario X
3.2 BTS Level Requirements/User Stories
3.2.1 Requirements from TT_GEN_SFS_CAPACITY AND PERFORMANCE(EFS)
3.2.1.1 Capacity, performance and overload control
3.2.1.1.1 Capacity
3.2.2 Requirements from TT_GEN_SFS_IP TRANSPORT(EFS)
3.2.2.1 Functional requirements
3.2.2.1.1 IP Connection Admission Control
3.2.2.1.2 Dual Uplane IP addresses
4 RNC High Level Requirements
5 OMS High Level Requirements
6 NetAct High Level Requirements
7 RACS High Level Requirements
8 Impact to BTS Design
8.1 Impact BTS design phase participants
8.2 References
8.3 Static Models (Optional)
8.3.1 Architecture impact diagram
8.3.1.1 Diagram explanation
8.3.2 Description of impacts and impacted system and subsystem components
8.4 Dynamic models (Optional)
8.5 Capacity and performance
8.6 Impact to Black Box Modules
8.7 Impact to BTS HW architecture
8.8 Impact to BTS SW architecture
8.9 Radio Platform User Stories and Requirements
8.10 Impact to Radio Platform SW
8.11 Impact to Application SW
8.12 Testability
 8.13 Impact to Interfaces
8.13.1 External Interfaces
8.13.2 Internal Interfaces
8.14 Impact to BTS EFS Documents
8.15 Feature splitting in BTS
9 Impact to RNC Design
9.1 CFAM Phase 2 RNC participants
9.2 References
9.3 Impact to RNC System Domains
9.3.1 Capacity and performance
9.3.2 E2E performance
9.3.3 Testability
9.3.4 Connectivity
9.3.5 Upgradeability
9.3.6 Availability
9.3.7 Operability
9.3.8 Traffic
9.3.9 Security
9.4 Impact to HW architecture
9.5 Impact to SW architecture
9.6 Impact to Interfaces
9.6.1 External Interfaces
9.6.2 Internal Interfaces
9.7 Feature integration steps/phasing in RNC
10 Impact to OMS Design
10.1 CFAM phase 2 OMS participants
10.2 References
10.3 Impact to domains
10.3.1 OMS functional domains
10.3.2 OMS non-functional domains
10.4 Impact to Flexiplatform
10.5 Impact to Testing
10.6 Impact to Customer Documentation
10.7 Impact to 3rd party SW
10.8 Impact to External Interfaces
10.8.1 NWI3
10.8.2 BTSOM
10.8.3 Other external interfaces
10.9 Feature phasing in OMS
11 Impact to RACS Design
11.1 References
11.2 Impact to RACS System Domains
11.2.1 Capacity and performance
11.2.2 E2E performance
11.2.3 Testability
11.2.4 Connectivity
11.2.5 Upgradeability
11.2.6 Availability
11.2.7 Operability
11.2.8 Traffic
11.2.9 Security
11.3 Impact to HW architecture
11.4 Impact to SW architecture
11.5 Impact to Interfaces
11.5.1 External Interfaces
11.5.2 Internal Interfaces
11.6 Feature integration steps/phasing in RACS
11.7 RSM EFS
12 Impact to NetAct Design
 12.1 References
12.2 Impact to System domains in NetAct
12.2.1 NetAct Configurator impact
12.2.2 NetAct Performance Management impact
12.2.3 NetAct Fault Management impact
12.2.4 NetAct Traffica impact
12.2.5 Other NetAct system area impacts
12.3 Impact to Interfaces
12.3.1 External Interfaces
12.4 Feature splitting in OMS and Network Elements
12.5 NetAct requirements to Network Element implementation
12.5.1 NetAct Configurator impact
12.5.2 NetAct Performance Management impact
12.5.3 NetAct Fault Management impact
12.5.4 NetAct Traffica impact
12.5.5 Other NetAct system area impacts
13 Feature Detailed BTS Design
1 Feature Analysis

1.1 Introduction

1.1.1 Version History

Version Date State Editor Note
(Draft/Proposed/
Approved)
0.0.1 13.6.2014 Draft Helmut Heeke Technical concept
complete and
agreed, CFAM
created
0.0.2 16.6.2014 Draft Helmut Heeke Overworked
0.0.3 17.6.2014 Draft Helmut Heeke Overworked
0.0.4 25.6.2014 Draft Helmut Heeke Overworked
0.0.5 1.7.2014 Draft Helmut Heeke SFS contributions
complete, EFS
partly completed.
0.0.6 2.7.2014 Draft Helmut Heeke CFAM SFS + EFS
contributions
available. Tool
problems with
CFAM generation.
0.0.7 2.7.2014 Draft Helmut Heeke Updated.
0.1.0 4.7.2014 Proposed Helmut Heeke All contributions
available,
distributed for
official review.
0.1.1 21.7.2014 Proposed Helmut Heeke Updated after first
review.
CFAM cannot be
generated due to
DOORS tool
problem.
0.1.2 24.7.2014 Proposed Helmut Heeke Minor
modifications.
CFAM cannot be
generated due to
DOORS tool
problem.
0.1.3 28.7.2014 Proposed Helmut Heeke Minor
modifications.
0.2.0 29.7.2014 Proposed Helmut Heeke CFAM complete,
can be generated,
distributed for
review.

Page 6 of 39
0.3.0 8.8.2014 Proposed Helmut Heeke Final review done,
feature is accepted
as ready for
approval (after
review comments
have been worked
in).
0.3.1 11.8.2014 -.- Helmut Heeke New CFAM
created after
comments from
approval review
were worked in.
(Some
contributions from
colleagues missing
due to vacations.)
0.4 10.9.2014 proposed Helmut Heeke New CFAM
generated after all
comments from
approval review
are worked in.
Minor
modification of
info model
(number of LTAC
objects).
Document
distributed for
final check if all
corrections made
are correct.
0.4.1 12.9.2014 proposed Helmut Heeke Updated after
minor comments.
1.0.0 17.9.2014 approved Helmut Heeke Updated after final
minor comments,
distributed as
approved version.
1.1.0 20.2.2015 approved for LTE Helmut Heeke Updated SFS
requirement
TT_LTE_SFS_DP
M.1939 (S1 GTP-
U Path
Supervision -Dual
U-plane IP
addresses).
Contributions for
SRAN added.
Impossible to
create new CFAM
version due to
DOORS
problems.

Page 7 of 39
1.1.0.1 13.3.2015 approved for LTE Helmut Heeke Still not possible
to create CFAM
with official
script, this version
is sort of "hand-
made". (Not
distributed for
review.)
1.1.1 16.3.2015 approved for LTE, Helmut Heeke Document created
proposed for after installation
SRAN of new DOORS
version (9.5). No
changes in
contents,
distributed for
review in SRAN
group.
2.0.0 24.3.2015 approved for LTE Helmut Heeke Status CP1 & CP2
CP1 & CP2 for declared for
SRAN SRAN after
review of SFS
level
requirements.
2.1 12.5.2015 approved for LTE Helmut Heeke SRAN parts
proposed for updated after
SRAN delivery of OAM
contributions.
Transport EFS
contributions
included.
Distributed for
SRAN SFS level
internal pre-
review.
2.2 13.5.2015 approved for LTE Helmut Heeke Distributed for
proposed for SRAN SFS level
SRAN review.
2.3 21.5.2015 Approved for Helmut Heeke Approved after
SRAN final review held
on 13.5.2015.
3.0 22.6.2015 Approved for Helmut Heeke New CFAM
SRAN generated after
discussions and
clarifications
regarding
specification
processes for
SRAN. No
changes in
technical content.
Distributed for
internal review.

Page 8 of 39
3.1 26.6.2015 Approved for Helmut Heeke No comments
SRAN received in
internal review,
forwarded for
approval and
storage in official
SFS folder.

1.1.2 Feature overview

1.1.2.1 LTE1771/RP000770 Dual U-plane IP addresses

LTE1771: Dual U-plane IP addresses:

The feature introduces the possibility of using a second U-plane IP-address per eNB, which
permits traffic separation based on the two U-plane addresses.

This provides for operators a possibility of distributing the S1 U-plane traffic to those two IP
addresses, which enables the utilization of 2 physical Ethernet interfaces (2xGE, or 2xFE),
and/or different paths through the transport network simultaneously. In all cases, data packets in
a flow remain in sequence order.

Several LTE system features have to interact with LTE1771 in order to establish a higher user
data throughput, or routing user traffic over different network paths. Required are
feature LTE649 (for VLAN support and VLAN aware MAC learning)
feature LTE1244 (for source based-routing of uplink traffic)
in addition it is recommended to monitor path availability via GTPu-path-supervision

See also the CFAM for feature LTE1244 (Source based routing) for additional user scenarios.

IMPORTANT NOTE

For SRAN project, only part of the LTE1771 feature specification is containes in this CFAM
(RP000770). SRAN implementation teams may need to consider the respective LTE1771
CFAM for further information, in particular regarding the interworking of TRSW parts with
Cplane, IP security, and BTSOM.

1.1.2.2 Feature description

The following paragraphs give a more detailed overview over the feature behaviour, focussing
on the address selection algorithm and its consequences. The corresponding binding
requirements are specified in TT_LTE_SFS_DPM (Data Path Management), see chapter 2.

Dual U-plane address selection algorithm for S1 traffic

(1) Paths supervision

The operator is expected to supervise the availability of paths (between eNBs and SGWs)
associated with dual U-plane addresses via GTPu-path-supervision. This means that the
availability status of paths is known (or assumed) at the moment when it has to be decided
which U-plane address to select, and this information is input to the address selection
algorithm.

Note: there may be paths that are not supervised (either because operators do not configure
GTPu-path-supervision for them, or operators connect more than the maximum allowed
number of SGWs supported). A potential consequence is that UEs may be connected to
the LTE system without getting service in case of path failures; however, this may
Page 9 of 39
 happen already in the current implementation and is accepted by operators.

Paths for which no availablility status information is provided are considered available by
the eNB.

(2) Address assignment algorithm for S1 traffic:

A UE connected to the LTE system uses one and only one of the dual U-plane IP-addresses
for S1 user traffic. The selection which address to use is made at the moment of context
setup (Initial Context Setup and Handover) .
The assignment of dual U-plane IP-addresses is done per UE (i.e., all S1 data bearers
belonging to the same UE use the same U-address [either U1 or U2])
The eNB monitors the number of UEs assigned to dual U-plane IP-addresses U1 and U2
For the selection which U-plane IP-address to use, the following algorithm is executed:

if both paths are available:

Let
NU1= number of UEs using U1;
NU2= number of UEs using U2;
IF NU1 < NU2 THEN assign as next address U1 ELSE assign U2

if one path is not available
=> use the other, available U-plane address
(Note: for GBR traffic, only up to the limit accepted by TAC)

A UE always uses the same U-plane IP-address for both uplink and downlink traffic.

Rationale:

(1) This algorithm implements the rule "always select the least used available U-plane
address" (where usage is measured by the number of UEs assigned to each U-plane address).
This ensures optimum load distribution in an environment where connections are
permanently set-up and released.

(2) The UE traffic flows are kept intact.

(3) In case a path becomes temporarily unavailable and afterwards available again, this
algorithm enforces fast return to an approximate 50% load distribution (new connections are
assigned to the respective U-plane address until 50% of UE distribution is accomplished).

(4) The case that both paths are unavailable corresponds to an exceptional situation (loss of
connection of eNB to SGW) which shall be handled like in the current system when
LTE1771 is not active.
Current behavior is: If a GTP-U path becomes unavailable, all impacted UEs will be
released using S1 partial reset. This behavior is expected to be continued, independent if one
or both pathes become unavailable.

Notes

The specified address selection algorithm has a number of important consequences:

About half of the UEs are assigned to each U-plane address. Accordingly, ~50% S1 user
traffic load per U-plane IP-address (on average, over time) can be expected.
Assignment of U-plane IP-addresses is only based on load-distribution (no quality based
address assignment).
Page 10 of 39
 No distinction of traffic types (GBR and nonGBR of a UE go over the same path)
Because the algorithm distributes the user traffic approximately to 50% to each U-plane
address, it is recommended that external Ethernets should be of the same kind (both GE
or FE, but not mixed GE/FE).

Dual U-plane address selection algorithm for X2 traffic (data forwarding)

X2 traffic of a UE is always mapped to the main U-plane address U1.

Rationale:

This is in line with current C-plane implementation. Also, X2 user traffic is expected to be very
small compared to S1 traffic, so a possible a-symmetry in traffic load distribution can be
accepted.
Behaviour in case of path failure (S1 traffic)

If a path which is supervised via GTPu-path-supervision is signaled as "unavailable", all

bearers associated with those UEs which are connected over this path are released by eNB.
The other UEs associated with the non-failing GTPu path remain operational (= are not
released)

Rationale:

This re-uses the same mechanisms as in the current GTPu-path-supervision implementation.

Note that no new connections are accepted for a failed path (but assigned to the available path
instead; this is a consequence of the address selection/load distribution algorithm) until the
failed path becomes operational again.

1.1.3 Open issues

-none-

1.1.4 Decisions
Date Description & reference (if any)
29.4.2014 FZM will only support 1 aspect of this feature:
dual U-plane virtual IPs to support redundant
IP paths, but not the 2nd aspect of this feature:
FZM will still support only 1 physical interface
for U-plane (i.e. 1 main backhaul port).

1.1.5 Common Feature analysis Module (CFAM) team members and their roles
CFAM Team Members
Role Name I: Inspector K: Key Inspector
(Phase 1 / Intermediate / Final
Review)
CFAM leader Helmut Heeke K/K/K

Page 11 of 39
SFS Author Helmut Heeke K/K/K if cat impacted
Ralf Krannich
Konrad Koller
Alexander Schierle
Hinrich Eilts
Mathias Pieroth
BTS Feature owner Andreas Schneider K/K/K if BTS impacted
BTS contributor Minna Ruonala K/K/K if appointed
Niraj Nanavaty
Marcin Krzyzowski
Andrzei Gawron
BTS SW Development <from all impacted BTS SCs, -/I/K if BTS impacted
to be named by BTS FO>
BTS Integration and <to be named by BTS FO if -/I/K if BTS impacted
Verification IV BTS is impacted>
OMS Author <to be named if OMS is K/K/K if OMS impacted
impacted, case-by-case
decision with the help of
operability expert
/contributor>;
OMS prime contact for
assignment: Pivi Kaste, Mari
Maki Kullas, Joan Maris Rosos
NetAct Author <to be named if NetAct is K/K/K if NetAct impacted
impacted, case-by-case
decision with the help of
operability expert/contributor>;
NetAct prime contact for
assignment: Jrgen Grge

1.1.6 Other stakeholders and their roles

Role Name I: Inspector K: Key Inspector

(Phase 1 / Intermediate / Final
Review)
PLM (technical) Stefan Krafft K/I/I (K/I/K only if feature
scope changed)
SyVe Matthias Hipp K/I/K
Carsten Block
Muhammad Zaman
SFS category leader (lead Esa Metl K/I/K
category)
SFS category leader (other Use: nsn-lte-sfs-cat- K/I/I if no impact or impact,
categories) leader@mlist.nsn-inter.net but SFS author assigned
BTS technical manager <to be named by BTS FO if I/-/I if BTS impacted
BTS is impacted>
BTS Requirement Area <to be named by BTS FO if I/-/I if BTS impacted
Manager (RAM) BTS is impacted>
BTS Supporting Product <to be named by BTS FO if -/-/I if BTS impacted
Owner (SPO) BTS is impacted>
BTS Specifcation Development <to be named by BTS FO if I/-/K if BTS impacted
Team (SDT) leader BTS is impacted>
Page 12 of 39
PDDB Coordinator PDDB: Frank Schleuss -/I/I if impacted
Migration specialist I_LTE_OAM_MIGRATON_S -/I/I if PDDB parameter is
PEC_GMS DG impacted
RISE Coordinator RISE: -/I/I if impacted
- Martyna Marcinkowska (FM)
- Joanna Nitka (counter)
BTS property coordinator BTS site solution feature only -/-/I if impacted
for final review; to be nambed
by BTS FO
BTS Site Manager Reviewer Mika Pyykkonen I/I/I if impacted
SFS specification project Mgnr Jens Teubert (FDD), Michael I/I/I
Heilig (TDD)
BTS specification project Mgnr Jari Hautala (FDD), Xianhua I/I/I if BTS impacted
He (TDD)
OMS reviewer <optional, case-by-case I/I/I if appointed
decision with the help of
operability expert /
contributor>;
OMS prime contact: Pivi
Kaste, Mari Maki Kullas,
Joan Maris Rosos
NetAct reviewer <optional, case-by-case I/I/I if appointed
decision with the help of
operability expert /
contributor>
If structural changes are done
in BTS info model, then review
is mandatory;
prime contact: Jrgen Grge
Network Engineering Reviewer <optional> -/-/I if appointed

CuDo Jrgen Kern -/-/I if appointed

SRAN contact persons (since Pattikangas, Esko
Jan 2015) Nagelkraemer, Thomas
Karhula, Jari
Deichmann, Volker
Metsala, Esa
Isoniemi, Matias
Broman, Jouni
Niemela, Henri
Tormanen, Jouko

1.1.7 Terms and abbreviations

U1 In the context of LTE1771, the U-plane address
specified by OAM parameter
uPlaneIPAddress (in case IP version 4 is used),
or uPlaneIPv6Address (in case IP version 6 is
used).
U2 In the context of LTE1771, the U-plane address
specified by OAM parameter
uPlaneIPAddress2 (in case IP version 4 is
used), or uPlaneIPv6Address2 (in case IP
version 6 is used).

Page 13 of 39
MBH Mobile Backhaul

1.1.8 References

1.1.9 IPR Notes

1.2 Stakeholder Requirements

1.2.1 Stakeholder Requirements (from Stakeholder Requirement module)

These are copies from the original requirements, do not edit or add any links!

1.2.2 Additional Stakeholder Requirements (edited here)

1.3 Feature Description

1.3.1 Feature Scope

See chapter 1.1.2 and references mentioned there.

1.3.2 Definition on dependencies between features

1.3.2.1 Interdependent features

LTE125:IPv6 for U/C-Plane, https://focalpoint-
prod.inside.nsn.com/fp/servlet/Login?go=38,1711
It shall be possible to use LTE1771 with IPv6

LTE505:Transport Separation for RAN Sharing, https://focalpoint-

prod.inside.nsn.com/fp/servlet/Login?go=38,2612
LTE1771 and LTE505 are mutually exclusive

LTE649:QoS aware Ethernet switching, https://focalpoint-

prod.inside.nsn.com/fp/servlet/Login?go=38,1725
VLAN and Qos aware Switching (for VLAN aware MAC learning) is required for
LTE1771

LTE1117:LTE MBMS, https://focalpoint-prod.inside.nsn.com/fp/servlet/Login?go=38,8180

LTE1771 and MBMS are functionally independent from one another, because MBMS
traffic always uses different IP addresses for user traffic than LTE1771.
However, in LTE1117, MBMS traffic is assigned to a dedicated L2-interface (operator
selectable), which may cause an a-symmetric traffic load distribution on external
interfaces. (LTE1771 aims to achieve an approximate 50% traffic load distribution.) This
is acceptable because a potential asymmetry caused by MBMS traffic is expected to be
small compared to the total traffic load.
MBMS traffic is real-time traffic and under control of mbTAC, hence must be factored in
TAC configuration by operator (as is the case also when LTE1771 is not used).

LTE1244:Source based routing, https://focalpoint-

prod.inside.nsn.com/fp/servlet/Login?go=38,10860
Source based routing is necessary in order to separate uplink traffic based on U-addresses.

LTE1401:Measurement based TAC, https://focalpoint-

prod.inside.nsn.com/fp/servlet/Login?go=38,15961

Page 14 of 39
 MB-TAC is applied to the sum GBR traffic of both U-plane addresses; operators must
consider this in the mbTAC configuration.

1.3.2.2 Affected features

-none-

1.3.2.3 Related features

-none-

1.3.3 Alternative Solutions and Selected Solution (in End User point of view)

1.4 Definition of User Scenarios

1.4.1 Operator Scenarios (Use cases)

Actors:

Preconditions:

Hardware requirements:

Required features:

Description:

Configure BTS:

Configure RNC:

Configure OMS/ NetAct

Alarms:

Measurements:

Post-conditions:

Exceptions:

1.4.2 Feature Management Scenarios

1.4.2.1 Feature Activation Scenarios

Actors:

Preconditions:

Hardware requirements:

Page 15 of 39
 Required features:

Description:

Configure BTS:

Configure RNC:

Configure OMS/ NetAct

Alarms:

Measurements:

Post-conditions:

Exceptions:

1.4.2.2 Feature Deactivation Scenarios (optional)

1.4.3 Impact on System Performance

1.4.4 Impact on System Capacity

LTE1771 may be used to increase the user data throughput of the network (eNB <=> SGWs): if
e.g. 2x 1GE is used for connecting an eNB to the transport network, theoretically up to 2 Gb/s
can be achieved.

See chapter 1.1.2.1 and references mentioned there for further details.

1.4.5 Licensing

1.4.6 Other User Scenarios

1.5 Summary of Feature phasing

Definition of phasing
WCDMA Phase ID LTE Phase ID Phase description Affected Network
Elements
use syntax description
RAN<feature
Component
ID>_<character>
RAN123_1 LTE456_A example: common
phase for LTE and
WCDMA
RAN123_2 - example: this phase is
valid for WCDMA
only
- LTE456_B example: this phase is
valid for LTE only

Page 16 of 39
1.6 SyVe and I&V aspects

1.6.1 O&M System Performance

1.6.2 Feature Testability Analysis

1.6.3 Define the needed configurations

1.7 Impact to NE external interfaces

1.7.1 Interfaces between different NEs

1.7.1.1 Interfaces between BTS and RNC

1.7.1.2 Interfaces between RNC and OMS

1.7.1.3 Interfaces between OMS and NetAct

1.7.1.4 Interfaces between BTS and OMS

1.7.1.5 Interfaces between BTS and NetAct

1.7.1.6 Interfaces between RNC and NetAct

1.7.1.7 Interfaces between OMS and NetAct

1.7.2 Layer 1 - Layer 3 interface impacts between UE and RAN

1.7.2.1 RNC - UE interface

1.7.2.2 BTS - UE interface

1.7.3 Interface between RAN and CN

1.7.3.1 Iu-CS

1.7.3.2 Iu-PS

1.8 DFMEA

1.8.1 DFMEA Outputs

1.8.1.1 1st level DFMEA status

1.8.1.2 2nd level DFMEA status

Page 17 of 39
2 RAN System Level Requirements
These are copies from the original requirements, do not edit or add any links!
RP000770 - LTE Dual U-plane IP addresses

2.1 Requirements from OM_GEN_SFS_TNL

/RA System General Modules/Operability/OM_GEN_SFS_TNL current
v.5.0V61.0_FL15A_14.06

2.1.1 High level requirements

2.1.1.1 Fault Management

2.1.1.1.1 LTE1771 - Dual U-Plane IP Addresses

In case of a faulty GTP-U path the already introduced fault "GTP-U Path Failure" shall be raised
and shall contain the related U-plane address in the additional info field.

2.1.2 Management requirements

2.1.2.1 Containment-Tree related to Transport Network Layer

2.1.2.1.1 Application related Object Model

2.1.2.1.1.1 SRAN 16.2

2.1.2.1.1.1.1 RAT specific applications

2.1.2.1.1.1.1.1 S1/X2
Class diagramm:

Page 18 of 39
Page 19 of 39
2.1.2.2 Operational Use Cases (pooled in Operability Functional SFS)

2.1.2.2.1 Application related Operator Use Cases

2.1.2.2.1.1 SRAN

2.1.2.2.1.1.1 LTE Dual U-plane IP addresses (RP000770)

2.1.2.2.1.1.1.1 Configuration of second U-plane IP address

The operator wants to configure the system that Dual U-plane IP addresses can be used.

Actors
Operator: The user at the Management System remotely or locally

Pre-conditions

SBTS is in service.
Management System is in service and the O&M connection to SBTS is established.
User Plane IPv4 address ipV4Address1 in uPlaneList of object SBTS/BTSSCL is
configured different to the value 0.0.0.0.
User Plane IPv4 address ipV4Address2 in uPlaneList of object SBTS/BTSSCL is
configured to the value 0.0.0.0. (default).

Main Flow

Operator edits the parameter ipV4Address2 of the MOC instance SBTS/BTSSCL with a
value which is matching an IP address configured in "localIpAddr" of "IPIF" and is
different to the IP address defined for ipV4Address1.
Operator downloads and activates the configuration changes.
SBTS stores the parameter values persistently.
SBTS informs the Management System about the changed configuration.
The LTE part of the SBTS is restarted in order to take the parameter values into use.

Post-conditions

The SBTS is using Dual U-plane IP addresses.

Exceptions
If the configured IP address does not match an IP address configured in "localIpAddr" of "IPIF"
or does match to the value configured for ipV4Address1, the SBTS rejects the activation of the
parameter with an appropriate error message indicating that the IP address is incorrect.

2.1.2.2.1.1.1.2 De-Configuration of second U-plane IP address

The operator wants not to use a second U-Plane IP address and wants to configure the system so
that Dual U-plane IP addresses is not used anymore.

Actors
Operator: The user at the Management System remotely or locally

Pre-conditions

SBTS is in service.
NetAct is in service and the O&M connection to SBTS is established.

Page 20 of 39
 Both User Plane IPv4 addresses ipV4Address1 and ipV4Address2 in uPlaneList of object
SBTS/BTSSCL are configured different to the value 0.0.0.0.

Main Flow

Operator edits the parameter ipV4Address2 of the MOC instance SBTS/BTSSCL with a
value matching 0.0.0.0.
Operator downloads and activates the configuration changes.
SBTS stores the parameter values persistently.
SBTS informs the Management System about the changed configuration.
The LTE part of the SBTS is restarted in order to take the parameter values into use.

Post-conditions

The SBTS is using a single U-plane IP address. (the one defined in ipV4Address1)

Exceptions
None

2.1.2.2.1.1.1.3 Management Parameters

The supported configuration parameters are defined in the attached table.

2.1.2.2.2 LTE1771 Dual U-Plane IP Addresses

2.1.2.2.2.1 Fault behavior of LTE1771/RP000770

Frequency
Seldom

Actors
System

Pre-conditions
eNB/SBTS is in service
Feature LTE1771 is activated, actDualUPlaneIpAddress is set to true
Feature RP000770 is configured: ipV4Address2 in uPlaneList of object SBTS/BTSSCL

Main Flow

-Event: One of the two configured U-plane paths is faulty

-Reaction: Fault "GTP-U Path Failure" is raised. The fault contains in the additional info
the U-plane address of the faulty path.
-Reaction: Fault is sent contained in the BASE STATION CONCONNECTIVITY
DEGRADED alarm to the management system.
- Event: Secondary of the U-plane paths is faulty.
-Reaction: Fault "GTP-U Path Failure" is triggered and raised again. The fault contains
in the additional info the secondary U-plane address of the faulty path.
-Reaction: Fault is sent contained in the BASE STATION CONNECTIVITY
DEGRADED alarm to the management system.
-Event: The secondary U-plane path is available again.

Page 21 of 39
 -Reaction: The related "GTP-U Path Failure" (which contains in the additional info the
secondary U-plane address) is cleared.
-Reaction: The related BASE STATION CONNECTIVITY DEGRADED alarm is
cleared and the related notification is sent to the management system.
-Event: Both U-plane paths are available again.
- Reaction: The fault "GTP-U Path Failure" (which contains in the addtional info the U-
plane address) is cleared.
- Reaction: The related BASE STATION CONNECTIVITY DEGRADED alarm is
cleared and the related notification is sent to the management system.

Post-conditions
Both U-plane paths are available

Exceptions
None

2.2 Requirements from TT_GEN_SFS_CAPACITY AND PERFORMANCE

/RA System General Modules/Transmission and Transport/TT_GEN_SFS_CAPACITY AND
PERFORMANCE current v.5.0V61.0_FL15A_14.06

2.2.1 Capacity, performance and overload control

2.2.1.1 Capacity

2.2.1.1.1 IP based S1/X2 - LTE Adapter

Number of paths for GTP-U path supervision

The maximum number of paths to be supervised with GTP-U path supervision shall be 64.

Rationale:
TT_CP.927 requires the support of 32 S-GWs. With RP000770 there are two user plane IP
addresses for the operator. This results in a maximum of 64 paths to be supervised.

2.3 Requirements from TT_GEN_SFS_IP TRANSPORT

/RA System General Modules/Transmission and Transport/TT_GEN_SFS_IP TRANSPORT
current v.9.1

2.3.1 Functional requirements

2.3.1.1 IP Connection Admission Control

2.3.1.1.1 LTE
TAC support for dual U-plane IP addresses

mbTAC shall support dual U-plane IP-addresses (feature LTE1771). If that feature is enabled,

mbTAC shall include GBR traffic for both U-plane IP-addresses in mbTAC measurements
the mbTAC decision algorithm for the sum GBR traffic (both U-plane addresses) shall be the
same as for the single U-plane case

This way, mbTAC limits the sum GBR traffic of both U-plane IP-addresses (not: GBR traffic
per U-plane address); in other words, traffic admission control is done per eNB!

Important

Page 22 of 39
If two external links are used, the maximum configured value for mbTAC limit is recommended
to be smaller than 50% of total link capacity in order to avoid a theoretically possible
overload situation in case one link fails. A hint to operators in Customer Documentation
shall state that clearly.

Rationale:

This TAC behaviour is optimum and sufficient in case of single MBHs, in particular the most
important use case of this feature (increasing throughput of the transport network). In this case,
the alternative (performing admission control per path) leads to sub-optimum bandwidth
utilization for GBR traffic, e.g. when a link selected for a new connection cannot be used
because it has no sufficient capacity anymore, but the other link would so - the new connection
would be rejected in this case. (The same mechanisms as in the current mbTAC implementation
are re-used. The implementation cost for a possible improvement of this behaviour was seen as
too high compared to the benefit.)

In case of 2 MBHs one TAC instance per link could be a better implementation, because an
operator could control each link separately (at the cost of sub-optimum utilization).

In the evaluation of the two possiblities the first one was considered the much more probable
application case, so one TAC instance for the sum GBR traffic is used.

Note

The question which TAC limits to choose is in the end determined by possible bottlenecks
somewhere in the MBH (not necessarily at the eNB), which needs to be anlyzsed by
operators depending or their network configurations. (See feature LTE1401.)

2.3.1.2 Dual Uplane IP addresses

Applicability of Dual U-plane IP addresses

The NE shall support two U-plane IP addresses.

It shall be possible to distribute S1 U-plane traffic to those two IP addresses in a way that UE
flows remain intact.

Rationale:
This allows the possibility of separating S1 user traffic based on the two U-plane IP addresses.
Distributing user traffic to two U-plane addresses enables the utilization of two physical
Ethernet interfaces (2xGE, or 2xFE) and/or different paths through the transport network while
keeping UE flows intact.

Note: The support of two U-IP-plane addresses is one pre-condition for user traffic separation,
but several features have to inter-operate to finally reach that goal. See CFAM user scenarios
and "acceptance criteria" for further details.

Implementation Note: For SBTS it is left to SW architecture to define the general approach if a
BTS or RAT reset is required for applying the configuration of a U-plane application IP address.
Usage of IPv4 and IPv6 for dual U-plane IP addresses

It shall be possible to use for the two U-plane IP addresses either IPv4 or IPv6. (Mixed versions,
like e.g. U1 being IPv4 and U2 being Ipv6, are not allowed.)

Page 23 of 39
Rationale:
The eNB already supports IPv4 and IPv6 addresses for single U-plane address. Both U-plane
addresses shall use the same IP-version.

Usage of IPv4 for dual U-plane IP addresses

The BTS shall use IPv4 as IP version for the two U-plane application IP addresses.

Rationale:
In the scope of SRAN16.2 other adapter features (S1/X2 or Iub) only allow IPv4. For other
adapters there are separate features for IPv6 in later SRAN releases.

2.4 Requirements from TT_GEN_SFS_LAYER 4

/RA System General Modules/Transmission and Transport/TT_GEN_SFS_LAYER 4 current
v.9.0V61.0_FL15A_14.06

2.4.1 Functional requirements

2.4.1.1 LTE User Plane Transport

2.4.1.1.1 GTP-U Protocol Architecture

2.4.1.1.1.1 Dual U-plane IP addresses

Re-using existing functions for 'Dual U-plane IP addresses'
The eNB is fully compliant to 3GPP TS 29.281 and the eNB supports all essential GTP-U
functions as specified in 3GPP specification TS 29.281.
When LTE1771 is enabled, the eNB shall support all GTP-U signaling as well as U-plane
related functions also at the second local GTP-U path endpoint, in the same manner, as specified
in DPM.SFS for the main local GTP-U path endpoint.
Functional requirements are detailed in LTE_DPM_SFS. Please refer to LTE_DPM_SFS
requirements linked to LTE1771.
2 local GTP-U Path Endpoints / GTP-U paths to S-GW
When LTE1771 feature is enabled, the eNB S1 application shall be bound additionally to a
second local GTP-U path endpoint (local U-Plane IP address U2).
The S-GW shall be reachable via both local GTP-U path endpoints, the main local GTP-U
path endpoint using the local U-Plane IP address U1 and
the second GTP-U path endpoint using the local U-Plane IP address U2.
One local GTP-U Path Endpoint / GTP-U path to adj. eNB
Even for the case the LTE1771 feature is enabled, the eNB X2 application shall not be bound to
a second local GTP-U path endpoint (local U-Plane IP address U2). The main local GTP-U path
endpoint (local U-Plane IP address U1) shall be used.

2.4.1.1.2 GTP-U Path Functions

2.4.1.1.2.1 Dual U-Plane IP addresses

GTP-U Path Management messages
When LTE1771 is enabled, all the GTP-U Path Management Messages implemented, on the S1
interface, for the main local GTP-U path endpoint, the eNB shall also support at the second local
GTP-U path endpoint, e.g. the GTP-U Path Supervisions ECHO REQUEST/RESPONSE
messages.
S1 GTP-U Path Supervision
When LTE1771 is enabled, and when the operator has activated GTP-U path supervision to a S-
GW's IP address, the eNB shall supervise both GTP-U paths towards that S-GW, in parallel.
Page 24 of 39
The existing alarm for S1 GTP-U Path Failures needs to be updated such that the eNB can
indicate the specific failed GTP-U path to the S-GW. In case of a GTP-U path failure, the
concrete failed GTP-U path shall be indicated in the alarm message by the starting and the
endpoint of the specific GTP-U path.
When one GTP-U path isnt available anymore to the S-GW, the eNB shall raise the alarm
GTP-U Path Failure, indicating the specific GTP-U path. The severity shall be major. The
reported alarm shall be BASE STATION CONNECTIVITY DEGRADED.
When also the second GTP-U path isnt available to the S-GW, the eNB shall raise the alarm
GTP-U Path Failure, indicating the specific GTP-U path. The severity shall be major. The
reported alarm shall be BASE STATION CONNECTIVITY DEGRADED.
In case LTE1771 is enabled, a note shall be added in the alarm text like the following The S-
GW might still be reachable. Please check whether a further GTP-U path has failed to that S-
GW. If so the S-GW isnt reachable anymore.

Note 1:
In the current implementation, the existing alarm text for the S1 GTP-U Path Failure already
contains the information about the starting and the ending endpoint of the GTP-U path meaning
the local eNB U1 plane IP address and the S-GW IP address.

2.4.1.1.3 GTP-U Tunnel Functions

2.4.1.1.3.1 GTP-U Tunnel Creation

2.4.1.1.3.1.1 Dual U-Plane IP addresses

S1 U-plane IP address selection during eNB UE Context Creation (Use Cases)
eNB UE Context Creation results in S1 U-plane IP address selection. The following section
shows the use cases. Additionally the acceptance criteria are added at the bottom of each use
case, so that the correct U-plane IP address assignment can be verified.
Use Case #1: eNB UE Context Creation when both S1 GTP-U paths are available
Preconditions:
Case A: The GTP-U path supervision isnt activated to the S-GW address signaled by S1AP
Case B: GTP-U paths are supervised to the S-GW address and both GTP-U paths are available

Description:
The eNB receives a request to create an UE context:
A.Reception of S1AP: INITIAL CONTEXT SETUP REQUEST (when working as eNB)
B.Reception of S1AP/X2AP: HANDOVER REQUEST (when working as TeNB)
The eNB executes the GTP-U path endpoint/U-plane Address assignment algorithm, described
like the following
Let
NU1= number of established UE contexts using U1 (main local GTP-U path
endpoint);
NU2= number of established UE contexts using U2; (second local GTP-U
path endpoint)
IF NU1 < NU2 THEN the eNB shall assign as next address U1 (main local GTP-U path
endpoint) ELSE assign U2 (second local GTP-U path endpoint).
Postconditions:
The eNB has selected the local U-plane IP address (GTP-U path endpoint)
The eNB has assigned the selected local U-plane IP address (for subsequent S1 UL and DL
GTP-U tunnel creation) to the UE context.

Acceptance Criteria:
The correct U-plane IP address assignment shall be checked by the following acceptance
criteria.
A. When working as eNB:
1.For the case NU1 was < NU2 before UE context creation, when the eNB is
receiving E-RAB SETUP REQUEST, the related UL and DL S1 GTP-U tunnels
are using U1 (U-plane is sent and received from/at U1)

Page 25 of 39
 2.For the case NU1 was NU2 before UE context creation, when the eNB is
receiving E-RAB SETUP REQUEST, the related UL and DL S1 GTP-U tunnels
are using U2 (U-plane is sent and received from/at U2)

B. When working as TeNB:

1.For the case NU1 was < NU2 before UE context creation, when the eNB is
receiving S1AP/X2AP: HANDOVER REQUEST, the related UL and DL S1 GTP-
U tunnels are using U1 (U-plane is received at U1)
2.For the case NU1 was NU2 before UE context creation, when the eNB is receiving
S1AP/X2AP: HANDOVER REQUEST, the related UL and DL S1 GTP-U tunnels are using U2
(U-plane is received at U2).
Use Case #2: eNB UE Context Creation when one S1 GTP-U path has failed
Preconditions:
The GTP-U path supervision is activated to the S-GW address signaled by S1AP AND one S1
GTP-U path has failed.

Description:
The eNB receives a request to create an UE context:
A.Reception of S1AP: INITIAL CONTEXT SETUP REQUEST (when working as eNB)
B.Reception of S1AP/X2AP: HANDOVER REQUEST (when working as TeNB)
The eNB selects the available local U-plane address (GTP-U path endpoint).

Postconditions:
The eNB has selected the local S1 U-plane IP address (GTP-U path endpoint)
The eNB has assigned the selected local U-plane IP address (for subsequent S1 GTP-U tunnel
creation) to the UE context.

Acceptance Criteria:
The correct U-plane IP address assignment shall be checked by the following acceptance
criteria.
A. When working as eNB:
1.For the case U1 GTP-U path has failed before UE context creation, when eNB
is receiving E-RAB SETUP REQUEST, the related UL and DL S1 GTP-U tunnels
are using U2 (U-plane is sent and received from/at U2)
2.For the case U2 GTP-U path has failed before UE context creation, when eNB
is receiving E-RAB SETUP REQUEST the related UL and DL S1 GTP-U tunnels
are using U1 (U-plane is sent and received from/at U1)

B. When working as TeNB:

1.For the case U1 GTP-U path has failed before UE context creation, when the
eNB is receiving S1AP/X2AP: HANDOVER REQUEST, the related UL and DL
S1 GTP-U tunnels are using U2 (U-plane is received at U2)
2.For the case U2 GTP-U path has failed before UE context creation, when the
eNB is receiving S1AP/X2AP: HANDOVER REQUEST, the related UL and DL
S1 GTP-U tunnels are using U1 (U-plane is received at U1).
Use Case #3: eNB UE Context Creation when both S1 GTP-U paths have failed
Preconditions:
The GTP-U path supervision is activated to S-GW address signaled by S1AP AND both S1
GTP-U paths have failed.

Description:
The eNB receives a request to create an UE context:
A.Reception of S1AP: INITIAL CONTEXT SETUP REQUEST (when working as eNB)
B.Reception of S1AP/X2AP: HANDOVER REQUEST (when working as TeNB)
The eNB doesnt create a UE context.

Postconditions:
The eNB rejects the S1AP: INITIAL CONTEXT SETUP REQUEST

Page 26 of 39
Acceptance Criteria:
It shall be verified that the eNB doesnt allocate the UE context resources by means of the
following acceptance criteria
A. When working as eNB:
1.For the case both GTP-U paths have failed before UE context creation', when
the eNB is receiving E-RAB SETUP REQUEST, the related UL and DL S1 GTP-
U tunnels arent created. (The eNB responds with E-RAB SETUP FAILURE)

B. When working as TeNB:

1.For the case both GTP-U paths have failed before UE context creation', when
the TeNB is receiving S1AP/X2AP: HANDOVER REQUEST, the related UL and
DL S1 GTP-U tunnels arent created. (The eNB responds with HANDOVER
REQUEST FAILURE).
Assignment of local S1 GTP-U path endpoint (U-plane IP address) during eNB UE Context
Creation
For both cases,
A.When working as eNB, due to reception of S1AP: INITIAL CONTEXT SETUP
REQUEST the eNB triggers 'UE context creation' for E-RAB bearer.
B.When working as TeNB, due to reception of S1AP/X2AP: HANDOVER REQUEST,
the eNB triggers 'UE context creation' at eNB for the related E-RAB bearer.
The eNB shall apply local S1 U-plane IP address selection, as specified by the use cases
described in TT_LTE_SFS_DPM.1945, TT_LTE_SFS_DPM.1946 and
TT_LTE_SFS_DPM.1947. The eNB shall assign the selected local U-plane IP address to the UE
Context.

Note:
The eNB performs the UE context related subsequent creations of UL and DL S1 GTP-U
tunnels for both trigger conditions described above in case A. and B.
It can be verified whether the eNB SW has assigned the correct local U-Plane IP address to each
S1 GTP-U tunnel by the acceptance criteria descriptions of TT_LTE_SFS_DPM.1945,
TT_LTE_SFS_DPM.1946 and TT_LTE_SFS_DPM.1947.
At every application of S1 GTP-U tunnel creation, the eNB checks the availability of Transport
Resources. When transport resources are available, the GTP-U tunnel is created. (The described
functions in that note are already implemented).
Used local GTP-U path endpoint (U-plane IP address) for Fwd S1 GTP-U tunnel creation
For both cases,
A.Working as SeNB, when the eNB is receiving the S1AP: HANDOVER COMMAND
B.Working as TeNB, when the eNB is receiving S1AP: HANDOVER REQUEST,
the eNB shall use always the local U plane Address (local GTP-U path endpoint) for the Fwd S1
GTP-U tunnel creation that the eNB has assigned during previous eNB UE context creation.

Note:
The availability of the transport resources isnt checked.
Case A (SeNB): The eNB UE context is assigned due to reception of previous INITIAL
CONTEXT SETUP. The Fwd S1 GTP-U tunnel is created.
Case B (TeNB): When the previous eNB UE context creation was successful, the Fwd S1 GTP-
U tunnel is created.
Used local GTP-U path endpoint (U-plane IP address) for Fwd X2 GTP-U tunnel creation
For both cases,
A.Working as SeNB, when the eNB is receiving the X2AP: HANDOVER REQUEST
ACKNOWLEDGE
B.Working as TeNB, when the eNB is receiving X2AP: HANDOVER REQUEST,
after previous eNB UE context creation, the eNB shall use always the local U1 plane Address
(main local GTP-U path endpoint) for the Fwd X2 GTP-U tunnel creation, also for the case the
LTE1771 is enabled.

Note:
The availability of the transport resources isnt checked.
Case A (SeNB): The eNB UE context is assigned due to reception of previous INITIAL
CONTEXT SETUP. The Fwd X2 GTP-U tunnel is created.
Page 27 of 39
Case B (TeNB): When the previous eNB UE context creation was successful, the Fwd X2 GTP-
U tunnel is created.

2.4.1.1.3.2 GTP-U Tunnel Management

GTP-U Tunnel Management messages -Dual U-plane IP addresses
When LTE1771 is enabled, all the GTP-U Tunnel Management Messages implemented, on the
S1 interface, for the main local GTP-U path endpoint, the eNB shall also support at the second
local GTP-U path endpoint, e.g. Error Indication or End Marker.

2.5 Requirements from TT_GEN_SFS_NETWORK CONFIGURATION

/RA System General Modules/Transmission and Transport/TT_GEN_SFS_NETWORK
CONFIGURATION current v.10.1

2.5.1 Feature application scenarios

2.5.1.1 Dual U-plane IP-addresses

Basis user scenario: two networks, main goal is routing via separate networks

(Note: IP addresses are example values.)

Two separate MBH networks

DL/UL traffic is distributed to both links based on BTS IP addresses
Decision criterion: load based (on average over time, ~ 50 % of load per link)
Ingress and egress traffic of all bearers belonging to the same UE goes over the same path

Basis user scenario: one network, main goal is increasing throughput

(Note: IP addresses are arbitrary example values.)

Page 28 of 39
 One MBH network, two external links to eNB
DL/UL traffic is distributed to both links based on BTS IP addresses
Decision criterion: load based (on average over time, ~ 50 % of load per link)
Ingress and egrepathss traffic of all bearers belonging to the same UE goes over the same

Basis user scenario: one network, main goal is to separate traffic in the network (not in eNB)

(Note: IP addresses are arbitrary example values.)

Note: this is the only use case FZM supports.

One MBH network, one external link to eNB

Two U-addresses are used, but eNB supports only one physical backhaul interface
All DL/UL traffic goes over the same physical link

Failure of link using address U2

Precondition
eNB is up and running
network and eNB configuration is according to figure AC1 example set-up;
feature LTE1771 is active (two U-plane addresses are used),
FSMr3 is used
1 Gb/s Ethernet is used
Transport network uses IPv4
A single mobile backhaul network is used (compare TT_NCONF.807 use case)
MBMS is not used

Event
Link associated with U-plane address U2 fails.
(Note: in system test, this may be achieved by unplugging link cable.)
Postcondition
GTPu-path-failure alarm is raised
(Note: the default value for raising the GTPu-alarms is 2 seconds; this value may have
been changed by operators. Note however, that the time for detecting the failure
condition [which eventually leads to the alarm] may be much longer, per default 5
min. This, however, is the same situation for the usual case also when LTE1771 is
not active.) The information that U-plane address U2 is affected is in the
addInfo-field of the alarm.

Page 29 of 39
 After the alarm is raised, all existing connections running over link U2 are released
all existing connections running over link U1 are not released
after the alarm is raised, all future connections use link U1 for S1 user traffic
(GBR connections only as long as their sum rate remains below the threshold
configured for TAC, in this example 200 Mb/s)
After failure, link using address U2 becomes operational again

Precondition
eNB is up and running
Network and eNB configuration is according to figure 1 example set-up;
feature LTE1771 is active (two U-plane addresses are used),
FSMr3 is used
1 Gb/s Ethernet is used
Transport network uses IPv4
A single mobile backhaul network is used (compare TT_NCONF.807 use case)
MBMS is not used
Link U2 is failed; eNB is in the state of postcondition of AC#2

Event
After failure, link associated with U-plane address U2 becomes operational again.
(Note: in system test, this may be achieved by re-plugging link cable.)
Postcondition
GTPu-path failure alarm disappears
(Note: the default value for clearing the GTPu-alarms is 2 seconds; this value may have
been changed by operators.).
All existing connections running over link U1 continue to be operational.
after the alarm is cleared, all future connections use link U2 for S1 user traffic until a
roughly 50% distribution UEs and user traffic is achieved.
(GBR connections are accepted only as long as their sum rate remains below the
threshold configured for TAC, in this example 200 Mb/s).
X2 traffic continues to use link U2 (Note: this change is introduced with PR
93149ESPE01)

3 BTS Level Feature User Scenarios and Requirements/User

Stories

3.1 BTS Level Feature User Scenarios

3.1.1 BTS level Feature User Scenario Relationships

3.1.2 BTS Level Feature User Scenario X

3.2 BTS Level Requirements/User Stories

These are copies from the original requirements, do not edit or add any links!
RP000770 - LTE Dual U-plane IP addresses

3.2.1 Requirements from TT_GEN_SFS_CAPACITY AND

PERFORMANCE(EFS)
/RA System General Modules/Transmission and Transport/TT_GEN_SFS_CAPACITY AND
PERFORMANCE current v.5.0V61.0_FL15A_14.06

Page 30 of 39
3.2.1.1 Capacity, performance and overload control

3.2.1.1.1 Capacity

3.2.1.1.1.1 IP based S1/X2 - LTE Adapter

Number of paths for GTP-U path supervision

The maximum number of paths to be supervised with GTP-U path supervision shall be 64.

Rationale:
TT_CP.927 requires the support of 32 S-GWs. With RP000770 there are two user plane IP
addresses for the operator. This results in a maximum of 64 paths to be supervised.

3.2.2 Requirements from TT_GEN_SFS_IP TRANSPORT(EFS)

/RA System General Modules/Transmission and Transport/TT_GEN_SFS_IP TRANSPORT
current v.9.1

3.2.2.1 Functional requirements

3.2.2.1.1 IP Connection Admission Control

3.2.2.1.1.1 LTE
TAC support for dual U-plane IP addresses

mbTAC shall support dual U-plane IP-addresses (feature LTE1771). If that feature is enabled,

mbTAC shall include GBR traffic for both U-plane IP-addresses in mbTAC measurements
the mbTAC decision algorithm for the sum GBR traffic (both U-plane addresses) shall be the
same as for the single U-plane case

This way, mbTAC limits the sum GBR traffic of both U-plane IP-addresses (not: GBR traffic
per U-plane address); in other words, traffic admission control is done per eNB!

Important
If two external links are used, the maximum configured value for mbTAC limit is recommended
to be smaller than 50% of total link capacity in order to avoid a theoretically possible
overload situation in case one link fails. A hint to operators in Customer Documentation
shall state that clearly.

Rationale:

This TAC behaviour is optimum and sufficient in case of single MBHs, in particular the most
important use case of this feature (increasing throughput of the transport network). In this case,
the alternative (performing admission control per path) leads to sub-optimum bandwidth
utilization for GBR traffic, e.g. when a link selected for a new connection cannot be used
because it has no sufficient capacity anymore, but the other link would so - the new connection
would be rejected in this case. (The same mechanisms as in the current mbTAC implementation
are re-used. The implementation cost for a possible improvement of this behaviour was seen as
too high compared to the benefit.)

In case of 2 MBHs one TAC instance per link could be a better implementation, because an
operator could control each link separately (at the cost of sub-optimum utilization).

In the evaluation of the two possiblities the first one was considered the much more probable
application case, so one TAC instance for the sum GBR traffic is used.
Page 31 of 39
Note

The question which TAC limits to choose is in the end determined by possible bottlenecks
somewhere in the MBH (not necessarily at the eNB), which needs to be anlyzsed by
operators depending or their network configurations. (See feature LTE1401.)

3.2.2.1.2 Dual Uplane IP addresses

Applicability of Dual U-plane IP addresses

The NE shall support two U-plane IP addresses.

It shall be possible to distribute S1 U-plane traffic to those two IP addresses in a way that UE
flows remain intact.

Rationale:
This allows the possibility of separating S1 user traffic based on the two U-plane IP addresses.
Distributing user traffic to two U-plane addresses enables the utilization of two physical
Ethernet interfaces (2xGE, or 2xFE) and/or different paths through the transport network while
keeping UE flows intact.

Note: The support of two U-IP-plane addresses is one pre-condition for user traffic separation,
but several features have to inter-operate to finally reach that goal. See CFAM user scenarios
and "acceptance criteria" for further details.

Implementation Note: For SBTS it is left to SW architecture to define the general approach if a
BTS or RAT reset is required for applying the configuration of a U-plane application IP address.
Usage of IPv4 and IPv6 for dual U-plane IP addresses

It shall be possible to use for the two U-plane IP addresses either IPv4 or IPv6. (Mixed versions,
like e.g. U1 being IPv4 and U2 being Ipv6, are not allowed.)

Rationale:
The eNB already supports IPv4 and IPv6 addresses for single U-plane address. Both U-plane
addresses shall use the same IP-version.

Usage of IPv4 for dual U-plane IP addresses

The BTS shall use IPv4 as IP version for the two U-plane application IP addresses.

Rationale:
In the scope of SRAN16.2 other adapter features (S1/X2 or Iub) only allow IPv4. For other
adapters there are separate features for IPv6 in later SRAN releases.

4 RNC High Level Requirements

These are copies from the original requirements, do not edit or add any links!

5 OMS High Level Requirements

Page 32 of 39
These are copies from the original requirements, do not edit or add any links!

6 NetAct High Level Requirements

7 RACS High Level Requirements

8 Impact to BTS Design

NOTE: The information in this paragraph is necessarily not up-to-date after implementation of
the feature has started. The cumulative BTS design information is kept up-to-date in the
documents (formal module paragraphs) stored into the BTS Functional Area Team (FAT)
formal modules, located in WCDMA_BTS/BTS_Requirement folder and structured according
to separate BTS Document Tree definition available in Sharenet-IMS.

Add the comment and date which after the content of this chapter is not updated anymore.

8.1 Impact BTS design phase participants

Impact BTS design phase team members
Role Person name
BTS E2E FO
Moderator / Approver
EFS Author

Impact BTS design phase key inspectors

Role Person name
EFS Author
SA E2E FO
NE implementation
NE I&V

Impact BTS design phase other inspectors

Role Person name
SFS Author

8.2 References

8.3 Static Models (Optional)

8.3.1 Architecture impact diagram

8.3.1.1 Diagram explanation

Page 33 of 39
8.3.2 Description of impacts and impacted system and subsystem components
With the new O&M architecture in SRAN the BTS O&M component is replaced by Megazone.
In the old architecture user plane application addresses were configured in TRSW and then sent
via BTS O&M to C-Plane(RROM). In order to avoid effort in the C-plane it is assumed that
Megazone reads the configured User Plane Addresses from the configuration and forwards them
via existing internal configuration interface to RROM. As a general approach for application
addresses is required this cannot be defined in the scope of RP000770 only but needs to be
defined generally for all features like S1/X2 adapter, Iub adapter etc. in the SW architecture. It is
not described in the sope of this feature. At the time of writing the SBTS only supports to take a
complete Site Configuration File into use and this requrires a BTS reset. When the feature
"Delta Configuration" is introduced this may have further impact on how application IP
addresses are taken into use and what kind of reset is required.

8.4 Dynamic models (Optional)

8.5 Capacity and performance

8.6 Impact to Black Box Modules

8.7 Impact to BTS HW architecture

8.8 Impact to BTS SW architecture

8.9 Radio Platform User Stories and Requirements

These are copies from the original requirements, do not edit or add any links!

8.10 Impact to Radio Platform SW

8.11 Impact to Application SW

8.12 Testability

8.13 Impact to Interfaces

8.13.1 External Interfaces

8.13.2 Internal Interfaces

8.14 Impact to BTS EFS Documents

8.15 Feature splitting in BTS

9 Impact to RNC Design

NOTE: The information in this paragraph is necessarily not up-to-date after the implementation
for the feature has been started. The cumulative RNC detailed level requirements are kept up-to-
date in the RNC EFSes stored into the RNC EFS formal modules, located in
WCDMA_RNC/EFS folder.

Page 34 of 39
Add the comment and date which after the content of this chapter is not updated anymore.

9.1 CFAM Phase 2 RNC participants

CFAM Phase 2 RNC team members
RNC E2E FO
Moderator / Approver
EFS Author

CFAM Phase 2 RNC key inspectors

EFS Author
SA E2E FO
NE implementation
NE I&V

CFAM Phase 2 RNC key inspectors

SFS Author

9.2 References

9.3 Impact to RNC System Domains

9.3.1 Capacity and performance

9.3.2 E2E performance

9.3.3 Testability

9.3.4 Connectivity

9.3.5 Upgradeability

9.3.6 Availability

9.3.7 Operability

9.3.8 Traffic

Page 35 of 39
9.3.9 Security

9.4 Impact to HW architecture

9.5 Impact to SW architecture

9.6 Impact to Interfaces

9.6.1 External Interfaces

9.6.2 Internal Interfaces

9.7 Feature integration steps/phasing in RNC

10 Impact to OMS Design

NOTE: The information in this paragraph is necessarily not up-to-date after the implementation
for the feature has been started. The OMS detailed level requirements are kept up-to-date in the
OMS EFSes stored into the OMS EFS formal modules, located in RA_OMS/EFS folder.

Add the comment and date which after the content of this chapter is not updated anymore.
Optionally short description of the feature from OMS point of view

10.1 CFAM phase 2 OMS participants

CFAM Phase 2 OMS team members
OMS E2E FO
Moderator / Approver
EFS Author

CFAM Phase 2 OMS key inspectors

EFS Author
SA E2E FO
NE Implementation
NE I&V

CFAM Phase 2 OMS other inspectors

SFS Author

Page 36 of 39
10.2 References

10.3 Impact to domains

10.3.1 OMS functional domains

10.3.2 OMS non-functional domains

10.4 Impact to Flexiplatform

10.5 Impact to Testing

10.6 Impact to Customer Documentation

10.7 Impact to 3rd party SW

10.8 Impact to External Interfaces

10.8.1 NWI3

10.8.2 BTSOM

10.8.3 Other external interfaces

10.9 Feature phasing in OMS

11 Impact to RACS Design

11.1 References

11.2 Impact to RACS System Domains

11.2.1 Capacity and performance

11.2.2 E2E performance

11.2.3 Testability

11.2.4 Connectivity

11.2.5 Upgradeability

11.2.6 Availability

11.2.7 Operability

Page 37 of 39
11.2.8 Traffic

11.2.9 Security

11.3 Impact to HW architecture

11.4 Impact to SW architecture

11.5 Impact to Interfaces

11.5.1 External Interfaces

11.5.2 Internal Interfaces

11.6 Feature integration steps/phasing in RACS

11.7 RSM EFS

12 Impact to NetAct Design

NOTE: The information on update dates and CFAM writers in this paragraph should be kept
updated once the feature has been started. The idea is also that all NetAct related requirements
are linked to this chapter and can be analyzed and traced during feature implementation.

Feature name and short description of NetAct areas

Authors on NetAct for differentent areas
Dates for target reviews and changes

12.1 References

12.2 Impact to System domains in NetAct

12.2.1 NetAct Configurator impact

12.2.2 NetAct Performance Management impact

12.2.3 NetAct Fault Management impact

12.2.4 NetAct Traffica impact

12.2.5 Other NetAct system area impacts

12.3 Impact to Interfaces

Page 38 of 39
12.3.1 External Interfaces

12.4 Feature splitting in OMS and Network Elements

12.5 NetAct requirements to Network Element implementation

12.5.1 NetAct Configurator impact

12.5.2 NetAct Performance Management impact

12.5.3 NetAct Fault Management impact

12.5.4 NetAct Traffica impact

12.5.5 Other NetAct system area impacts

13 Feature Detailed BTS Design

Page 39 of 39