IPv6 Communication between LTE Nodes 


 • P-GW allocates the IPv6 address to UE.
 • This address allocation done through the Router Advertisement message.
 • The Router Advertisement message will carry both Prefix and Interface ID for an UE.
 • UE makes the FULL IPv6 address by using both Prefix and Interface ID
 • There will be no DAD(Duplicate Address Detection) for IPv6 UE address as the UE IPv6 address is globally unique.
 • As UE is in air interface and there is no IP Connectivity so there will be no DAD(Duplicate Address detection)
 • But in between eNB-MME-SGW-PGW, DAD is available as there is a chance of duplicate Address. So DAD is applicable here.

1. UE initiate Attach Request towards eNB to attach in the LTE network.
 2. eNB derives the MME and sends Attach Request to MME in S1-MME Initial UE Message.
 3. MME selects the SGW and sends Create Session Request towards SGW with EPS bearer information for default Bearer.
 4. SGW creates the EPS bearer context and sends Create session Request to PGW with default EPS bearer information. Note: PGW selection done by MME and shared with SGW in Create session Request from MME. PDN GW performs an IP-CAN Session Establishment with PCRF. The PCRF may modify the APN-AMBR and the QoS parameters (QCI and ARP) associated with the default bearer in the response to the PDN GW.
 5. PGW creates EPS Bearer Context table and generates Create Session Response towards SGW. PGW initiates the Charing activities for the EPS bearer. PGW also obtain the prefix from the external PDN through Diameter and shares the prefix info and Interface ID for an UE in the PAA(PDN Address) Informational Element of Create Session Request. Now PDN can sends the downlink packet for an UE but as the eNB information is not available the packet will get buffered at SGW. SGW might initiates Downlink indication towards MME.
 6. SGW confirms the Default bearer creation and sends the Create Session Request with MME. SGW shares the prefix info and Interface ID for an UE in the PAA(PDN Address) Informational Element of Create Session Request.
 7. MME creates the Bearer Context and sends Attach Accept in S1-MME Intial Context Setup Request to eNB. In the Attach Accept message, the MME does not include the IPv6 prefix within the PDN Address but shares the UE Interface ID to eNB.
 8. eNB sends RRC Reconfiguration Request message to UE. If the UE receives an IPv6 interface identifier, it may wait for the Router Advertisement from the network with the IPv6 prefix information or it may send a Router Solicitation if necessary.
 9. UE sends RRC Reconfiguration Complete message to eNB.
 10. eNB sends the Initial Context Setup Response message to MME with eNB’s TEID(Tunnel Identifier) and IP address for downlink packet.
 11. UE sends a Direct Transfer message to the eNodeB.
 12. eNB sends the Attach Complete towards MME.
 13. As UE knows the UL bearer information, now UE can sends the UL traffic. So UE initiates the Router Solicitation message towards network to get the Full IPv6 address. This packet is same as UL traffics.
 14. MME initiates the Modify Bearer Request towards SGW to share the eNB’s information i.e. eNB’s TEID and IP address for downlink packet.
 15. SGW updates the eNB information and sends Modify Bearer response towards MME.
 16. Now SGW has the information of eNB, so the downlink packet can be delivered to UE. So the PGW response back with Router Advertisement message for a Router Solicitation message initiated by UE. The Router Advertisement message will have IPv6 prefix in it to make the Full IPv6 address. This Router Advertisement Message is carried as a DL packet. Now UE can make the full IPv6 address by using the Interface ID shared before by PGW and the IPv6 prefix shared in Router Advertisement message. •

References: – http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation-09
– 23.402 (LTE Over View) 3gpp specification
 – 29.274 (GTPv2-C) 3gpp specification

TFT filtering rule in LTE network

TFT

TFT is set of all packet filter associated with an EPS bearer. A packet filter may be associated with a protocol. A packet filter Identifier shall be used to identify a packet filter. For eg: lets say we have http traffic. Now we all know that destination port in Http is 80. So a packet filter can be created indicating destination port to 80 and this packet filter may associate with a ID which is nothing but packet filter ID. Now several packet filters can be combined to form a Traffic Flow Template.

One EPS bearer is established when UE connects to PDN and that remains lifetime of that PDN connection to provide UE with always on IP connectivity to PDN. This is default bearer. Any additional bearer that is established to the same PDN is referred as dedicated bearer.

Up Link Traffic Flow Template (UL TFT) : - Set of uplink packet filters in TFT
Downlink Traffic Flow Template (DL TFT) : - Set of downlink packet filters in TFT
Every dedicated EPS bearer is associated with TFT.

The following way we can define the TFT filtering rule for a bearer.

-       IP Network based

-       Port range base

-       Protocol base

-       Direction base

1. IP Network Base:

If each bearer will have distinct IP network then in this case the IP network base filtering can be used.

2. Port range Base:

If the network is same for the entire bearer then this can be used for TFT filtering.

3. Protocol Base:

This can be used to filter some protocol based TFT.

4. Direction Base:

This is a filtering rule for UL/DL direction.

Default_Dedicated_bearer_Creation in LTE network

This document will explain about the new bearer allocation on top of default bearer.

First we will cover the default bearer creation and then we will cover the allocation of dedicated bearer.

Default Bearer Creation:

Here I will elaborate more on GTP perspective for creating default bearer. Please refer the following points when attach request initiated by UE,

1.       UE initiate a “Attach Request” towards eNB with the UE information such as IMSI, UE Core Network Capability, Attach Type, NAS information, RRC parameters etc.

2.       ENB derives MME from RRC parameter and forward the “Attach Request” i.e. S1-MME message (Initial UE Message) towards MME with the Selected Network, CSG ID (Common subscriber group), and TAI+ECGI information.

3.       MME will initiate a GTP-C signaling message towards S-GW to proceed with attach. This will help the EPS (Evolved Packet system) to create default bearer in the network. MME initiates Create Session Request with the following important information

a.       IMSI

b.      MME’s F-TEID for control plane (MME IP + TEID (Tunnel ID)). This will be used for future communication with MME.

c.       PGW’s G-TEID for Control plane (P-GW IP + TEID (here it will be zero)). This will be used by S-GW to communicate with P-GW.

d.      Bearer Context to be created. This is the bearer information to be created at MME. This will include the default bearer ID with TFT, QOS.

e.      APN

f.        Recovery

4.       S-GW will process the “Create Session Request” initiated by MME and create the UE, eNB, and MME context and modify the Create session Request and send it to P-GW. Create session Request from S-GW will have the following important information

a.       IMSI

b.      S-GW’s F-TEID for control plane (S-GW IP + TEID (Tunnel ID)). This will be used for future communication with S-GW.

c.       Bearer Context to be created. This is the bearer information to be created at S-GW. This will include the default bearer ID with TFT, QOS, S-GW user plane F-TEID

d.      APN

e.      Recovery

5.       Once P-GW receives “Create Session Request” , it will create UE, S-GW context and communicate with PCRF for QOS and APN resolve. If that succeed, P-GW will respond back with “Create Session Response” towards S-GW. The Create Session Response will have following information:

a.       Cause. This value will be used for Success/failure for the Create Session Request.

b.      P-GW’s F-TEID for control plane (P-GW’s IP + TEID ). This information will be used for future signaling message communication with P-GW.

c.       PAA (PDN Address Allocation).

d.      Bearer Contexts Created. This information element will have Default EPS bearer ID, P-GW user plane F-TEID, TFT, Bearer Qos, Charging ID.

e.      Charging GW

f.        Recovery

6.       Once S-GW receives “Create Session Response”, it will create P-GW context and forward/process the “Create Session Response “with the following information.

a.        Cause. This value will be used for Success/failure for the Create Session Request.

b.      S-GW’s F-TEID for control plane (S-GW’s IP + TEID ). This information will be used for future signaling message communication with S-GW.

c.       PAA (PDN Address Allocation).

d.      Bearer Contexts Created. This information element will have Default EPS bearer ID, P-GW user plane F-TEID, TFT, Bearer Qos, Charging ID.

e.      Charging GW

f.        Recovery

7.       Now if downlink data comes from PDN it will get buffered in S-GW as user plane eNB information shared with S-GW.

8.       MME shares the eNB information as part of attach procedure with “Modify Bearer request” with the following information

a.       Bearer Contexts to be modified. This IE will have eNB’s user plane F-TEID.

9.       Once S-GW receives the “Modify Bearer request” with eNB information.  It will respond back with “Modify bearer Response”.

10.    Now downlink data can be sent to eNB because S-GW has the information of eNB.

11.   But uplink data can possible after step 6.

Dedicated Bearer Allocation:

Once the default bearer created the UE or network can opted for the dedicated bearer.  To get more service from network, UE or NW may initiate the dedicated bearer allocation.

1.      UE Initiated Dedicated Bearer Allocation:

a.       UE Request “Bearer Resource Allocation” message towards MME for allocating dedicated bearer.

b.      MME sends “Bearer Resource Command” with the default bearer ID to S-GW for a dedicated bearer allocation. That means MME commands to the P-GW to initiate a “Create Bearer Request” to start the dedicated bearer allocation. This command will provide the default bearer ID. This message will have the following information:

                                            I.            EBI i.e. Default EPS bearer ID.

                                          II.            PTI

                                        III.            TAD (TFT rule + TFT ID)

c.       Once S-GW receives the “Bearer Resource Command” then the SGW or the PGW will determine if the UE is requesting an Allocation operation of bearer resources for a traffic flow aggregate based on the TFT operation code and the packet filter ID value in the Traffic Aggregate (TAD) IE and/or the presence of the EPS Bearer ID IE.

d.      PCRF entity has to check the APN and QoS details for bearer approval.

e.      After P-GW received “Bearer Resource Command”, it will initiate “Create Bearer Request” towards S-GW for dedicated bearer allocation. This request will have the following information.

                                            I.            EBI i.e. Default EPS bearer ID.

                                          II.            Bearer Context. This IE will contain the dedicated bearer id with value “0” (as MME is going to allocate the bearer ID), TFT, P-GW user plane F-TEID etc.

f.        Once S-GW receives “Create Bearer Request”, it will propagate the message towards MME for dedicated bearer allocation.

g.       MME does a bearer setup request with eNB after receiving “Create Bearer request” from S-GW.

h.      Once the bearer setup request completes, MME sends back “Create Bearer Response” with the following information.

                                            I.            Cause. This is for success or failure.

                                          II.            Bearer Contexts. EBI. This ID will be assigned by MME with a value. eNB User plane F-TEID etc.

i.         Once S-GW receives “Create Bearer Response” then it update the UE,eNB and MME context for the dedicated bearer and sends the “Create Bearer Response” towards P-GW.

2.      NW Initiated Dedicated Bearer Allocation:

If the service provided by NW is not sufficient in a bearer then P-GW opted for dedicated bearer initiation.

a.       P-GW will initiate “Create Bearer Request” towards S-GW for dedicated bearer allocation. This request will have the following information.

                                            I.            EBI i.e. Default EPS bearer ID.

                                          II.            Bearer Context. This IE will contain the dedicated bearer id with value “0” (as MME is going to allocate the bearer ID), TFT, P-GW user plane F-TEID etc.

b.      Once S-GW receives “Create Bearer Request”, it will propagate the message towards MME for dedicated bearer allocation.

c.       MME does a bearer setup request with eNB after receiving “Create Bearer request” from S-GW.

d.      Once the bearer setup request completes, MME sends back “Create Bearer Response” with the following information.

                                            I.            Cause. This is for success or failure.

                                          II.            Bearer Contexts. EBI. This ID will be assigned by MME with a value. eNB User plane F-TEID etc.

e.      Once S-GW receives “Create Bearer Response” then it update the UE,eNB and MME context for the dedicated bearer and sends the “Create Bearer Response” towards P-GW.

Functionality of Different LTE Nodes

LTE Architecture
LTE network compromises of the following nodes:

• UE (User Endpoint)
• MME (Mobile Management Entity)
• S-GW (Serving Gateway)
• P-GW (PDN Gateway)
• PDN (Packet Data Network or IP world)
• PCRF (Policy and Charging Enforcement Function) 
• eNB (e Node B)
• SGSN (Serving GPRS Support Node)
• HSS (Home Subscriber SubSystem)
• E-UTRAN (Collection of eNB)
• EPC (Combination of MME, S-GWand P-GW)

The Architecture of LTE network look like this:

LTE Non-Roaming architecture

The communication between different nodes of LTE work like this:

We will go deeper to describe about the different interface between different nodes, functionality and the layering structure of LTE Nodes.

Interfaces between different Nodes:

Uu-Interface: This interface is in between UE and eNB. This is a radio/air interface and OFDMA (Orthogonal Frequency Division Multiple access) technology is used to send uplink packet and SC-FDMA technology is being used to send downlink packet.

X2-Interface: This interface is in between eNB and eNB. Under this interface the UDP being used as Transport protocol and GTP being used as Application protocol. Basically this interface is used for Handover.

S1-U Interface: This interface is in between eNB and S-GW and this interface will be used for data path communication. Under this interface  UDP will be used as Transport protocol and GTP-U protocol will be used for application protocol

S1-AP Interface: This interface is in between eNB and MME. This interface is used for sending signalling packet between eNB and MME. Under this interface SCTP will be used as transport protocol and S1-AP will be used as application protocol.

S11 Interface: This interface is in between MME and S-GW. this interface will be used for Signalling communication between MME and S-GW. Under this interface UDP will be used as transport protocol and GTP-C will be used as application protocol.

S5-C Interface: This interface is in between S-GW and P-GW. This interface will be used for signalling between S-GW and P-GW. Under this interface UDP will be used for transport protocol and GTP-C will be used for applicatio protocol.

S5-U Interface: This interface is in between S-GW and P-GW. This interface will be used for data path. Under this interface UDP will be used for transport protocol and GTP-U will be used for application protocol.

S6a Interface: This interface is in between MME and HSS. This interface will be used for Authentication, Authorization and Accounting. The SCTP will be used for transport protocol and Diameter will be used for application protocol.

 Functionality of LTE Nodes:
eNodeB
The following functionality for eNodeB in LTE network:

-     Header compression and user plane ciphering;

-     MME selection when no routing to an MME can be determined from the information provided by the UE;

-     UL bearer level rate enforcement based on UE-AMBR and MBR via means of uplink scheduling
(e.g. by limiting the amount of UL resources granted per UE over time);

-     DL bearer level rate enforcement based on UE-AMBR;

-     UL and DL bearer level admission control;

-     Transport level packet marking in the uplink, e.g. setting the DiffServ Code Point, based on the QCI of the associated EPS bearer;

-     ECN-based congestion control.

MME
The different functionality of MME are:

-     NAS signalling;

-     NAS signalling security;

-     Inter CN node signalling for mobility between 3GPP access networks (terminating S3);

-     UE Reachability in ECM-IDLE state (including control and execution of paging retransmission);

-     Tracking Area list management;

-     Mapping from UE location (e.g. TAI) to time zone, and signalling a UE time zone change associated with mobility,

-     PDN GW and Serving GW selection;

-     MME selection for handovers with MME change;

-     SGSN selection for handovers to 2G or 3G 3GPP access networks;

-     Roaming (S6a towards home HSS);

-     Authentication;

-     Authorization;

-     Bearer management functions including dedicated bearer establishment;

-     Lawful Interception of signalling traffic;

-     Warning message transfer function (including selection of appropriate eNodeB);

-     UE Reachability procedures.

GTP-C message description in LTE enviornment.

When you come across GTP-C message then you are surely curious about the GTP-C message handling in LTE network.
GTP-C message flows between different interface to setup the signalling connection. The interfaces are S11, S5, S8 and S4.

There are two type of GTP-C messages are there.
1. Path management messages
2. Tunnel management messages.

1. Path Management Messages
ECHO request/response will be used to ping destination GTP end point as well handle the restart procedure of a GTP endpoint.
Please refer ECHO message handling in GTP-C

2. Tunnel Management Messages
Different GTP-C messages are used to manage a Tunnel. The GTP-C messages are Create Session Request/Response, Create Bearer Request/Response, Modify Bearer Request/Response, Update Bearer Request/Response, Delete Session Request/Response, Delete Bearer Request/Response etc.

Let's see the following diagram where GTP-C message is used for signalling setup.
This figure is for attaching a UE in the LTE network

Here i will explain more on the GTP-C message flow in LTE Network.
a. Create Session Request/Response
This message is used to do signalling setup between MME and SGW or SGW and PGW.

To Create a tunnel between MME and SGW, MME sends Create Session Request towards SGW with GTP-C F-TEID, Bearer Context, MME FQ-CSID and some more Informational element.

The initial Create Session request from MME will have TEID value as 0 in the GTP-C header as MME doesn't know about the SGW F-TEID.
But further Create Session Request from MME will have TEID in GTP-C header as MME knows the TEID of S-GW.

The different Informational Elements of Create Session request are:
IMSI, MSISDN, User Location Information (ULI), Serving Network, RAT Type, Indication Flags, MME/SGW F-TEID, PGW F-TEID, PDN Type, PAA, Bearer Context to be created, Bearer Context to be removed, Recovery, MME-FQ-CSID, SGW-FQ-CSID, Charging Characteristics, Private Extension.
IMSI: The 15 digit number of UE.
MSISDN: The mobile no of UE.
MME/SGW F-TEID: This IE is MME S11 GTP-C(Control plane) F-TEID if MME sends Create Session Request towards S-GW and SGW S5 GTP-C(Control plane) F-TEID if SGW sends Create Session Request towards P-GW.
Bearer Context To be Created: This informational elements is for creating a default bearer through Create Session Request. It carry some sub Informational element. The Informational elements are:

• EBI: Default bearer ID
• 
  

ECHO message handling in GTP-C

Introduction: 
ECHO message is a primary message communication in GTP interface. This message is used for to ping an end point as well used for restoration procedure for an end point. We will go detail in the following description.

Format of ECHO message:

		Bits
Octets		8	7	6	5	4	3	2	1
1		Version			P	T=0	Spare	Spare	Spare
2		Message Type
3		Message Length (1st Octet)
4		Message Length (2nd Octet)
5		Sequence Number (1st Octet)
6		Sequence Number (2nd Octet)
7		Sequence Number (3rd Octet)
8		Spare

This message is same as other GTP-C message header format but only one difference is the 4 bytes TEID filed is missing in the header format.

The ECHO message is also called as path management message in the GTP interface because this message is used for to ping an GTP endpoint in the S11, S5, S8 interfaces.

As well this message is used for restart procedure.

The format of GTP-C ECHO message is like this:

ECHO message is a combination of ECHO GTP-C header and some Informational Element.
The Informational elements are

Information elements	P	Condition / Comment	IE Type	Ins.
Recovery	M		Recovery	0
Sending Node Features	CO	This IE shall be sent towards a peer node on any GTPv2 interface if the sending node supports at least one feature on this interface or if the sending node supports at least one feature and does not know the interface type towards the peer node. This IE may be present otherwise.	Node Features	0
Private Extension	O		Private Extension	VS

This message contains one IE called Recovery IE to set the restart counter value for an GTP endpoint.

Suppose one GTP endpoint restarted then that end point will send an ECHO request to the other GTP end point  with the recovery IE.

Restart procedure Handling at SGW

During or immediately after an SGW Restart the SGW shall place local SGW restart counter value in all GTPv2 Echo requests/responses messages.

The SGW will receive the MME restart counter in GTPv2 Echo requests and Echo response messages that the SGW receives from the MME.

The SGW will receive the PGW restart counter in GTPv2 Echo requests/ responses receives from the PGW.

When an SGW detects that a peer MME has restarted it shall delete all PDN connection table data associated with the peer node that fails as well as freeing any internal SGW resources associated with those PDN connections.

When an SGW detects that a peer PGW has restarted it shall delete all PDN connection table data associated with the peer node that fails as well as freeing any internal SGW resources associated with those PDN connections. In addition, if the optional feature PGW Restart Notification is supported by the SGW  the SGW shall initiate the cleanup of the hanging PDN connections associated with the SGW and the restarted PGW at the corresponding MMEs by sending GTPv2 message(s) PGW Restart Notification, with the control plane IP address of the restarted PGW and the control plane IP address of the SGW on the S11 interface included. 

When the MME receives this message, according to the control plane IP address of the restarted PGW and the control plane IP address of the SGW on the S11 interface included in the message, MME should delete all PDN connection table data associated with the SGW and the restarted PGW as well as freeing any internal MME resources associated with those PDN connections. The MME may optionally perform other implementation specific actions such as to clear external resources (e.g. S1-MME messages to clear eNodeB resources) or more advanced forms of restoration. 

Restart procedure Handling at PGW

After a PGW restart, the PGW shall delete all MM Bearer contexts affected by the restart that it may have stored.

During or immediately after a PGW Restart, the PGW shall place this PGW restart counter value in all GTPv2 echo requests/responses the PGW sends.

The PGW will receive the SGW  restart counters in GTPv2 echo requests/responses. When a PGW detects that a peer SGW has restarted it shall delete all PDN connection table data associated with the peer node that fails as well as freeing any internal PGW resources associated with those PDN connections. 

GTP-C Overview

GTP-C tunnels are used between two nodes communicating over a GTP based interface, to separate traffic into different communication flows.

A GTP-C tunnel is identified in each node with a TEID, an IP address and a UDP port number. 
Each node will be uniquly identified by F-TEID (Fully Qualified Tunnel identifier) in a global network. Each node will share their   TEID for both signalling and Data path.


There are different version of GTP-C. I will cover more on GTPv2.


In GTPv2-C protocol, three type of messages are there.

1. Initial Message
2. Triggered Message
3. piggy backed message

Initial Message: As name says, who is initiating a request or Command is a Initial Message. e.g. Create Session Request, Bearer Resource Command etc. Always the Initial message will get forward to 2123 for GTP-C and 2152 for GTP-U


Triggered Message: This message is a response message of Initial Message. In Triggered message will use the port same as the source of Initial message. e.g Create Bearer request for Bearer resource Command.


Piggybacked Message: This message is a combination of two GTP-C message with one GTP-C header. e.g. Create Session Response will piggyback Create Bearer Request and same way Create Bearer Response will piggyback Modify Bearer Request.


The GTP-C message has the following format:

		Bits
	Octets	8	7	6	5	4	3	2	1
	1 to m	GTP-C header
	m+1 to n	Zero or more Information Element(s)

The GTP-C message is a combination of GTP-C header and zero or more Information Element.
The Format of GTP-C header is:

		Bits
Octets		8	7	6	5	4	3	2	1
1		Version			P	T=1	Spare	Spare	Spare
2		Message Type
3		Message Length (1st Octet)
4		Message Length (2nd Octet)
5		Tunnel Endpoint Identifier (1st Octet)
6		Tunnel Endpoint Identifier (2nd Octet)
7		Tunnel Endpoint Identifier (3rd Octet)
8		Tunnel Endpoint Identifier (4th Octet)
9		Sequence Number (1st Octet)
10		Sequence Number (2nd Octet)
11		Sequence Number (3rd Octet)
12		Spare

1st Octet
The 4th bit of first octet is the 'T' bit means, If this flag is set then the 4 byte TEID will be available in the GTP-C  message.
The 5th bit of first octet is the 'P' bit means, if this bit is set then the message will be considered as piggybacked message.
The 6,7 and 8th bit is combination for version of GTP-C message.
2nd Octet
This octet is for message type of the GTP-C message.
3rd & 4th Octet
These octets are used for Message length of GTP-C header. The length of the message is from TEID field to the end of the message i.e excluding the 4 byte from the GTP-C message.
5th, 6th, 7th & 8th Octet
These octets are used for Tunnel identifier value. these octets will be absent if 'T' bit is set to 0.
9th, 10th and 11th Octet
These octets are used for sequence no of the GTP-C message. 


The GTP-C messages are divided into two parts.
1. Path Management
2. Tunnel Management


For details keep reading the preceding blogs