Tag Archives: ECM_IDLE

LTE / EUTRAN – Idle Detach

In order to keep radio resources free, if a UE doesn’t send or receive data for a predefined threshold, it’ll detach from the network and call back to Idle mode.

If the UE has data to send to the network, the UE will re-attach to the network, whereas if the network has data to send to the UE, it’ll Page the UE in the tracking area it’s currently in, the UE is always listening for it’s identifier (s-TMSI) on the paging channel, and if it hears it’s identifier called, the UE will re-attach.

I’ve also attached a PCAP file of the packet flow between the eNB and the MME.

UEContextReleaseRequest [RadioNetwork-cause=user-inactivity]

The first packet is sent by the eNB to the serving MME to indicate the user wishes to detach from the network.

PCAP of UEContextReleaseRequest from eNB to MME

UEContextReleaseCommand [NAS-cause=normal-release]

The next packet is sent from the MME back to the eNB confirming UE is releasing from the network.

UEContextReleaseCommand

UEContextReleaseComplete

Finally after the UE has released it’s radio resources the eNB sends a UEContextReleaseComplete so the MME knows the UE is now in Idle state and will need to be paged.

UEContextReleaseComplete response

IMTx: NET02x (4G Network Essentials) – Management of Sporadic Data Flows – 3. Standby Modes

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

As we discussed before when no data has been sent by a UE for a period of time the eNB will switch from an ECM-Connected state to an ECM-Idle state where there is no radio connection.

ECM-Connected state

So let’s look at the release procedure.

When the transmission timeout (typically 10 – 30 seconds) has expired, meaning a user hasn’t sent data for that length of time, the eNB sends the MME a S1-AP UE Context Release Request with the cause of User Inactivity to denote why the change is being made.

The MME then sends a GTP-C message requesting release of the tunnel between the S-GW and the eNB (GTP-C Release request).

The S-GW sends back a GTP-C Release Access Bearers response, indicating it has cleared down the GTP tunnel between itself and the eNB,

The MME then sends a S1-AP UE Context Release Command to the eNB, and the eNB sends an RRCConnectionRelease which releases the RNTI assigned to that UE removing it’s radio resources.

Finally a S1-AP UE Context Release Complete is sent from eNB to the MME to let the MME know the process has completed.

Release procedure

At this stage the RNTI is no longer active so the UE cannot use the RNTI and therefore cannot be assigned radio resources.

The UE is now in ECM_Idle mode, however as it still has an IP Address allocated and can be bought back it’s in EMM_Regsitered mode.

States

EMM-Deregistered State

UE is disconnected from the network with no radio resources and does not have an IP Address

EMM-Registered & ECM-Connected

  • UE is connected to the network with an IP address
  • Radio resources (RNTI allocated)
  • Location of the UE known
  • All tunnels & connections established

EMM-Regsitered & ECM-Idle

  • UE has an IP address & appears to be connected
  • No radio resources (RNTI) currently in use
  • No tunnels or connection from the eNB to the S-GW & MME.
  • Tunnel between S-GW and P-GW and the tunnel between the MME and S-GW
  • A relative location (tracking area) of the UE is available

IMTx: NET02x (4G Network Essentials) – Management of Sporadic Data Flows – 4. UE Triggered Service Request

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

As we just saw when a terminal moves to ECC-Idle while in EMM-Registered state, it releases it’s radio resources, so what happens when the UE needs to send / receive data again?

UE is disconnected from Radio Resources (ECM-Idle & EMM Registered)

While one option could have been to go through the full attach procedure again when the UE is triggered, the 3GPP team wanted the re-connection process to be as fast as possible.

As we saw in the last post we don’t drop the S-GW <-> P-GW tunnel, which saves time on re-establishing a connection. The S1 tunnel is also not completely released; the TEID value from the S-GW end of the tunnel is saved by the MME so it can be reused by the new tunnel when the UE reconnects, without needing to inform the S-GW.

IMTx: NET02x (4G Network Essentials) – Management of Sporadic Data Flows – 2. UE Connection to the Network

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

One of the common themes we cover over and over in the 4G discussion is the desire to preserve energy on the UE RF side of things, to extend battery life as much as possible.

The 3GPPs requirements for LTE also included the smallest round trip times, defining less than 5 ms in unload condition, so traffic to the UE must be routed as quickly as possible.

Mobiles are by their very nature, mobile.

This requires UEs to constantly monitor the RF conditions and the signal measurements from different base stations so the UE can determine if it’s time to handoff to another cell due to going further from one eNB and closer to another, or another eNB offering better RF conditions (Strong signal etc).

This requires regular exchanges of messages and checks, but this would take a lot of energy and eat up battery usage.

Instead we avoid maintaining the radio connection all the time with the aid of an inactivity timer on the eNB.

For as long as user data is flowing over the air interface the connection is maintained, for example web browsing, the inactivity timer is constantly reset as traffic flows.

However when the eNB detects no packets sent or received by the UE the timer starts counting down from it’s set value.

When the inactivity timer reaches 0 the RRC Connection is released and the UE no longer has an RNTI.

The UE is still listening to an eNB, it’s just not sending data to it it and visa-versa.

As the radio bearer has been removed the UE the S1-AP and S1-UP bearers between the eNB and the MME and the eNB and the S-GW respectively, can be torn down.

This means the MME is no long sure of exactly which eNB the UE is listening on.

This is referred to as ECM_IDLE state as there is no radio connection, and the network is unaware of the precise location of the UE.

An ECM_ACTIVE state is the state when the UE is connected to an eNB with an RNTI and it’s inactivity timer has not reached 0.

The dotted line bearers shown in the image above frequently change between active and inactive based on the ECM_ACTIVE / ECM_INACTIVE state of the bearers.