openair lte core network user · pdf fileopenair lte core network user plane training session....

April 27, 2017 Openair-cn training - User Plane 1

OAI workshop, BUPT Beijing, 04.27.2017

Openair LTE Core NetworkUser Plane

Training session


OPENAIR-CN training Plan

● Plan– Scope

– Progress

– 3GPP bullets about tunneling

– Openair-cn tunneling

– SPGW software architecture

– Classification of user traffic

– What is missing


SCOPE


OPENAIR-CN trainingScope

● Targeted audience: Code contributors, testers, users of openair-cn.

● Objectives– Save time for willing contributors who want to

understand what is in openair-cn :● Show differences between 3GPP spec and current

implementation.● Show some of internals, API.


Progress made in User plane since 1 year

● Use of OSMOCOM libgtnl and their GTP Linux kernel module contribution in kernel > 4.7.– Removed old design relying on netfilter and GTP

xtables extension.

● Implementation of a dedicated bearer allowing PCEF contribution.


LTE core network scopeScope : Reminder 3GPP LTE Core Network

entities

● LTE network entities :

UE

eNB MME

HSS

SGW PGW

S1-MME

S6-a

S11

S5/S8 SGI S1-U

PCRF

Gxc Gx

Implemented in openair-cn

Implemented in openairinterface5g

Not implemented

S10

SGSNS3

S4RNC

S12(optional tun)

USIM

ME

E-UtranUu

EIR

S13X2


3GPP LTE Tunneling User plane overview

● Protocol stacks overview and S1U/S5 encapsulation

IP

L2

L1

eNB SGW

S1-U

UDP

GTP

IP

L2

L1

UDP

GTP

IP

L2

L1

UDP

GTP

IP

L2

L1

UDP

GTP

MAC

PHY

RLC

PDCP

MAC

PHY

RLC

PDCP

IP IP

PGW

L4

L2

L1

IP

Node

L4

Appli Appli

S5

UE

GTP8

UDP8

IP20

IP L4 AppliL2

LTE-Uu


LTE Tunneling, wireshark view

Tunneling

IPL4

Appli

GTP

UDP

IP


LTE Tunneling port numbers

● 3GPP TS 29.281 section 4.4.2.3 Encapsulated T-PDUs :– The UDP Destination Port number shall be 2152.

It is the registered port number for GTP-U.

– The UDP Source Port is a locally allocated port number at the sending GTP-U entity.


LTE Tunneling fragmentation

● GTPv1 described in 3GPP TS 29.281– Section 4.2.2 IP transport : Unnecessary fragmentation

should be avoided when possible due to the following;● Fragmentation is bandwidth inefficient, since the complete

IP header is duplicated in each fragment.● Fragmentation is CPU intensive since more fragments

require more processing at both GTPv1-U endpoints and IP routers. It also requires additional memory at the receiver.

● If one fragment is lost, the complete packet has to be discarded. The reason is there is no selective retransmission of IP fragments provided in IPv4 or IPv6.


LTE Tunneling fragmentation

● 3GPP TS 36.300 section 4.5 IP fragmentation– Fragmentation function in IP layer on S1 and X2

shall be supported.

– Configuration of S1-U (X2-U) link MTU in the eNB according to the MTU of the network domain the node belongs to shall be considered as a choice at network deployment. The network may employ various methods to handle IP fragmentation, but the specific methods to use are implementation dependant.


LTE core network scopeReminder : Openair LTE Network entities

● LTE entities:

eNBMME

HSS

SGW PGW

S1-C

S11

SGI S1-U

Network function Implemented in openair-cn


Bearer GTP encap/decap

Repository [email protected]:oai/openair-cn.git

[email protected]:oai/openairinterface5g.git


Openair : LTE Tunneling User plane overview

● Protocol stacks overview and S1U encapsulation, missing split between SGW and PGW.

IP

L2

L1

eNB S+PGW

S1-U

UDP

GTP

IP

L2

L1

UDP

GTP

MAC

PHY

RLC

PDCP

MAC

PHY

RLC

PDCP

IP IP

L4

L2

L1

IP

Node

L4

Appli Appli

UE

GTP8

UDP8

IP20

IP L4 AppliL2

LTE-Uu


Openair : GTP conformance

● Implemented :– T-PDU (source port is not random: 2152)

● Not implemented :– Path Management messages

● Echo Request/Response : Not implemented

– Tunnel Management Messages● Error Indication● End marker


LTE Tunneling fragmentationOPENAIR-CN recommendation

● Considering the comments of 3GPP about fragmentation, we encourage people to increase the MTU of S1-U interfaces by almost 36 bytes, the more, the better (We use the max allowed MTU by our hardware that is 9000).


Tunneling - when

● How build a tunnel from the protocol point of view ?– FTEID have to be exchanged between peers (eNB,

SGW)

– When ?


Interaction Control-Plane/User planeFocus on the creation of the S1-U tunnel

endpointseNB MME SPGW HSS

uplinkNASTransport/IdentityResponse

InitialUEMessage/AttachRequest-PDNConnectivityRequest

dowlinkNASTransport/IdentityRequest

AuthenticationRequestAuthenticationAnswer

uplinkNASTransport/AuthenticationResponsedowlinkNASTransport/AuthenticationRequest

uplinkNASTransport/SecurityModeCompletedowlinkNASTransport/SecurityModeCommand

UpdateLocationRequestUpdateLocationAnswer

InitialContextSetupRequest/

AttachAccept-ActivateDefaultEPSBearerContextRequestInitialContextSetupResponse/

uplinkNASTransport/

AttachComplete-ActivateDefaultEPSBearerContextAccept

CreateSessionResponseCreateSessionRequest

ModifyBearerResponseModifyBearerRequest

Inform of the SGW FTEID

Creation of the eNB FTEID

Inform SGW about eNB FTEID

Allocation of the SGW FTEID (Should create the UL tunnel)

Creation of the bidir. tunnel


Creation of the default S1-U tunnel endpoints (wireshark overview)

Allocation of the SGW FTEID

Inform SGW about eNB FTEID

Inform eNB of the SGW FTEID Creation of the eNB FTEID


Creation of the dedicated S1-U tunnel endpoints (wireshark overview)


Interaction Control-Plane/User planeFocus on the creation of the dedicated S1-U

tunnel endpoints


S11 Create Session Request MME->SGW

Default EBID


S11 Create Session Response SGW->MME

S1U SGW F-TEID

Default EBID


Initial Context Setup MME->eNB

S1U SGW F-TEID


S1AP Initial Context Setup Response eNB->MME

S1U eNB F-TEID


S11 Modify Bearer Request MME->SGW

Default EBID

S1U eNB F-TEID


S11 Modify Bearer Response SGW->MME


SOFTWAREARCHITECTURE


LTE Software ArchitectureSPGW ITTI design

● Each ITTI task communicates with others with ITTI messages (asynchronous)

Described in previous session

ITTI taskLegend :

UDP SPGW_APP

ITTI API (Messages, sockets, timers facilities, memory pool)

spgw process

S11

glibc Timer API epoll API Lfds API LibgtpnlAuthor : Pablo Neira Ayuso <[email protected]>

GTP Linux Kernel module (Version >=4.7) Authors: Harald Welte <[email protected]>,

Pablo Neira Ayuso <[email protected]>, Andreas Schultz <[email protected]>

Create/delete GTPv1 tunnels

NwGtpv2cAuthor :

Amit Chawre

mailto:[email protected]

mailto:[email protected]


TRAFFICCLASSIFICATION


CLASSIFICATION OF USER TRAFFICStatic PCC rules

PCC Rule 0

SDF template x

SDF Filter

SDF Filter

Bearer QOSQci, arp, gbr, mbr

PCC Rule n

SDF template x

SDF Filter

SDF Filter


PCC Rule n+1

SDF template

SDF Filter

SDF Filter


● A set of static PCC rules are loaded on init in SPGW (missing Gx interface).

● Each rule contain one SDF template.

● Each SDF template contains 1 or more SDF filters.

● Any IP flow matching a SDF filter will be mapped to a bearer having the QOS defined in the PCC rule


CLASSIFICATION OF USER TRAFFICStatic PCC rules

● See examples of static PCC rules (to be extended) in https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/SGW/pgw_pcef_emulation.c function pgw_pcef_emulation_init()

https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/SGW/pgw_pcef_emulation.c

https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/SGW/pgw_pcef_emulation.c


CLASSIFICATION OF USER TRAFFIC3GPP SDF classification


CLASSIFICATION OF USER TRAFFICOPEANAIR-CN SDF Classification in SPGW

IP packet are first marked with the SDF IDFor any UE


3GPP service data flow mapping to EPS bearers


OPENAIR-CN Service Data Flow mapping to EPS bearers

S1-U gtp0SGI

POSTROUTING

OUTPUT Local processGTP ENCAP

GTP DECAP

SDF ID detection from predefined static PCC rules:-A POSTROUTING -d 172.16.0.0/12 -p icmp -j MARK --set-xmark 0x20/0xffffffff-A POSTROUTING -d 172.16.0.0/12 -j MARK --set-xmark 0x1f/0xffffffff

Dynamic rule mapping a SDF ID to EPS Bearer ID :-A POSTROUTING -o gtp0 -d 172.16.0.2/32 -m mark --mark 0x1f -j MARK --set-mark 0x05/0xffffffff

POSTROUTING

OUTPUT

SDF ID to EPS Bearer ID

«Default» SDF

Default EBI allocated by MME

Table mangle


EPS bearer to S1-U tunnel mapping in GTP kernel module

● Added EPS bearer id to libgtpnl primitives● Added EPS bearer id to PDP context in kernel

gtp.c

IPv4 address = IP destination address

EPS bearer ID = skb mark

172.16.0.2 5

172.16.0.2 6

...

Hash

h1

h2

hx

ipv4_hashfn()ipv4_ebi_hashfn()

PDP contextu32 i_tei ;u32 o_tei ;u8 bearer_id ;struct in_addr ms_addr_ip4;struct in_addr sgsn_addr_ip4;




Enabling Paging in openair-cn

Figure from « 3GPP TS 23.401 version 10.13.0 Release 10 »



Figure from « EMM Procedure 4. Service Request »

www.netmanias.comNMC Consulting Group ([email protected])



● A kind of Traffic Detection Function has to be implemented in the data path – could be implemented in GTP kernel module =>

● Need for an interface between GTP kernel module and SPGW.

– Could also be implemented out of the GTP kernel module.

● Need for GTPv2-C Downlink Data Notification, Downlink Data Notification Acknowledge messages triggered by the Traffic Detection Function.


What is missing


What is missing

● EPS bearer and SDF classification in uplink (enable QOS enforcement)

● QOS (Max and guaranteed bitrates)– Implementation (Qdiscs) and automate tests

● Traffic flow aggregation (missing parts in control plane) for bearer that have same QCI and same ARP.


Thank you


CLASSIFICATION OF SDF TRAFFIC

● Missing feature :– Missing Gx

interface

for PCRF.

eNB MME

HSS

SGW PGW

S1-C

S6-a

S11

S5/S8 SGI S1-U

PCRF

Gxc Gx

Network entity Implemented in openair-cn


Not implemented, not interfaced

S10


3GPP TS 23.002 4.1.4.2.1.

● Serving GW● The Serving GW is the gateway which terminates the interface towards E-UTRAN.● For each UE associated with the EPS, at a given point of time, there is a single Serving GW. For detailed S-GW● functions, see TS 23.401 [76] and TS 23.402 [77].● Connectivity to a GGSN is not supported.● The functions of the Serving GW include:● - the local Mobility Anchor point for inter-eNodeB handover;● - Mobility anchoring for inter-3GPP mobility;● - ECM-IDLE mode downlink packet buffering and initiation of network triggered service request procedure;● - Lawful Interception;● - Packet routeing and forwarding;● - Transport level packet marking in the uplink and the downlink;● Accounting on user and QCI granularity for inter-operator charging;● - A local non-3GPP anchor for the case of roaming when the non-3GPP IP accesses connected to the VPLMN;● - Event reporting (change of RAT, etc.) to the PCRF;● - Uplink and downlink bearer binding towards 3GPP accesses as defined in TS 23.203 [73];● - Uplink bearer binding verification with packet dropping of "misbehaving UL traffic";● - Mobile Access Gateway (MAG) functions if PMIP-based S5 or S8 is used;● - Support necessary functions in order for enabling GTP/PMIP chaining functions.


● Serving Gateway● The SGW is a data plane element whose primary function is to

manage user-plane mobility and act as a demarcation point between the RAN and core networks. SGW maintains data paths between eNodeBs and the PDN Gateway (PGW). From a functional perspective, the SGW is the termination point of the packet data network interface towards E-UTRAN. When terminals move across areas served by eNodeB elements in E-UTRAN, the SGW serves as a local mobility anchor.

This means that packets are routed through this point for intra E-UTRAN mobility and mobility with other 3GPP technologies, such as 2G/GSM and 3G/UMTS. Figure 3 shows the Serving Gateway.


3GPP TS 23.002 4.1.4.2.2.● PDN GW● The PDN GW is the gateway which terminates the SGi interface towards the PDN.● If a UE is accessing multiple PDNs, there may be more than one PDN GW for that UE, however a mix of S5/S8● connectivity and Gn/Gp connectivity is not supported for that UE simultaneously.● The P GW provides PDN connectivity to both GERAN/UTRAN only UEs and E UTRAN capable UEs using any of E● UTRAN, GERAN or UTRAN. The P GW provides PDN connectivity to E UTRAN capable UEs using E UTRAN only● over the S5/S8 interface. The P¬GW may also provide PDN connectivity to UEs using non-3GPP access networks with● the procedures defined in TS 23.402 [77].● For detailed PDN-GW functions, see TS 23.401 [76] and TS 23.402 [77].● PDN GW functions include:- Per-user based packet filtering (by e.g. deep packet inspection);● - Lawful Interception;● - UE IP address allocation;● - Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point, based on the● QCI of the associated EPS bearer;● - UL and DL service level charging, gating control, rate enforcement as defined in TS 23.203 [73];● - UL and DL rate enforcement based on APN-AMBR;● - DL rate enforcement based on the accumulated MBRs of the aggregate of SDFs with the same GBR QCI● (e.g. by rate policing/shaping);● - DHCPv4 (server and client) and DHCPv6 (client and server) functions;● Additionally the PDN GW includes the following functions for the GTP-based S5/S8/S2b:● - UL and DL bearer binding as defined in TS 23.203 [73];● - UL bearer binding verification;● The PDN GW functions also includes user plane anchor for mobility between 3GPP access and non-3GPP access. It● supports:● - A LMA function for PMIPv6, if PMIP-based S5 or S8, or if S2a or PMIP based S2b is used;● - A DSMIPv6 Home Agent, if S2c is used;● - Allocation of GRE key, which is used to encapsulate uplink traffic to the PDN GW on the PMIP-based S5/S8, or● S2a or PMIP based S2b interface;● - A MIPV4 Home Agent, if S2a with MIPv4 FA CoA mode is used.● - GPRS Tunnelling Protocol for the control plane and the user plane to provide PDN connectivity to UEs using● non-3GPP accesses, if GTP based S2b is used.


● Packet Data Network Gateway● Like the SGW, the Packet Data Network Gateway (PDN GW) is the

termination point of the● packet data interface towards the Packet Data Network(s). As an

anchor point for sessions towards● the external Packet Data Networks, the PDN GW supports:● • Policy enforcement features (applies operator-defined rules for

resource allocation and usage)● • Packet filtering (for example, deep packet inspection for

application type detection)● • Charging support (for example, per-URL charging)

openair lte core network user · pdf fileopenair lte core network user plane training session....

Documents