# SRv6-Based Edge Service Continuity in 5G Mobile Networks +
## 4 Architecture and Procedures for MEC-Based Mobile Services
### IPv6 Addressing Convention and Reference Scenario  
We now present a possible allocation of IPv6 addresses for the different entities, which we use throughout the paper. The used addressing convention has been inspired by [43].  
The pool C:0::/32 is reserved for services. The client is allocated the pool A:0::/32. The 5 GC network devices are allocated addresses from the B:0::/32 pool, as Table 1 shows. In more detail, the gNB addresses are assigned from B:0::/48, whereas the addresses of the SRv6 nodes are allocated from B:0::0::/48. As suggested by [23], the SID comprises three components: the locator, the function, and the arguments. For a given device, the locator remains consistent across all behaviors and is constructed from the node identifier, e.g., B:0::0::::/48 being the locator, each implemented behavior has an address whose first 48 bits are B:0::0::::  
In Section 4.2 and in Section 5, we will employ four distinct behaviors. Two behaviors are taken from [23], whereas two new behaviors, End.Buffer and End.M.GTP6.D.Buffer, are defined in this work to support the lossless mobility in SRv6-based 5G networks. The End behavior, as defined in [23], is allocated the prefix B:0::0::<nodied>:E:/80 and requires no arguments.  
Regarding the two new behaviors, the End.Buffer, which will be explained in Section 5.2.1, is denoted by B:0:0:<nodeid>:B::/80. The End.M.GTP6.D behavior, defined in [13] and identified by the BSID B:0:0:<nodeid>:G000:<args>::/80, requires arguments to establish the SRv6 policy, i.e., to delineate the list of segments to be encapsulated in the SRH. Finally, the End.M.GTP6.D.Buffer behavior, which will be described in Section 5.2.2, is identified by the BSID B:0:0:<nodeid>:GB00:<args>::/80. It requires arguments to identify the SRv6 policy, i.e., to understand the list of segments to be encapsulated in the SRH before executing the buffering function.  
We conclude this section by illustrating a reference network topology, reported in Figure 4, which is used as a reference in Sections 4.2 and 5 for describing the allocation and migration procedures. A UE can be either a mobile device or an IoT device. A UE is connected to the base station gNB1, which accesses the 5 GC network via SR Endpoint1. The service instance of the UE runs on MEC Host1 and is deployed in the form of containers. MEC Host1 is in turn connected to the 5 GC through SR Endpoint3. The 5 GC control plane, prompted by the MEO, configures the system's routing rules via the AMF and SMF. The SMF communicates with the SDN controller to implement rules in the SRv6 nodes.  
Since the UE has mobility capabilities, a handover, e.g., from gNB1 to gNB2 could occur. Assuming a non-roaming handover, the client retains its original IPv6 address. The MEC architecture provides mechanisms to support service instance migration and information transfer between MEC Hosts [44]. Upon notification from the 5 GC regarding the UE mobility, the MEC system can initiate the migration of the corresponding service from MEC Host1 to MEC Host2. The migration in this case is the procedure that allows a running container to be moved from one host to another [45]. Uplink packets traverse the  
\begin{table}
\begin{tabular}{c c} \hline
**5G Core Locator or Behavior** & **Allocated SID Prefix** \\ \hline Locator & B:0:0:<nodeid>:/64 \\ \hline End behavior & B:0:0:<nodeid>:E::/80 \\ \hline End.Buffer behavior & B:0:0:<nodeid>:B::/80 \\ \hline End.M.GTP6.D BSID & B:0:0:<nodeid>:G000:<args>::/96 \\ \hline End.M.GTP6.D.Buffer BSID & B:0:0:<nodeid>:GB00:<args>::/96 \\ \hline \end{tabular}
\end{table}
Table 1: 5G core devices addressing space.  
Figure 4: Proposed network topology.  
5 GC via SR Endpoint2 and exit through SR Endpoint4. As soon as migration is triggered, a network update to reroute packets toward the new destination is enforced.