What happens if I don’t use the radio functions of my terminal for a long period, typically 10 or 20 seconds, for example, because I’m not looking at a Web site or I don’t have an application sending data to the network or receiving data? We know the answer: we will switch from the state ECM-Connected (with a radio connection) to the state ECM-IDLE (where there is no radio connection). Here’s the initial state we’re talking about. The terminal has a set of tunnels and connections established, including the radio connection, it is in ECM-Connected state and the MME has memorized ECM-Connected state, with regards to the terminal we’re discussing. Here, we see the release procedure. We show bearers that have been established. The terminal is inactive, in other words, there hasn’t been a transmission of user packets for a certain time. At the end of this time, typically ten, twenty or thirty seconds, the eNodeB sends an S1-AP message, requesting the release of the context. It will indicate the reason: user inactivity. The MME then sends a GTP control message, requesting the release of the tunnel between the SGW and the eNodeB. The SGW processes the request and responds positively to the MME, it means that the release has been done and the MME informs the eNodeB that the release is to be done on its side. The eNodeB informs the terminal that the connection has been released. The terminal returns to standby mode. If the user is playing a game and it’s a game that does not generate radio exchanges, the terminal remains active. however, from a radio point of view, it is inactive. It considers that the RNTI is no longer allocated, so it can no longer use the RNTI, and the eNodeB releases the radio connection and the RNTI. Once this is done, the eNodeB responds to the MME to indicate that release has been fully carried out. At the end of this procedure, the terminal and the MME for this terminal return to the state ECM-IDLE. On the other hand, the terminal keeps its IP address, so it remains in the state EMM-Registered. So, we have two types of states: ECM states and EMM states. In EMM-Deregistered state, the terminal does not exist, from the point of view of the network, so it is necessarily in ECM-IDLE state. It is disconnected from the network and does not have an IP address. In EMM-Registered and ECM-Connected, the terminal is connected to the network: it has an IP address and an RNTI, its location is known down to the cell level by the MME and all the tunnels and the connections have been established. In EMM-Registered and ECM-IDLE (from the point of view of the applications and the user), it is still connected. The terminal appears to be connected to the network: it has its IP address, but it does not have an RNTI allocated, and there is no tunnel or connection leading from the eNodeB. However, the tunnel between the Serving Gateway and the P Gateway, and the tunnel between the Serving Gateway and the MME are maintained. Why? Because a Serving Gateway manages a large area and the probability of changing Serving Gateways within several minutes is relatively low. In this state, EMM Registered and ECM-IDLE, the precise cell location of the UE is not known exactly. The network is not too concerned about knowing in exactly which cell the terminal is located. So we have the following: when the cell phone is completely absent from the network, it is not associated to a Serving Gateway or P Gateway (I’ve added a few in the diagram). When it attaches to the network, it changes to EMM-Registered and ECM-Connected, there is an RRCx connection, all tunnels are established. When the inactivity timer times out, its state will change to ECM-IDLE, but it will remain in EMM-Registered state, in other words, it keeps the IP address.
