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 MMErelocation 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

* 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

At first, I thought I was too noob to understand this stuff. I still consider myself a noob, but the way these TSs are written sometimes really gets on my nerves.

Let’s just consider the case of the S1-based handover with MME relocation and SGW relocation and Indirect Tunneling – meaning there is no X2 link between the source and target eNBs. All I can do for the moment is to look at the S11 interface, because this is the one I have the opportunity to study at this point.

So, the 2 TSs involved in this case, at least at the high level are TS 23.401 – which describes the message flows between the SAE entities and TS 29.274 – which describes each message and its IEs.

The S1 based handover with MME/SGW relocation and Indirect Tunneling looks something like this:

In order to make this more human-readable, I have considered the following scenario:

where my UE (UE-1) moves from eNB 30.0.0.1 to eNB 30.0.0.5 (which have an X2 link together) – doing X2 handover (with no MME relocation), then it moves from eNB 30.0.0.5 to eNB 30.0.0.8 (which don’t have an X2 link between them). As you can see from the picture, these 2 eNBs belong to 2 different MMEs and SGWs. This means that, when the UE moves from eNB5 (30.0.0.5) to eNB8(30.0.0.8), it will generate an S1 handover signaling between the source MME – MME1 (30.0.1.1), source SGW – SGW1 (30.0.2.1), target MME – MME4 (30.0.1.4) and target SGW – SGW2 (30.0.2.2). As there is no X2 link between eNB5 and eNB5, the downlink packets coming from the PGW while the UE is in the handover process with reach eNB5, then they will be “reflected” back to SG1, which will then forward them via an “indirect” tunnel to SGW2, which will forward them to the new eNB8, which is in charge of my UE.

The flow is like this (3GPP copy-pasted 🙂 )

1) So, as this picture states, once the handover is decided, the source MME sends a Forward Relocation Request to the target MME. This message must at least contain the following mandatory IEs, as per TS 29.274:

– IMSI

– Sender’s F-TEID for Control Plane

– MME/SGSN UE EPS PDN Connections

– SGW S11/S4 IP Address and TEID for Control Plane

– MME/SGSN UE MM Context

2) Then the target MME sends a Create Session Request message to the target SGW, including (M == Mandatory):

– IMSI (M)

– RAT Type – here is E-UTRAN (M)

– Sender F-TEID for Control Plane – here it is the IP address of the source MME: 30.0.1.4 + it’s TEID/GRE Key (this “key” is actually a hexadecimal number on 2 bytes) (M)

– APN Name (M)

– Maximum APN Restriction (M)

– LBI – Linked EPS Bearer ID – indicates the default bearer of the connection – the ID of the default bearer, usually this has value 5 (C)

– PGW S5/S8 Address for Control Plane or PMIP – this is the IP address of the PGW: 20.0.0.1 (C)

3) the target SGW replies to the target MME with a Create Session Response message, containing:

– Cause (M)

– Sender F-TEID for Control Plane – this is the IP address of the target SGW: 30.0.2.2 (C)

– APN Restriction (M)

– Bearer Contexts created (M) – this means that all the bearers that have the OK to be created for the UE in question are going to be present here, in a separate group IE; the IEs within a Bearer Context have the following:

— EBI – EPS Bearer ID (M)

— Cause (M)

— S1-U SGW F-TEID – the IP address of the SGW used for user-plane and a TEID/GRE identifier on 2 bytes – this is usually the same identifier used for the initial traffic of this user, _before_ the handover, let’s just call it Key-A – which is the uplink identifier for the user (C)

— Bearer Level QoS – the new QoS parameters, if they have been changed (C)

** Let’s stop for a second a recap. What do I have at this point? I have an UE (UE-1 in the picture) with an IP address (let’s say: 40.0.0.91). It is attached to the eNB 30.0.0.5, having a default bearer in place with the MME 30.0.1.1 (source) and the SGW 30.0.2.1 (source). This default bearer has an uplink identifier TEID, called as above Key-A, which also has a downlink identifier TEID, called Key-1. Let’s say that what travels in uplink has a key made out of letters, and what travels in downlink has keys made out of numbers 🙂

Ooook, what’s next. Well, as my UE moves to eNB 30.0.0.8, AND there is no X2 link between eNB5 and eNB8, target MME creates an indirect tunnel for the packets. Once the UE has moved to eNB8, the uplink flows directly from this new eNB, to the new SGW and so on. So, the indirect path is for the downlink packets, more precisely, for THOSE downlink packets that have already been routed by the source SGW to the source eNB (eNB5). eNB5 cannot contact eNB8 directly, so it re-routes these packets back to the source SGW, which will also re-route them via this indirect tunnel to the target SGW – which has direct S1-U connectivity to the target eNB to deliver the packets to my dear UE 🙂

How does EPC do that?

4) Target MME (30.0.1.4) sends a Create Indirect Data Forwarding Tunnel Request message to the Target SGW (30.0.2.2), containing all the grouped IEs Bearer Contexts that are to be forwarded this way, this grouped IE being the only Mandatory IE in this message. This Bearer Context IE contains:

— EBI – EPS Bearer ID (M)

— S1-U eNodeB F-TEID for data forwarding – this is the IP address of the target eNB (30.0.0.8) and its associated TEID/GRE key, let’s call it Key -2. This key instructs the target SGW about the destination of the packets for my UE (C)

5) then the Target SGW (30.0.2.2) responds to this message with a Create Indirect Data Forwarding Tunnel Response message. This message has 2 Mandatory IEs: the Cause and the Bearer Contexts grouped IE. This Bearer Context IE has:

— EBI (M)

— Cause (M)

— S1-U SGW F-TEID for data forwarding – this is the IP address of the target SGW and its TEID/GRE identifier – Key-B

6) After this, the target MME sends a Forward Relocation Response message to the source MME, instructing it about the bearers that have been accepted for creation on this indirect path

7) Now, the source MME (30.0.1.1) sends a Create Indirect Data Forwarding Tunnel Request to the source SGW (30.0.2.1), with elements similar to the corresponding message above, except that in this case, the Bearer Context has the TEID/GRE identifiers of the target SGW, contained in the Create Indirect Data Forwarding Tunnel Response from above – Key-B – when source SGW will forward the packets to target SGW, this will be the GRE Identifier used for encapsulating those packets

8) The source SGW responds with a Create Indirect Data Forwarding Tunnel Response message, same as above, but the TEID/GRE ID is the one of the IP address of the source SGW. This ID shall be used for uplink data on the indirect tunnel from the source eNB to the source SGW. Let’s call this ID Key-3.

*** At this point, we have an indirect tunnel created between the following entities:

source eNB (30.0.0.5) -> source SGW (30.0.2.1) : TEID Key-3

source SGW (30.0.2.1) -> target SGW (30.0.2.2) : TEID Key-B

target SGW (30.0.2.2) -> target eNB (30.0.0.8) : TEID Key-2

At this point, the user traffic is like this:

1: packets already forwarded by the source SGW to the source eNB are “reflected” by this eNB – use the downlink GRE ID established initially, Key-1

2: the reflected packets from source eNB back to source SGW use the GRE negotiated via the messages above: Key-3

3: packets then travel on the tunnel from source to target SGW, via the TEID/GRE ID: Key-B

4: then the target SGW finally forwards the packets down to the target eNB via GRE ID: Key-2

*** During all this complicated process, the uplink is already using the target eNB as source for the encapsulating tunnel

So, what happens afterwards?

9) the target MME sends a Modify Bearer Request message to the target SGW, describing the newly created tunnels for downlink, not the indirect ones, the usual, direct ones and the target SGW replies with a Modify Bearer Response message in order to acknowledge (or state a cause for rejecting) this

10) the source MME deletes its session from its (source) SGW, using a Delete Session Request / Delete Session Response pair of messages, carefully indicating the SGW that this is only a “local detach” of the UE, not a complete detach, meaning that the UE just moved and the local information about it is no longer valid, NOT that the UE disappeared from the network and the resources are to be deleted !

EXCEPT Me, because there are a lot of misleading and confusing “explanations” in the specs regarding this type of scenarios, like for instance:

a) one spec (TS 23.401) states that the delete session procedure should have Cause and LBI IEs in the Create Session Request message, while TS 29.274 defines these 2 IEs as Conditional, and, as per the condition in place, none of them should appear in this message when the source MME disconnects from the source SGW. Instead, the SGW should look at the Indication Flags in this request: if the Operation Indication is set, then this is a full detach, if the Scope Indication is set, this is a local detach.

b) look at the above flags: shouldn’t it be better to have just 1 flag, and, if it is set, we have a full detach, otherwise we have a local detach?

c) what happens in the S1 handover with no SGW relocation (whether or not the MME is relocated) and Indirect Tunneling? How is that going? Do I still send the two pairs of Create Indirect Data Forwarding Tunnel Request/Response?

Let’s have a short (very short) talk about this DAF thinggie. DAF stands for Dual Address Bearer and it is a flag only set in the Create Session Request message, sent from the MME to the SGW, over the S11 interface. Details about this funky flag are in TS 23.401 (Section 5.3.2.1 E-UTRAN Initial Attach and Section 5.3.1 IP Address Allocation) and in TS 29.274 (Table 7.2.1-1 Information Elements in Create Session Request) and…might be in other TSs also, but I have no idea about those 😛

So, when and why we do use this flag? Mwell, TS 29.284 says the following:

DAF – Conditional : Dual Address Bearer Flag: This flag shall be set to 1 when the UE requests a PDN type IPv4v6 and all SGSNs which the UE may be handed over to support dual addressing. This shall be determined based on node pre-configuration by the operator.

So, this flag is an indication sent from the MME to the SGW, telling the SGW at the moment of the Initial Attach procedure: Hey! you know what? My mobile device supports dual-stack. You can assign it at once, on the same bearer, both an IPv4 and an IPv6.

Also, if the UE moves from a 3G coverage to a 4G coverage (the definition above says the other way around, but logic tells me that the MME actually sends a Create Session Request when it is a _target_ MME, therefore when the UE moves from a 3G to a 4G network), doing an MME relocation, SGW relocation handover procedure, our MME would says the following to its fellow SGW: Dear SGW, my mobile device has just arrived here from a 3G network, more specifically from an SGSN that supports dual addressing. So don’t worry that I am asking for both an IPv4 and IPv6 addresses for the same bearer for this UE.

Now, there are several rules when using or not this DAF. The general rule is to set it, which seems to be the default rule in the 4G network context.

The only case when, in a 4G context we do NOT set this flag is when the interface between the SGW and the PGW (the S5/S8 interface) runs PMIP, and not GTPv2 (as S11 does).

So, usually, in this most common case, the UE that supports dual-stack will ask for a single default bearer, having an IPv4v6 dual-stack type of address. If the MME is running in a full 4G environment or it is aware that all SGSNs to which the user may handover to also support dual-stack and the MME is aware that the S5/S8 interface runs GTPv2, then the MME will set the DAF flag and hopefully the PGW also supports dual-stack, our dear UE will get an IPv4v6 address, actually meaning that it will get 2 IP addresses (one IPv4 and one IPv6) for the same, single, default bearer to this APN.

But, even if the UE says it supports dual-stack, but the MME considers, for some reasons it has (it is aware of non-compatible SGSN, or it knows about S5/S8 running PMIP or whatever), not to set the DAF flag, then the UE’s type of address remains to be decided by the PGW….as it follows:

The PDN GW takes into account the received PDN type, the Dual Address Bearer Flag and the policies of operator when the PDN GW selects the PDN type to be used as follows. If the received PDN type is IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing for this APN is possible in the PDN, the PDN GW selects a single IP version (either IPv4 or IPv6). If the received PDN type is IPv4 or IPv6, the PDN GW uses the received PDN type if it is supported in the PDN, otherwise an appropriate error cause will be returned. The PDN GW allocates a PDN Address according to the selected PDN type. If the PDN GW has selected a PDN type different from the received PDN Type, the PDN GW indicates together with the PDN type IE a reason cause to the UE why the PDN type has been modified.

What about the UE. What should it do after getting an IP?

After the Attach Accept message and once the UE has obtained a PDN Address, the UE can then send uplink packets towards the eNodeB which will then be tunnelled to the Serving GW and PDN GW. If the UE requested for a dual address PDN type (IPv4v6) to a given APN and was granted a single address PDN type (IPv4 or IPv6) by the network with a reason cause indicating that only single IP version per PDN connection is allowed sent together with the PDN type, the UE may request for the activation of a parallel PDN connection to the same APN with a single address PDN type (IPv4 or IPv6) other than the one already activated. If the UE receives no reason cause in step 18 in response to an IPv4v6 PDN type and it receives an IPv6 Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN Address field, it considers that the request for a dual address PDN was successful. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.

Now, the applications on the UE must know which type of socket to create. They can either create an IPv4 or an IPv6 socket and choose among the available IP addresses.

2. an UE can have multiple default bearers per APN connection: for example, one for IPv4 and one for IPv6;

2.a) 2 default bearers per APN connection are possible when the MME does NOT set the Dual Address Bearer Flag; this way, the MME forces the sending of separate IPv4 and IPv6 requests for PDN connectivity;

2.b) if the MME sets the Dual Address Bearer Flag, then it can send a request with dual-stack IPv4v6 and the APN can provide both of these IP addresses at once – this means that there are 2 IP addresses (one IPv4 and one IPv6 ONLY one of each type !) for a SINGLE default bearer;

3. Allocation of these IP addresses to the UE can happen from a local PGW pool or from the PDN. In the later case, the Create Session Response message sent from the PGW to the SGW (and further on to the MME) has PAA = 0.0.0.0, following the later completion of this address;

3.a) If the PGW has nothing to do with the further negotiation of the IP addresses, we are talking about a direct transparent access IP allocation; the PGW is just a proxy;

3.b) If the PGW is actively (protocol dependent) implicated in the IP address allocation, then we are talking about a non transparent access; the PGW is an active part in the IP negotiation: for instance, it may act as a DHCP server for the UE (via SGW, of course) and in the same time as DHCP client – when talking to the APN’s actual DHCP server;

*Note: the role of the PGW in the DHCP allocation case is different from the role of its 3G homologous, the GGSN – this entity playing the role of a DHCP relay agent in this scenario;

*Note: We are talking about the so-called IP-CAN (Connectivity to Access Network) session establishment – which, as far as I understand from TS 29.061, refers to the process of allocating an IP address (IPv4, IPv6 or IPv4v6) by a process other than gathering it from the PGW pool, for instance: via DHCP/DHCP-PD, PPP, IMS CN IM process…etc…

Doing some more reading in the TS 29.061, I ended up in some other dilemmas.

The following information results from this spec so far (as per my understanding):

1. the PGW acts as a “proxy” for the SIP-IMS messages, encapsulating them in GTPv1-U

2. in order for the PGW to locate the P-CSCF, this PGW can have a pre-configured list of P-CSCFs

3. when the UE connects to that APN, the PGW must look through the list of pre-configured Ps, verify which ones are still up (by using ICMP, for example) and send to the UE a list of Ps; if there are multiple Ps in the list, the PGW will use the PCO IE to provide to the UE a prioritized list of Ps

Now, the dilemma comes. As the PGW is a control-plane entity and a user-plane entity in the 4G world, it can send both 4G control-plane messages (to the SGW – that may propagate or not till the MME – GTPv2-C messages) and user-plane messages (which are GTPv1-U messages encapsulating SIP, DHCP, whatever protocol).

TS 29.061 states the following, about how the PGW sends the IP / IPs of the P-CSCF to the UE: – section 13a.2.2 IMS Specific Procedures in the GGSN/P-GW:

The GGSN/P-GW shall then provide only those P-CSCF address(es) that are available in a Create PDP Context Response/Create Bearer Response.

Now, there are 2 issues with this statement:

1. the Create Bearer Response message is actually sent FROM the MME/SGW TO the PGW; the PGW is the one sending the Create Bearer Request message

2. disregarding item 1 and only thinking about the fact that the PGW will send the IP of the P-CSCF as part of the GTPv2-C signaling (rather the proxying it via the GTPv1-U tunnel), TS 29.274 leaves no room for more IEs in the Bearer Context grouped IE:

Table 7.2.3-2: Bearer Context within Create Bearer Request

Octets 1

Bearer Context IE Type = 93 (decimal)

Octets 2 and 3

Length = n

Octets 4

Spare and Instance fields

Information elements

P

Condition / Comment

IE Type

Ins.

EPS Bearer ID

M

This IE shall be set to 0.

EBI

0

TFT

M

This IE can contain both uplink and downlink packet filters to be sent to the UE. Downlink packet filters are also used by SGW for PMIP based S5/8 interfaces.

Bearer TFT

0

S1-U SGW F-TEID

C

This IE shall be sent on the S11 interface if the S1-U interface is used.

F-TEID

0

S5/8-U PGW F-TEID

C

This IE shall be sent on the S4, S5/S8 and S11 interfaces.

F-TEID

1

S12 SGW F-TEID

C

This IE shall be sent on the S4 interface if the S12 interface is used.

F-TEID

2

S4-U SGW F-TEID

C

This IE shall be sent on the S4 interface if the S4-U interface is used.

F-TEID

3

Bearer Level QoS

M

Bearer QoS

0

Charging Id

C

This IE shall be sent on the S5/S8 interface.

Charging Id

0

Bearer Flags

O

Applicable flags are:

– PPC (Prohibit Payload Compression)

Bearer Flags

0

So, if the 3GPP guys actually claim to configure multiple P-CSCF addresses in the above grouped IE, where are they putting those IP addresses? where:

I’ve been looking, as one of this blog’s readers asked for, a 3GPP spec to describe the functionality of the PGW (or SGW)..or, for the matter of fact, the 4G network element that deals with the IMS interaction. The common sense advised me the “culprit” in this matter should be the PGW.

3. all user-plane traffic that flows from the eNB via the SGW to the PGW is encapsulated in GTPv1-U tunnels

4. there is a “default” bearer structure that represents the connection of the UE to the PGW (PGW being the one that allocates the IP for the UE and it is also the main anchor point for mobility purposes) – this bearer is only used for fallback and the specs don’t recommend sending user-data over it; the QoS and attributes of the default bearer reside in the local 4G HSS database, connected via S6a to the MME

5. in order to be able to better shape the user-plane traffic, there are “dedicated” bearer structures that have a QoS class associated; the PCRF contains the information about these bearers, classifying traffic according to its importance; the PGW is the one responsible to communicate with PCRF, gather these rules and trigger the dedicated bearers creation to sustain this traffic

6. the PGW deals with encapsulation of the downlink data into the correct GTPv1-U tunnels according to the appropriate QoS settings – which results in specific user-plane bearer identifiers being used to identify these tunnels; also, the PGW deals with the decapsulation of the uplink data traffic and routing it to the appropriate destination in the Internet/IMS networks/intranet…etc. As the enforcer of the QoS patterns, the PGW acts as border MPLS router, translating the bearer QoS structures into plain IP QoS structures

In the TS 29.061 – section 13.a, the 3GPP guys shortly define the roles of the PGW:

This procedure is used to release the logical S1-AP signalling connection (over S1-MME) and all S1 bearers (in S1-U) for a UE. The procedure will move the UE from ECM-CONNECTED to ECM-IDLE in both the UE and MME, and all UE related context information is deleted in the eNodeB.

Unfortunately, this is not exhaustive. The things described here DO happen, but something ELSE DOES NOT happen.

Step 3 in the procedure clarifies the situation:

3. The S‑GW releases all eNodeB related information (address and TEIDs) for the UE and responds with a Release Access Bearers Response message to the MME. Other elements of the UE’s S‑GW context are not affected. The S‑GW retains the S1-U configuration that the S‑GW allocated for the UE’s bearers. The S‑GW starts buffering downlink packets received for the UE and initiating the “Network Triggered Service Request” procedure, described in clause 5.3.4.3, if downlink packets arrive for the UE. If the MME sends UE’s Location Information in step 8, the S‑GW sends a Modify Bearer Request to the PDN GW including the User Location Information IE.

Ok, so the 3GPP guys let us believe the ECM-IDLE ==EQUALS== NO user-plane bearers. OK, point taken, there are some bearers still up.

Buuut, this affects us when talking about the following scenario:

Take a look at the TS 23.401 – 5.3.4.1 UE Triggered Service Request. What is this section actually describing? Well, it says that the UE, while in ECM-IDLE simply decides to make traffic. What does it do first? Well, it has to become CONNECTED, that’s for sure, so it re-authenticates to the HSS via the MME, then the MME sends its eNB a S1-AP: Initial Context Setup Request. After the Radio Bearers are up, the UE CAN IMMEDIATELY SEND TRAFFIC in UPLINK.

!!! You will notice that, at this point, the UE is not in ECM-CONNECTED, as we define this state, meaning that there are no eNB S1-U bearers up. STILL, should you keep in mind the observations in the beginning of this post (that the SGW S1-U TEIDs are NOT deleted in the S1 Release Procedure), the eNB actually has the Uplink TEID, so it CAN encapsulate the Uplink data of this UE. The TEID of the SGW S1-U interface is passed on to the eNB by the MME, via the S1-AP: Initial Context Setup Request message.

You’ll notice that barely after the UE actually uplinks data is the MME and SGW updating this UE’s information so that we can truly say it is in ECM-CONNECTED state.

There are 2 scenarios that involve the “awakening” of the UE from ECM-IDLE to ECM-CONNECTED:

A. The PCRF decides the creation of a new dedicated bearer, via the Create Bearer Request message. The Spec (TS 23.401) describes this procedure in 3 places:

1. TS23.401 – 5.4.1 Dedicated bearer activation

– in step 3 (corresponding to the sending of Create Bearer Request from SGW to MME), it states that, if the UE is in ECM-IDLE, then the MME with do the “network triggered service request” procedure (5.3.4.3) first, buffering the Create Bearer Request message received from the SGW, until it awakens the UE

2. TS23.401 – 5.3.4.3 Network Triggered Service Request

– this section starts with an introduction that indicates the procedure should begin from step 3 if this procedure is triggered by a control-plane signaling coming from the SGW (like in my case); and step 3 is Paging the UE

– after this, the procedure “calls” yet another procedure, namely the UE triggered service request procedure

3. TS23.401 – 5.3.4.1 UE Triggered Service Request

– this procedure includes the NAS Service Request, the Authentication process and the setup of the bearer contexts

It’s like calling recursive procedures in programming. Very hard to follow, when trying to understand a scenario. Visually it should look something like this…

B. The “second” scenarios happens (or at least to my understanding happens) specifically when there is downlink data to be sent from the SGW to the UE, without (necessarily???) having to send control-plane signaling.

In this case, the hop-by-hoping through the sections of TS 23.401 starts with

1. TS 23.401 – 5.3.4.3 Network Triggered Service Request

with Step 1

and, nevertheless, we get to

2. TS 23.401 – 5.3.4.1 UE Triggered Service Request

which is executed fully, just as in the first scenario, then the execution flows goes back to 5.3.4.3

2. the network decides to delete some of the UE’s bearers, by sending a Delete Bearer Request message to the MME managing this UE

Question:

– Will the UE first be woken-up from ECM-IDLE and become CONNTECTED, and then the Delete Bearer Request is processed and responded? Or simply the MME will process the Delete Bearer Request message and NOT put the UE in ECM-CONNECTED?