What happens when I turn my 4G terminal on or off? That is the question we are going to answer in this video. A 4G terminal has a permanent IP connectivity as long as we don’t, for example, turn on flight/airplane mode. As soon as it is powered up, the terminal requests the establishment of bearers for the various tunnels for its IP connectivity. The default bearer is then maintained independently of how the terminal is used. To establish connectivity, an EPS Connectivity Request message is sent by the terminal. In reality, as we will see, this message is included in the attachment message, in other words, the attachment and the establishment of connectivity are made at the same time. First, let’s look at how things are when we consider a powered down terminal. It’s important for the network to know whether a terminal can be reached or not. Therefore, we have the notion of “state”, which is memorized for each terminal. This state, when attachment has not been made, is called EMM deregistered, which means that the cell phone is not reachable; it could be powered down or in flight/airplane mode. We can imagine that the terminal has already been used and that it already has a security association and a temporary identity, here GUTI 1. The MME memorizes the state of the terminal and the context elements. To attach to the network and request a connection, we’ll have the following messages: the terminal sends an EMM attach request with GUTI 1 and puts in the same message an ESM PDN Connectivity Request message which has a different meaning. That means: the UE requests connectivity to the external IP network. It will indicate in the message the type of connectivity it wants, IPv4 or IPv6. We will have, inside this procedure, the establishment of the S1-AP connection. We’re not going to go into detail here and we’re going to assume that the terminal communicates with the MME. Of course, all messages go through the eNodeB. What the MME will does is: analyze the type of connectivity requested, IPv4 or IPv6, find the default APN, Access Point Name, which is stored in the subscriber profile, and select the Serving Gateway and the P-Gateway. The MME then creates a control tunnel with the SGW using the Create Session Request message. Inside, the subscriber IMSI, the type of IP requested and the APN are indicated. The S-Gateway passes on the request to the P-Gateway and we can imagine here that there is a DHCP-type mechanism to automatically allocate the IP address, DHCP meaning Dynamic Host Configuration Protocol. The message we see and the following messages include the TEIDs to establish the tunnels. The P-Gateway indicates the IP address in its response to the request for a tunnel. As soon as this message is received, the two pieces of equipment know the TEIDs of the opposite end and the S5/S8 bearer is established. The S-Gateway sends a response, still transporting the allocated IP address, this IP address will be memorized by the MME. The MME will probably renew the temporary identity, choosing a different GUTI and will send the following messages. First, an EMM Attach Accept message with the GUTI, for the terminal, this means, OK, you’re taken into account by the network. And second, an ESM Activate default EPS bearer context request message with the IP address, the response to the previous request. The terminal stores the IP address and the GUTI and will then acknowledge, indicating the attachment was successful and that the establishment of the context, in other words, the IP address, has been stored. And the MME will then indicate to the S-Gateway that it must establish the S1 bearer: the data tunnel between the eNodeB and the Serving Gateway. At the end of the procedure, we have a terminal in the EMM Registered state, meaning it has been taken into account, it has a security association and an IP address. The context is updated by the MME, which retains the IP address and the security association, of course, corresponding to the terminal. The S-Gateway and the P-Gateway also have context elements since they need to store the TEIDs. This is the table we saw last week. Tunnels and connections are established and we have this diagram that we will see in a lot of the videos. The radio bearer, with the signaling bearer between the UE and the eNodeB, the S1-AP connection, the tunnel for control, only a data tunnel, called a bearer, between the eNodeB and the S-Gateway. Another bearer between SGW and PGW and the tunnel for control. We must also consider the detach procedure: if, for example, I activate flight/airplane mode, or if I power down, the terminal makes a detach request. All the connections and tunnels will be released. And the MME, as well as the terminal, with its SIM card, will keep the security associations and the GUTI in memory. The procedure works like this: here, we have the entire set of bearers that have been established. The terminal sends a detach request, indicating its GUTI and as soon as there’s an acknowledgment on the radio channel, as soon as it is sure that the base station has taken the message into account, it can power down. The radio bearer has now been released, there is no longer a radio connection. But all the resources in the network must be released. So, the eNodeB sends a message to the MME indicating the disconnection. The MME will, for that subscriber, identified by his GUTI, take the subscriber’s data and release the part of the context related to the bearer that had been established, but it will retain the GUTI and the security keys. The MME now notifies the SGW: it asks it to erase everything in its memory, I mean the TEID of the various tunnels. And the SGW also sends a delete session request message to release the S5/S8 bearer. The S-Gateway, when it receives the response from the PGW, when it has released the context, notifies the MME which requests that the eNodeB releases the bearer between the S-Gateway and the eNodeB. So, all the bearers have been released. At the end, the MME notifies the HSS that the subscriber is no longer reachable.
