11
Mar
Posts Tagged ‘passion’
19
Mar
X2-based handovers
As I was saying in a previous post, one of the handover types that can take place over LTE/SAE is the X2-based handover. This type of handover takes place when the UE moves from a cell controlled by one eNodeB (let’s call it source eNB) to a cell controlled by another eNB – target eNB. When this happens, the MME cannot be changed (basic condition of an X2-based handover). Still, the MME can decide whether or not to change the SGW. This means that there are 2 types of X2-based handover: with no SGW relocation and with SGW relocation. In both of them, the existence of the X2 interface between the source and target eNB is assumed.
As per TS 23.401, the behavior in case of X2 handover is the one below:[quoted from TS 23.401 - 5.5.1 Intra-E-UTRAN handover]
5.5.1.1 X2-based handover
5.5.1.1.1 General
These procedures are used to hand over a UE from a source eNodeB to a target eNodeB using the X2 reference point. In these procedures the MME is unchanged. Two procedures are defined depending on whether the Serving GW is unchanged or is relocated. In addition to the X2 reference point between the source and target eNodeB, the procedures rely on the presence of S1-MME reference point between the MME and the source eNodeB as well as between the MME and the target eNodeB.
The handover preparation and execution phases are performed as specified in TS 36.300 [5].
When the UE receives the handover command it will remove any EPS bearers for which it did not receive the corresponding EPS radio bearers in the target cell. As part of handover execution, downlink packets are forwarded from the source eNodeB to the target eNodeB. When the UE has arrived to the target eNodeB, downlink data forwarded from the source eNodeB can be sent to it. Uplink data from the UE can be delivered via the (source) Serving GW to the PDN GW. Only the handover completion phase is affected by a potential change of the Serving GW, the handover preparation and execution phases are identical.
If the MME receives a rejection to a NAS procedure (e.g. dedicated bearer establishment/modification/release; location reporting control; NAS message transfer; etc.) from the eNodeB with an indication that an X2 handover is in progress (see TS 36.300 [5]), the MME shall reattempt the same NAS procedure either when the handover is complete or the handover is deemed to have failed. The failure is known by expiry of the timer guarding the NAS procedure.
5.5.1.1.2 X2-based handover without Serving GW relocation
This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is unchanged and decides that the Serving GW is also unchanged. The presence of IP connectivity between the Serving GW and the source eNodeB, as well as between the Serving GW and the target eNodeB is assumed.
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2].
1. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell, including the TAI+ECGI of the target cell and the list of rejected EPS bearers. The MME determines that the Serving GW can continue to serve the UE
2. The MME sends a Modify Bearer Request (eNodeB address(es) and TEIDs for downlink user plane for the accepted EPS bearers) message to the Serving GW. If the PDN GW requested UE’s location info, the MME also includes the User Location Information IE in this message.
The MME releases the non-accepted bearers by triggering the bearer release procedure as specified in clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL packet and does not send a Downlink Data Notification to the MME.
3. If the Serving GW has received the User Location Information IE from the MME in step 2 the Serving GW informs the PDN GW(s) about this information that e.g. can be used for charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, User Location Information IE) to the PDN GW(s) concerned. A Modify Bearer Response message is sent back to the Serving GW.
4. The Serving GW starts sending downlink packets to the target eNodeB using the newly received address and TEIDs. A Modify Bearer Response message is sent back to the MME.
5. In order to assist the reordering function in the target eNB, the Serving GW shall send one or more “end marker” packets on the old path immediately after switching the path as defined in TS 36.300 [5], clause 10.1.2.2.
6. The MME confirms the Path Switch Request message with the Path Switch Request Ack message. If the UE AMBR is changed, e.g. all the EPS bearers which are associated to the same APN are rejected in the target eNodeB, the MME shall provide the updated value of UE AMBR to the target eNodeB in the Path Switch Request Ack message.
If some EPS bearers have not been switched successfully in the core network, the MME shall indicate in the Path Switch Request Ack message which bearers failed to be established (see more detail in TS 36.413 [36]) and inititate the bearer release procedure as specified in clause 5.4.4.2 to release the core network resources of the failed EPS bearers. The target eNodeB shall delete the corresponding bearer contexts when it is informed that bearers have not been established in the core network.
7. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers the release of resources. This step is specified in TS 36.300 [5].
8. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause “Triggers for tracking area update” applies.
NOTE 2: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in ECM CONNECTED state and the MME is not changed.
5.5.1.1.3 X2-based handover with Serving GW relocation
This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is unchanged and the MME decides that the Serving GW is to be relocated. The presence of IP connectivity between the source Serving GW and the source eNodeB, between the source Serving GW and the target eNodeB, and between the target Serving GW and target eNodeB is assumed. (If there is no IP connectivity between target eNodeB and source Serving GW, it is assumed that the S1-based handover procedure in clause 5.5.1.2 shall be used instead.)
Figure 5.5.1.1.3-1: X2-based handover with Serving GW relocation
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2].
1. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell, including the ECGI of the target cell and the list of rejected EPS bearers. The MME determines that the Serving GW is relocated and selects a new Serving GW according to clause 4.3.8.2 on “Serving GW Selection Function”.
NOTE 2: The MME knows the S GW Service Area with a TA granularity.
2. The MME sends a Create Session Request (bearer context(s) with PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, eNodeB address(es) and TEIDs for downlink user plane for the accepted EPS bearers, the Protocol Type over S5/S8) message to the target Serving GW. The target Serving GW allocates the S GW addresses and TEIDs for the uplink traffic on S1_U reference point (one TEID per bearer). The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. If the PDN GW requested UE’s location info, the MME also includes the User Location Information IE in this message.
The MME releases the non-accepted bearers by triggering the bearer release procedure as specified in clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL packet and does not send a Downlink Data Notification to the MME.
3. The target Serving GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the PDN GW. The Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. It sends a Modify Bearer Request (Serving GW addresses for user plane and TEID(s)) message to the PDN GW(s). The S GW also includes User Location Information IE if it is present in step 2. The PDN GW updates its context field and returns a Modify Bearer Response (PDN GW address and TEID, Charging Id, MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. The PDN GW starts sending downlink packets to the target GW using the newly received address and TEIDs. These downlink packets will use the new downlink path via the target Serving GW to the target eNodeB.
4. The target Serving GW sends a Create Session Response (Serving GW addresses and uplink TEID(s) for user plane) message back to the target MME. The MME starts a timer, to be used in step 7.
5. The MME confirms the Path Switch Request message with the Path Switch Request Ack (Serving GW addresses and uplink TEID(s) for user plane) message. If the UE AMBR is changed, e.g. all the EPS bearers which are associated to the same APN are rejected in the target eNodeB, the MME shall provide the updated value of UE AMBR to the target eNodeB in the Path Switch Request Ack message. The target eNodeB starts using the new Serving GW address(es) and TEID(s) for forwarding subsequent uplink packets.
If some EPS bearers have not been switched successfully in the core network, the MME shall indicate in the Path Switch Request Ack message which bearers failed to be established (see more detail in TS 36.413 [36]) and inititate the bearer release procedure as specified in clause 5.4.4.2 to release the core network resources of the failed EPS bearers. The target eNodeB shall delete the corresponding bearer contexts when it is informed that bearers have not been established in the core network.
6. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers the release of resources. This step is specified in TS 36.300 [5].
7. When the timer has expired after step 4, the source MME releases the bearer(s) in the source Serving GW by sending a Delete Session Request message, which is acknowledged by the Serving GW.
8. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause “Triggers for tracking area update” applies.
NOTE 3: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in ECM CONNECTED state. During the TA update procedure the MME deactivates ISR because of the S GW change.
Tags: eNB, eNodeB, LTE, MME, passion, PGW, SAE, SGW, SGW relocation, techie, UE, X2-based handover
10
Mar
Mobility over LTE/SAE
Mwell…my dear dear journal, today I had to learn about Mobility over SAE. As we very well know, our naughty user (User Equipment) does not just stay in one single cell, but rather moves around between different antennas. As per TS 23.401 (I have studied the June edition), there are several “cases” of mobility, or handover, as the 3GPP guys call them.
What is to know about how these “cases” are delimited:
1. whether the UE only moves from one eNodeB to another (the rest of the EPS is the same) or other components (like MME and/or SGW) are also changing => X2-handover and S1-handover
2. whether or not the eNodeBs are connected each-other (when they are connected, the interface is called X2) => this results in 2 separate cases: Direct Tunneling (we have X2) and Indirect Tunneling (we don’t have X2)
3. whether or not the MME changes (is relocated, as per the TS) => no MME relocation and MME relocation scenarios
4. whether or not the SGW changes (is relocated, as per the TS) => no SGW relocation and SGW relocation scenarios
5. in each of these cases, what happens to the user-plane traffic in terms of the path it takes; the uplink usually goes directly through the new components of handover, but the downlink data is forwarded back and forth around those elements – in the diagrams attached I have represented the user-plane in dotted lines – hope you’d like it 
6. the user-plane flow problem appears only in the time interval that the handover is not completed, otherwise it is the usual; this is why there is only a downlink user-plane traffic described
So—let’s do this by the book.
TS 23.401, section 5.5.1.1.2 – X2-based handover with NO SGW relocation and NO MME relocation (implicit direct tunneling)
- UE moves from source eNB to target eNB, the X2 interface is present
- the downlink data flows this way: PGW -(via S5/S8)> SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE
TS 23.401, section 5.5.1.1.3 – X2-based handover with SGW relocation and NO MME relocation (implicit direct tunneling)
- UE moves from source eNB to target eNB, the X2 interface is present
- the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> target eNB -(via LTE radio)> UE
* no MME relocation for X2-based handover :d
TS 23.401, section 5.5.1.2.2 – S1-based handover, NO SGW relocation and MME relocation + Direct Tunneling
- UE moves from source eNB to target eNB, the X2 interface is present
- the downlink data flows this way: PWG -(via S5/S8)> SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE
TS 23.401, section 5.5.1.2.2 – S1-based handover, NO SGW relocation and MME relocation + Indirect Tunneling
- UE moves from source eNB to target eNB, the X2 interface is NOT present
- the downlink data flows this way: PGW -(via S5/S8)> SGW -(via S1-U)> source eNB -(via S1-U)> SGW -(via S1-U)> target eNB -(via LTE radio)> UE
* this is the case when there are some downlink packets that have been forwarded from the SGW to the source eNB, BEFORE the handover is completed; this means that the source eNB (knowing there is a handover ongoing), resends/sends back these packets to the SGW they came from; the SGW, at this point, should be aware of the handover and buffer the packets until the handover is completed, then forward them via the appropriate S1-U to the target eNB
TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and NO MME relocation + Direct Tunneling
- UE moves from source eNB to target eNB, the X2 interface is present
- the downlink data flows this way: PWG -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE
TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and NO MME relocation + Indirect Tunneling
- UE moves from source eNB to target eNB, the X2 interface is NOT present
- the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via S1-U)> source SGW -(via…to check this up)> target SGW -(via S1-U)> target eNB -(via LTE radio)> UE
TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and MME relocation + Direct Tunneling
- UE moves from source eNB to target eNB, the X2 interface is present
- the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE
TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and MME relocation + Indirect Tunneling
- UE moves from source eNB to target eNB, the X2 interface is NOT present
- the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via S1-U)> source SGW -(via…to check this up)> target SGW -(via S1-U)> target eNB -(via LTE radio)> UE
The signaling required for these handovers are described in TS 23.401 as a flow and in TS 29.274 at the IE level.
I will try to describe each flow (or at least the most significant ones) in future articles. Enjoy :p
Tags: direct tunneling, downlink, eNodeB, EPC, handover, indirect tunneling, LTE, MME, mobility, passion, PGW, S1-MME, S1-U, S11, SAE, SGW, source, target MME, target SGW, techie, UE, uplink, X2
One of the best IPsec devices I have worked with so far is Stoke. And when I am saying best I mean it in a sense of compliance, flexibility, stability and performance.
Although it has its minuses, like any device on earth, the pretty SSX-3000 solution I’ve got my hands on knew most of the Remote-Access scenarios I could think of and EAP authentication on top. Besides that, I could do my work undisturbed, while my colleagues were experimenting on their own. Why? Because of the contexts: each one of these “virtual” routers minds its own business, permitting me to play around with my stuff, while the others could work very well, without having to worry about Cristina’s ideas. Now, 240k IPsec tunnels in remote-access with EAP authentication versus Radius and support for digital certificates sounds pretty good if you were to ask me. Mwell…not good enough for the Stoke guys…it seems. So they came up with an even more interesting idea: LAN-to-LAN. Now..hmm..this powerful machine, able of doing so much on RA…could it also be doing site-to-site? So, I’ve contacted my favorite Japanese techie and asked for instructions.
This is the way it works:
Let’s assume there are 2 security gateways, Tokyo (10.1.1.2) and Bucharest (10.1.1.1). Tokyo gateway protects a network (5.1.1.0/24), while in Bucharest we have another network (6.1.1.0/24). Stoke has the concept of “tunnel-enabled interface”, which is a only /32 IP address of an interface type “tunnel”. The following services are not allowed on a tunnel-enabled interface: static IP hosts, ARP, and routing protocols.
So, in our case, let’s assume the tunnel interface for Tokyo is 9.9.9.1/32 and for Bucharest it is 9.9.9.2/32.
As everything on an SSX is done via a context, let’s assume that Tokyo has a context called TB1 and Bucharest has a context called BT1, on which they have this LAN-to-LAN configuration. The configuration on Tokyo would look something like this:
context TB1
interface Tokyo-LAN
arp arpa
ip address 5.1.1.0/24
exit
interface Tokyo-Bucharest
arp arpa
ip address 10.1.1.2/24
exit
interface Tokyo-Tunnel tunnel
ip address 9.9.9.1/32
exit
ipsec policy ikev2 phase1 name si_p1
suite3
gw-authentication psk open_sesame
peer-authentication psk
exit
exit
ipsec policy ikev2 phase2 name si_p2
suite4
exit
exit
exit
tunnel Tokyo-Bucharest-TUN type ipsec protcol ip44 context TB1
enable
ip local 10.1.1.2 remote 10.1.1.1
bind interface Tokyo-Tunnel TB1
ip route 6.1.1.0/24
ip route 9.9.9.2/32
exit
ipsec policy ikev2 phase1 name si_p1
exit
ipsec policy ikev2 phase2 name si_p2
exit
port ethernet 1/1
bind interface Tokyo-LAN TB1
exit
enable
exit
port ethernet 1/0
bind interface Tokyo-Bucharest TB1
exit
service ipsec
enable
exit
While the Bucharest config should be like this:
context BT1
interface Bucharest-LAN
arp arpa
ip address 6.1.1.0/24
exit
interface Bucharest-Tokyo
arp arpa
ip address 10.1.1.1/24
exit
interface Bucharest-Tunnel tunnel
ip address 9.9.9.2/32
exit
ipsec policy ikev2 phase1 name si_p1
suite3
gw-authentication psk open_sesame
peer-authentication psk
exit
exit
ipsec policy ikev2 phase2 name si_p2
suite4
exit
exit
exit
tunnel Bucharest-Tokyo-TUN type ipsec protcol ip44 context BT1
enable
ip local 10.1.1.1 remote 10.1.1.2
bind interface Tokyo-Tunnel TB1
ip route 5.1.1.0/24
ip route 9.9.9.1/32
exit
ipsec policy ikev2 phase1 name si_p1
exit
ipsec policy ikev2 phase2 name si_p2
exit
port ethernet 2/1
bind interface Bucharest-LAN BT1
exit
enable
exit
port ethernet 2/0
bind interface Bucharest-Tokyo BT1
exit
service ipsec
enable
exit
To verify the config, run:
Stoke [TB1]# sh ike-session list
—————————————————————————-
SLOT : 1
Session Handle : f4100214
IKE Version : 2 <LAN<->LAN>
Remote IP : 10.1.1.1
IKE-SA ID : 10.1.1.1
Session State : IPSEC-ESTABLISHED, IKE-SA DONE, CHILD-SA MATURE
——————————————————————————-
While
Stoke[TB1]#sh ike-session detail handle f4100214
displays a lot of details about this session, like ports, type of authentication, lifetime values and algorithms.
Stoke[local]#sh tun
Name CctHdl Type Admin State
—————————— ——– ———- ——- ———–
Tokyo-Bucharest-TUN ce000013 ipsec:ip44 enable up
Bucharest-Tokyo-TUN ce000014 ipsec:ip44 enable up
2 objects displayed.
Stoke[local]#sh tun name Tokyo-Bucharest-TUN
will display the details of this particular tunnel.
For the moment, afaik, this is only IPv4-over-IPv4, but I can’t hardly wait to have another e-mail from these guys saying that I can also play with mixed transport on one of their new StokeOSes. 
Tags: ipsec, lan-to-lan, passion, site-to-site, SSX-3000, stoke, techie
24
Feb
things to remember
I used to think that, once I’ve learned…till a certain reasonable point, the IPsec protocol, how hard could another tunneling protocol be? Well…rules to remember:
1. Never say “how hard can it be”
2. Never think about eGTP as “just another tunneling protocol”
Why? Because there are A LOT of acronyms and because there is A LOT of logic behind the protocol, the messaging scheme and the entities involved.
First of all, in order to be able to take a look anytime at the acronyms themselves, along with a short explanation of their meaning and a nicely reference to the most appropriate Technical Spec that describes the term in question, I use this:
LTE – A Pocket Dictionary of Acronyms
Also, the Tech-Invite.com has a very nice list of the 3GPP TSs, classifying them by feature:
So far, I am constantly using the TS 23.xxx series, where the functions and different behaviors and scenarios are described in detail, with cool message exchange diagrams and funky references for every term.
For my PhD paper I am using the TS 33.xxx series, which describe the security aspects of the SAE/EPS implementation.
All the TSs, per releases and per versions could be found at:
http://www.3gpp.org/ftp/Specs/
My general feeling so far about these TSs is that RFCs are waaaay prettier now
Sarah Brightman – tipa aia care canta alaturi de Andrea Bocelli “Time to say goodbye”, se pare ca a luat-o pe urmele Tarjei Turunen. De curand am vazut clipul Fleurs du Mal, in care soprana canta alaturi de o orchestra, un cor si o trupa de roackeri.
Desi inregistrarea din link-ul de mai jos nu e grozava, interpretarea mi se pare extraordinara. Iar gestul sopranei demonstreaza inca o data, daca mai era nevoie, ca black/heavy/<any>metal-ul si muzica simfonica sunt 2 tovarasi care fac o pereche minunata.
Fleurs du Mal
I am inviting you to visit one of my favorite sites:
The reason this is one of my favorite sites is that it is, firstly, VERY TECHNICAL of course. There are several sections where the articles are placed: Organizations, Standardization work, IETF topics, 3GPP topics, ETSI topics and…Other topics. I have to thank my VoIP guru colleague Alin for telling me about this site.
To be honest, I’ve never used any other categories, other than 3GPP and IETF topics. But these ones I have used extensively. Ranging from packet by packet IPsec negotiation, to SIP headers description, example, and a lot of scenarios, database infrastructure to UMTS and SAE architecture and scenarios, with a very welcome RFC and TS classification, I believe this site is one of the best locations where one could go to clarify technical things, to view scenarios and to take a look at packets and headers along with their analysis.
The latest link I’ve used is a secure SIP basic call from roaming, using the IMS architecture over UMTS. There are diagrams with each step of the flow, the packet dump and explanations for each packet. Gold, I say 
So take a look.
“Well, as we have talked about QoS, why not try to see it at work?”
“Good idea!” – says I
So, let’s take a look at the way 3GPP guys thought of a Dedicated Bearer creation. First of all, these dedicated bearers are structures that:
- have a specific QoS level
- unlike the default bearers, they can be both GBR and non-GBR (but not in the same time, of course) – default bearers can only be non-GBR (as per TS23.401)
- they should only be initiated from the APN, when a bearer is needed in order to send/receive data to/from a specific UE – actually, there is a Bearer Resource Command sent by the MME to the SGW on the S11 – GTP-C interface, which, if the SGW (after asking PCRF), is permitted, receives a Create Bearer Request message on the same S11 GTP-C interface. The MME forwards the Bearer Setup Request/Session Management Request to the eNB (on the S1 interface) – which verifies and deals with the resource allocation, exchanging RRC Connection Configuration messages with the UE. Once the eNB confirms the UE has enough resources to deal with another bearer, it informs the MME about this also, sending it a Bearer Setup Response/Session Management Response, which MME forwards to the SGW as a Create Bearer Response message… Pretty much what the following picture says:
Looking at the S11 interface that I particularly fancy, the first message of interest is the Bearer Resource Command, which has the headers described below. I am omitting the Flags header and any other header that has values described so far in the previous posts…
- Procedure Transaction ID : the ID of the transactions – new concept that appears now (here is 1)
- EBI – EPS Bearer ID : 5 is here ( should be between 5 and 15 – as you know, at most 11 bearers per UE)
- TAD - Traffic Aggregation Description: one of its fields is Operation Code, which, here, is set to Create New TFT, as the output of this transaction will be the creation of a new bearer, with an associated TFT
*** Second to think about stuff: When the PGW intends to create a new bearer (which must have attached a new TFT), it does so based on existing QoS rules on the PCRF. Well, those rules are defined on a per port basis, which means that PGW knows what type of traffic it should transport. And so do UE and MME when sending this command. So, assuming that the traffic triggering my bearer creation is HTTP only, the TFT will need to have a single TFT Filter, on port 80 as a Single Remote Port Type. Assuming that I am intending to send FTP only, the TFT will still have a single TFT Filter, but there will be a Remote port range low limit number of 20 and a Remote port range high limit of 21. Should I want to send both FTP and HTTP, there will be 2 TFT Filters.
- Flow QoS: this one sets the values requested by the MME for the following parameters:
— QCI – QoS Class Identifier – belongs to [1..255] – here is 3
— MBR-U – Maximum Bit Rate for Uplink
— MBR-D – Maximum Bit Rate for Downlink
— GBR-U – Guaranteed Bit Rate for Uplink
— GBR-D – Guaranteed bit Rate for Downlink
The reply from the SGW on this message is the Create Bearer Request from the SGW, which asks the MME to start the negotiation with the eNB in order to allocate resources for this bearer:
- it keeps the same EBI – 5 here
- it also keeps the Transaction ID – 1 here
- and the Bearer Context looks like this:
— EBI – same : 5
— Charging ID : if needed – here 0
— F-TEID of the S1 GTP-U interface of the SGW (!!! Remember that SGW has GTP-C _and_ GTP-U on its interface – which can be a single IP or different IP addresses-recommended – GTP-C does with MME and GTP-U does with eNB – in here it negotiates the GTP-U interface that the eNB will use to send data plane traffic on )
— F-TEID of the S5/S8 GTP-U interface of the SGW – which is headed towards the PGW – may be the same as the previous one or a different one
— Bearer QoS : which holds our beloved QoS values described in the previous eGTP post:
—– the QCI, MBR-U, MBR-D, GBR-U and GBR-D described above
—– the ARP – Allocation&Retention Priority
*** Please read TS23.401 – starting with page 38… Basically, this ARP should be interpreted as “The Priority of Allocation and Retention” – meaning this is a bearer prioritizer: marks a bearer as being more important than another one (the higher the number the more important the bearer); this matter when doing handovers, for instance, because, if you need to cut off some bearers (from lack of resources), you start by cutting off the ones with the smallest ARP values.
*** Still in the TS23.401 (page 38), you will find out that ARP is not a field, but a set of 3 (sub)fields:
— PVI : Pre-emption vulnerability
— PL : Priority Level
— PCI : Pre-emption capability
*** Details of each of them on TS23.401
— EPS Bearer TFT – as the TFT described above
If the MME verifies that everything is OK and the rest of the network is ready to create this new bearer, it replies to the above SGW’s message with a Create Bearer Response message, containing:
- Cause: set to 0 (Request accepted)
- Bearer context, having:
— EBI : set to 6 (the next EBI available) – ! still to verify with the TSs
— Cause: as above
— F-TEID – with the IP address of the S1-U eNB’s interface
— F-TEID – with the IP address of the S1-U SGW’s interface
And now we should be ready for traffic.
Whiiichhh, by the way, is encapsulated as GTPv1! Note to self: log a bug to 3GPP
* first picture is the content of the Bearer Resource Command
* subsequent 2 pictures are from the Create Bearer Request
* last 2 pictures are from the Create Bearer Response
Tags: 3GPP, ARP, bearers, EBI, eGTP, eNB, GBR, LTE, MME, non-GBR, passion, PGW, QCI, QoS, SGW, TAD, techie, TFT, UE
Everybody knows about this Quality of Service thinggie that helps admins to classify traffic and better allocate network and system resources to accommodate traffic needs and also to enforce the policies that exist for each user/groups of users – basically according to the amount of money they pay for this service
In order to enforce a QoS on SAE entities, there are a few things to keep in mind:
A. PCRF – Policy Charging Rules Function device, which basically is a database that holds specific service QoS associations for each UE – this device is interrogated by the PGW in order to find out which QoS is applied on which traffic for each UE that requests a dedicated bearer
B. HSS – Home Subscriber Server, which has _nothing_ to do with QoS; this is a static database that holds information about the UE as is, and no information about any SLA of that UE with the provider
C. Only dedicated bearers hold a QoS level as part of their TFT association
D. The QoS on SAE has multiple variants, dividing the bearers into 2 groups:
– GBR bearers (Guaranteed Bit Rate)
– non-GBR bearers
E. The TFT (Traffic Flow Template – containing the filtering components for the traffic) that is associated with a bearer is not per flow, but per direction:
- TFT-UL (TFT uplink)
- TFT -DL (TFT downlink)
Also, the TFT can be:
- bearer-level
- SDF-level (service data flow level)
Now, we are interested in the GBR bearers. The GBR profile includes the following parameters:
1. QCI – QoS Class Identifier
Rules:
a. 1 QCI corresponds to 1 bearer only
b. 2 services having different QCI values can NOT be on the same bearer (TFT)
c. 2 services having the different QCI values can NOT have the same ARP (see below) value
d. QCI values must belong to [1..255]
2. ARP - Allocation & Retention Priority
Rules:
a. this value has NO influence on QoS
b. this value is set per eNB, following the PGW’s decision
c. it is established by PCRF according to a tuple of —activity type — subscription information — admission policies—
3. GBR – Guaranteed Bit Rate
4. MBR – Maximum Bit Rate
** There are also aggregated GBR bearers: AMBR (this is per APN) and UE-AMBR (the per-non-GBR, per UE rate) — [note to myself] to study more on this!
***Things to consider:
Thinking about the Mobility/Handover scenarios, keep in mind that, when a UE moves from one eNB to another, or from one MME to another, or from one SGW to another, the QoS is enforced on ALL the EPS components. This means that the QCI, ARP, GBR, MBR rates will all be verified on the resources of the destination (destination eNB, destination MME and so on). This means further on that, should at least one of the components not have enough resources to sustain all the QoS of a specific UE, some bearers will be dropped – this, again, is a decision of the SGW, taking into consideration, of course, the signaling came from the rest of the components.
[courtesy of my LTE guru colleagues]
Tags: ARP, bearer, dedicated bearer, default bearer, eNB, GBR, handover, HSS, LTE, MBR, MME, mobility, non-GBR, passion, PCRF, PGW, QCI, QoS, SAE, SGW, techie, TFT, UE
As I was saying in a previous post, Bearers are structures that define a single QoS traffic between eNB – MME – SGW – PGW. They are created via GTP-C (control GTP) negotiation, and have effect on the actual traffic that flows between these entities (GTP-U – User plane). There 2 types of bearers: default bearers and dedicated bearers. While the default bearers are created by default during the Initial Attach procedure, simply stating that the UE is “logged in” the network (and usually no User plane traffic is permitted over these bearers), the dedicated bearers are created specifically when a particular type of application needs to send traffic over the network. If this happens, the network (here read PGW in correspondence with PCRF) looks at its QoS level. Should there be a TFT (associated to a dedicated bearer) already created for that application, the network simply uses that bearer to pass on those IP packets, otherwise it creates a new, dedicated, bearer, with a QoS specific to the needs of the application in question.
So… How is this “default bearer” created after all?
The most usual case is when the MME sends a Modify Bearer Request to the SGW. This message is a simple UDP packet, with destination port 2123, encapsulated as GTPv2. Its content looks like this:
- Flags: showing GTP version (2)
- Type of Message: “Modify Bearer Request”
- Length of Message: 30
- T-EID (Tunnel Endpoint Identifier) of the GTP-C on S11 (between MME and SGW)
- EPS Bearer ID
- F-TEID (Fully Qualified Tunnel Endpoint Identifier) which indicates the type of IP address (here it is IPv4), the type of interface where the bearer would take place (it is S1-U – S1 – User plane, the interface between the eNB served by the MME in question and the SGW in question)
** Why is this S1-U? Why this interface? Why a “U” interface? Because the purpose of the GTP-C is to negotiate the GTP-U part. Basically, via these GTP-C messages I am negotiating which are the GTP-U interfaces that will transfer the actual data. And, as MME is ONLY a GTP-C entity, it has the role of negotiating the bearers that will carry the traffic between the GTP-U entities, here eNB and SGW. So, the GTP-C passes through MME, while GTP-U does not. This is why I can see on the GTP-C message sent from MME to SGW the TEID of a S1 interface, rather than a S11 interface.
- F-TEID IPv4 – this is the IP address of the eNB, in this case 40.0.0.3
** This F-TEID IPv4 is the actual IP address that eNB will use in order to send data-plane packets flowing between UE and PDN. As the path of the GTP-U is between UE – eNB – SGW – PGW – PDN ( the MME only appears in the GTP-C flow), the F-TEID IPv4 address here should have layer 3 connectivity with the SGW IP address. I had a rough time today trying to understand why on earth my GTP-U traffic disappeared, while I was having the eNB and SGW IP addresses on two different subnets and no router to route packets from one subnet to another – smarty, I know
The Modify Bearer Request packet looks something like this:
If the MME has been a good kid (and the UE also), the SGW acknowledges its request and responds with a Modify Bearer Response packet having as Cause : Request accepted. The fields of this packet are the following:
- Flags – indicating the GTPv2 and some other stuff
- Cause – has the IE (Information Element) type, which is 2 here, Cause being Request Accepted and the ID of the Cause is 0 (it should be different than 0 if the request were not accepted)
- Bearer Context – this indicates that the SGW reserved resources for a new context (default one) and instructs the eNB and the PGW to do the same; this field contains the
- – - EPS Bearer ID : 5
- – - Cause subfield : indicates “Request accepted”
- – - F-TEID: type of IPv4, the interface is S1-U (S1 – User plane between eNB and SGW) and the F-TEID IP is the IP address of the SGW (40.0.0.2)
Basically this message confirms the creation of the Default Bearer, the reservation of the network resources for the traffic flowing over this bearer (if any). The user is officially logged in the network and has the first, most simple and non-priviledged session with the PDN.
The Modify Bearer Response packet looks something like this:
—
Tags: bearers, dedicated bearer, default bearer, GTP-C, GTP-U, LTE, MME, passion, PDN, PGW, S1-U, S11, SAE, SGW, techie, TFT, UE
Eu am donat. Doneaza si tu.
Most Popular Posts
Recent Comments
- X2-based handovers | Windancer - Stairway to ...Heaven? on Mobility over LTE/SAE
- adin on Capoeira – in Bucuresti
- cristina_crow on Mobility over LTE/SAE
- Rakesh on Mobility over LTE/SAE
- cristina_crow on Mobility over LTE/SAE
- Rakesh on Mobility over LTE/SAE
- Patrik on I haz bukz !!!
- cristina_crow on ma gandeam cum sa fac anuntul mai amuzant
- paispe on ma gandeam cum sa fac anuntul mai amuzant
- cristina_crow on ma gandeam cum sa fac anuntul mai amuzant