What happens when a UE in RRC-inactive state changes cells? Or in other words, how is mobility managed in the RRC-inactive state? This is what we will see in this video. For mobility management, the concept of location area is a widely used concept in mobile networks. In this particular case, we use RNA for RAN-based Notification Area, RAN, meaning Radio Access Network. RNA is a group of cells. When the UE changes RNAs, it will do a resume request, procedure and an update. When the UE stays in the same RNA, even if it changes cells, there is no update. Note that the network may ask the UE to do a periodic update. In the case when a UE is in the RRC-inactive state and there has been no radioactivity, no data exchange for a certain period of time, it does an update. Let's consider a first case of mobility where the UE moves from a cell depending on an RNA to a cell, depending on a different RNA: the UE makes a random access with a preamble, receives an RNTI, and as we have already seen, sends an "RRC Resume Request" message. In this message, there is an I-RNTI to identify the UE and an indication of the fact that this is an update, that the connection is resumed following a change of RNA. The operator then has three possibilities. The first, to keep the UE in RRC-inactive state. The second, put the UE in RRC-idle state. Maybe the terminal has been in the RRC-inactive state for a long time and we can take the opportunity to put it in the RRC-idle state and free up the connections and tunnels. Or why not put the UE in the RRC-connected state? Here, we assume that the operator has chosen to keep the UE in RRC-inactive state. First, the context must be retrieved from the old gNB so that, when necessary, the data flow between the UE and the access network can be established very quickly. But how does the new gNB know the old gNB? For this, we will use a little trick. The I-RNTI has two parts. One is specific to the UE and the other is the gNB identity. Thus, in our scenario, the I-RNTI includes the identity of the old gNB. The message is therefore sent from the new gNB to the old gNB. This message is called retrieve UE contexts request. It contains the I-RNTI of the UE. From this I-RNTI, the old gNB can retrieve the context (the radio characteristics of the UE) and sends this context back to the new gNB. The tunnels and connections to the new gNB have to be re-established. This is what will happen once the context has been retrieved. There is an exchange of "Path Switch" messages and a procedure that will involve the AMF, the UPF and also the SMFs to redirect the tunnels and connections. Once this is done, we need to release the context in the old gNB. The new gNB does this by sending a UE context release message. The radio connection can be released. This is done by sending an RRC release message with an I-RNTI to the terminal. Note that the I-RNTI is a new I-RNTI since it includes the identity of the new gNB. the whole procedure takes place in a question of milliseconds. What happens when a terminal (a UE) changes cell but remains within the same RNA? The question is simple, the answer is even simpler. Nothing happens. By the very definition of the RNA, since there is no radio exchange when a terminal changes cell but remains in the same RNA. The problem arises when a packet is sent by a server to the UE. This packet is encapsulated, put in a tunnel, and it will arrive at the old gNB since from the perspective of the core network, mobility has not been detected. The packet is stored by the old gNB in a buffer and the UE must be reached as soon as possible. The network doesn't know which cell the UE is located in. The old gNB will therefore send a paging request message called "RAN Paging" to all gNBs of the RNA. The gNBs broadcast the paging message. The paging message contains the identity of the UE in the form of I-RNTI since this is all we have to identify a UE in the RRC-inactive state. Wherever the UE is, it receives the paging message and it will make a request to resume the connection. We find the "RRC Resume Request" message with the I-RNTI. This I-RNTI allows the new gNB to recover the context from the old gNB. Once this context is recovered, it's possible to establish the radio connection with a data flow and radio connection whose characteristics are adapted to the context, to the radio characteristics of the UE. Let's not forget that we have our packets waiting in the old gNB. We need to re-route these packets. To do this, we will establish a tunnel between the two gNBs, a little like what we do during an X2-handover, all the packet's waiting in the old gNB can be transferred through this tunnel to the new gNB. We have a set of messages exchanged between the AMF, the UPF, and the SMF to re-route all these tunnels and connections correctly. Once they are properly reestablished, we will be able to release the tunnel between the gNBs and release the context in the old gNB. The final state is an RRC-connected state. All connections and tunnels are established via the new gNB, allowing for direct data flow. In conclusion, for UE in an RRC inactive state, mobility is managed using the concept of RNA (RAN Notification Area), whose principles are similar to a Tracking Area in 4G. No signaling is exchanged when a UE changes cells but remain in the same RNA. If the UE has changed cells while a data packet was being sent from the external network, the packet will be re-routed and then the tunnels and connections will be transferred towards the gNB. When a packet is sent from the UE, tunnels and connections are transferred and data flow is restored. The "RRC Resume" procedure is performed when the terminal changes cells and RNA. All this is really important if we want to minimize the signaling that is actually exchanged, if we want to minimize the consumption of the UEs, if we want to optimize, and thus, minimize latency. Note that the strategies and the parameter values are not necessarily the same for all UEs. Indeed, mobility habits or mobility service usage habits may be very different for each subscriber.
