| Internet-Draft | MCN | February 2024 |
| Yan, et al. | Expires 24 August 2024 | [Page] |
Mobile peers exchange signals with networks, for both wireline and wireless domains, to negotiate capabilities for mobile registration, connection management, session establishment, service provisioning, etc. Generally, mobility capabilities include the supported and provisioned resources along with associated protocols for certain mobility management scenarios. While devices in the mobile wireline (IP) domain would mostly focus on the IP-related negotiation, devices in the wireless domain, e.g., the 5G system (5GS), embrace both mobile IP-related resources as well as wireless-specific capabilities. Regarding both the mobile-IP and wireless domains, we have generalized two protocol categories for mobility capability negotiation & management, i.e., the host-initiated category that involves the direct & active engagement of mobile end devices vs. the network-based category over which mobile endpoints play almost no role in the process. The classification and then the application of the two categories help us analyze the mobility capability negotiation for both the mobile IPv6 and the 3GPP 5G system. The comparison of the capability negotiation under both the Home-Routed (HR) and the Local BreakOut (LBO) roaming cases in 5GS further reflects the feasibility of the protocol dichotomy.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 August 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Mobile communication is the use of various technological systems to communicate while two or more communicating peers do not stay always in the same fixed locations. In order to pass on messages successfully, mobile peers have to go through a procedure that would be mostly comprised of registration, connection management and paging, session establishment and management, service provisioning, dialogue, etc. This process would involve the signalling exchange and capability negotiation among mobile peers.¶
Generally, mobility capabilities include the supported and provisioned resources along with the associated protocols for certain mobility management scenarios. While the scenarios are applicable to both the wireline and wireless domains, there do exist discrepancies between them. For devices in the wireline domain (i.e., mobile IP ), they would mostly focus on the negotiation of IP-related address allocation & provisioning, traffic switching and redirection, as well as resource optimization. While for devices in the wireless domain, e.g., 5G system (5GS), apart from the previously-mentioned mobile IP-related capabilities, there are other wireless-specific settings to be negotiated, e.g., the radio, the MM (Mobile Management) core network (MM CN), and the SM (Session Management) core network (SM CN) capabilities [TS.23.501].¶
There exist different mobility management protocols. These protocols have been standardized for versatile mobile scenarios. A mobile node, i.e., so-called User Entity or UE, has to adopt some protocol(s) to negotiate, for certain scenarios like in the roaming case, via the visited mobile (access) network, with its home network for pre-configured or dynamically-provisioned mobility capabilities. The successful negotiation would help achieve the requirments of service connectivity and communication performance, for potential cases like the IP-domain roaming as well as the UE handover and migration in wireless network.¶
Regardless, for either the IP-mobility or the wireless like 5GS, both the IP-related resource allocation and provisioning, e.g., IP addresses, mobile-IP tunnels, IP prefixes in visited domains, etc., and the wireless related capabilities like the radio, MM CN, and SM CN [TS.23.501], etc., depend on the selection and application of the mobility management protocols. These protocols could be deployed in the fields of both the home and the visited networks, including both the (access) networks and the UE entities themselves. However, the objectives of achieving this type of homogenous mobility and the ubiquitous connections might be impaired by the diversified capabilities and requirements of the networks and/or the host entities. Accordingly, a scheme and a procedure shall be in place to support the negotiation and selection of the mobility management protocol which a mobile host, i.e., either IP or wireless one, could adopt to access the network.¶
While the scheme aims to guarantee the optimal and the most suitable mobility management protocol will be selected, the procedure is for the effective application of the protocol. Though the selection procedure and notification scheme might be implementation-dependent because the home & visited networks, and UE entities have certainly different capabilities and preferences (e.g., subject to the settings of the mobility pattern of a 5G host [TS.23.501]), there are two general aspects to be considered:¶
In this draft, the descriptions so far lead to two different protocol categories for mobility management, i.e., the host-initiated and the network-based protocols. They are defined as follows:¶
In order to inherit the features of the corresponding mobility management protocols, the capability negotiation modes are also mapped into these two categories. That is, the host-initiated protocol accommodates the host-initiated negotiation while the network-based protocol embraces the network-based negotiation.¶
Obviously, the difference between the two categories lies on the role of mobile end devices in the mobility management process. We will explain in the next two sections how this dichotomy would be applied to the negotiation in both the mobile IPv6 domain (i.e., wireline) and the 3GPP 5G system (i.e., wireless).¶
The protocol negotiation could be included in the MN_ATTACH Function [MN-AR.IF] and the implementation may be based on new or extended signalling messages (e.g., ICMPv6, Diameter, and RADIUS). Besides these, other protocols could also be used in certain specified scenarios, such as for extended IEEE 802.21 primitives, UE providing the supported protocol list to Access and Mobility Management Function (AMF) in 5GS registration and/or update procedures, etc. In summary, the general procedure for protocol negotiation and selection might be:¶
Evidently, when a mobile host accesses the network, authentication shall be executed before any mobility management service would be honored. In order to support the mobility management protocol selection, new data, e.g., authentication vector or AV for 4G/5G, would be recorded by the network after the successful authentication. The newly introduced information shows the selected mobility management protocol and shall be updated when the adopted protocol changes.¶
Based on the host-initiated and network-based categories, this section analyzes the mobility capability negotiation on the mobile IPv6 domain.¶
Fundamentally, there are four types of mobile IPv6-based mobility management protocols:¶
MIPv6 suit protocols: Based on the MIPv6 protocol, there are multiple extension protocols that have been standardized. These protocols can be classified into two types: protocols for function extension and protocols for performance enhancement. In the context of MIPv6 suit protocols, any location update will be initiated by a mobile host and a redirection tunnel is established between the UE’s home network and the UE in the visited network.¶
Based on definitions from the Section 1.2, the above four types can be bucketed into either host-initiated or network-based protocols:¶
Figure 1 illustrates the scopes of the above different categories as well as their belongings to either Host- or Network- types:¶
+----------------+ +----------------+
| Network-based | | Host-based |
|+--------------+| |+--------------+|
||PMIPv6 suit || ||MIPv6 suit ||
||+------------+|| ||+------------+||
|||PMIPv6 ||| |||MIPv6 |||
||+------------+|| ||+------------+||
|+--------------+| |+--------------+|
+----------------+ +----------------+
In reality, the host-initiated protocols and the network-based protocols can certainly co-exist in fields, which might lead to the configurations of multiple protocol daemons on the mattered network entities and mobile hosts. This bodes well for the need of schemes to support the negotiation and selection of the suitable mobility management protocol when a mobile host registers with an access network initially or triggers the handover & roaming later [PaperCombiningMobilityStandards].¶
In the procedure described in the Section 1.3, the network-based protocol is listed as the default selection. However, in the mobile IPv6 domain, we believe the protocols bearing function extensions shall be given higher priority than those targeting for the performance enhancement.¶
As we have discussed in the Section 1.2, for 5G wireless devices, apart from the normal mobile IP-related capabilities like addressing, provisioning, traffic switching and redirection, there are other wireless-specific categories to be negotiated, e.g., the radio, the MM core network (MM CN), and the SM core network (SM CN) capabilities [TS.23.501]. Further, the Section 1.2 elucidates that the host-initiated protocol requires the involvement of mobile devices themselves, and the network-based one puts the negotiation burden on network entities. While the mobile IP-domain has been conforming near perfectly to this dichotomy, the 5G wireless system oversees the seamless integration of both types of protocols upon the IP-related and the wireless-specific capabilities. That is, the 5GS mobility capability negotiation is subject to the control and management of both types of protocols. Here, it must be clarified that, different from the common recognition in the IP domain, the term 'network' in 5GS indicates both the wireless access network (i.e., RAN) and the 5G core system.¶
According to 3GPP TS 23.501 [TS.23.501], the 5GS mobility capabilities are comprised of the UE radio, the UE 5GMM core network (5GMM CN), and the UE 5GSM core network (SM CN) capabilities. The negotiation handling is between the mobile device (i.e., UE) and many 5G network functions (NFs), e.g., AMF, SMF, UDM, etc., as shown in the Figure 2:¶
+------+ +-----+ +------+ +-----+ +-----+ +------+ +---------+
| NSSF | | NEF | | NRF | | PCF | | UDM | | AF | | EASDF |
+------+ +-----+ +-----+| +-----+ +-----+ +------+ +---------+
| | | | | | |
Nnssf | Nnef | Nnrf | Npcf | Nudm | Naf | Neasdf |
| | | | | | |
----+----+---+----+---+------+-----+----+---+-----+--+-------+---+-----
| | | | | |
| | | | | |
Nnssaaf | Nausf | Namf | Nsmf | | Nnsact |
+--------+ +-----+ +-------+ +-----+ +-----+ +---------+
| NSSAAF | | AUSF| | AMF | | SMF | | SCP | | NSACF |
+--------+ +-----+ +-------+ +-----+ +-----+ +---------+ / | |
N1 N2 N4
/ | |
/ | |
+------+ +-------+ N3 +-----+ N6 +--------+
| UE |--| (R)AN |----| UPF |-----------| DN |
+------+ +-------+ +-----+ +--------+
| |
+-N9+
The UE Radio Capability information is defined in TS 38.300 [TS.38.300] , which contains a great deal of information on the Radio Access Types or RATs that the UE supports, e.g. power class, frequency bands, etc. During the negotiation phase, this radio information can be sent by a UE and the AMF shall store the capabilities to avoid unnecessary radio overhead. The UE 5GMM CN Capability is related to 5G core network and defined in TS 24.501 [TS.24.501]. It contains mainly non-radio related UE capabilities, e.g. the network-slice information, the NAS security algorithms, etc., which are transferred only upon the AMF to AMF changes. During the initial negotiation as well as the mobility update (i.e., regarding the registration procedure), the UE shall send its 5GMM CN capability information to the AMF and the AMF shall store it. The UE 5GSM CN capability is related to 5G PDU session establishment and management, requiring the involvement from the critical function SMF. It contains the supporting indications of reflective QoS, multi-home IPv6, ATSSS, etc.¶
As it can be seen, the UE radio, the UE 5GMM CN and the 5GSM CN capability handlings involve both the UE itself and the 5G system. An UE initiates the process by providing its capabilities to the network (i.e., the 5GS) and the network (via 5G NFs) negotiates based on the system settings. This wireless-specific negotiation procedure is clearly an integration of the host-initiated and the network-based modes.¶
As one of the UE mobility capabilities, the 5G UE IP address management is very flexible [TS.23.501]. It includes the allocation, release and the renewal of the IP addresses. Based on the DNN configuration, UE subscription data and/or 5GS operator policies, along with the PDU session type as selected by the 5G function SMF, a UE could be allocated either IPv4 address or IPv6 prefix or both IPv4 and IPv6 prefix/addresses. While the allocation mode as determined by the UE subscription data bears the static nature of host-initiated, the operator policies, DNN-configuration and the selected PDU session type bode well for the dynamic network-based negotiation. Here, we want to emphasize again that the network in 5GS indicates both the wireless access network (i.e., RAN) and the 5G core system.¶
For the network-based dynamic mode, based on a UE indication, the UE IPv4 address (and the IPv6 prefix) along with their (IPv4 and IPv6) parameters could be negotiated via three different ways:¶
For the static host-initiated mode, a static IPv4 address and/or an IPv6 prefix could be negotiated and allocated by 5GC based on a UE subscription record stored in the UDM/UDR, or based on the per-DNN per-S-NSSAI record of a UE stored in the DHCP/DN-AAA server that is located either in the 5G core network or in the external domain.¶
Actually, both negotiation modes may co-exist in the 5GS. For example, the UDM/UDR can have a UE subscription record to fulfill the host-initiated allocation, and simultaneously a SMF might provide the network-based IP address management via DHCP/DN-AAA servers. So, we might ask which negotiation mode will prevail in an operator network. While the existence of multiple modes is not uncommon in field, unfortunately, there is no definite prioritization specified in 5G standards to address the potential confliction. In practice, the final determination is based on the locally configured policies in operator networks. Of course, the (core) network settings might be more authentic than an individual UE subscription record, but it never excludes from giving the preference to the UE.¶
The Section 3 describes the general 5GS mobility capability negotiation procedure when a UE is located in and registered with its home mobile network. However, when a UE roams to another network, or the so-called visited network, the UE still needs to negotiate its mobility capabilities. The 5GS has defined two roaming architectures, i.e., Home-routed (HR) vs. Local Break Out (LBO).¶
According to 5G TS 23.501, in Home-Routed (HR) roaming, when a UE resides in the visited network, the visiting network data traffic is routed to the destination data network (DN) via the subscriber home network. While HR provides more control to the operators upon offering roaming services, policies and charging the subscribers, however, it adds extra layer of complexity and lag in the network because of the extra traffic redirection. The following Figure 3 shows the HR-based roaming architecture.¶
+------+ +-----+ +------+ +-----+ | +-----+ +-----+ +-----+ +------+ +-------+
| NSSF | | NEF | | NRF | | PCF | | | UDM | | NRF | | NEF | | NSSF | | NSACF |
+------+ +-----+ +-----+| +-----+ | +-----+ +-----+ +-----+ +------+ +-------+
| | | | | | | | | |
Nnssf | Nnef | Nnrf | Npcf | | Nudm | Nnrf| Nnef| Nnssf| Nnsacf|
| | | | +-------+ | +-------+ | | | | |
----+----+---+----+---+--------+--+ vSEPP |-N32--| hSEPP |------++-------+-+------+----+---+-----+----+--+--
| | | +-------+ | +------ + | | | | |
| | | | | | | | |
Nnssaaf | Nausf | Nsmf| | Nsmf | Nausf| Nnsaaf| Npcf| Naf|
+-------+ +-----+ +-----+ | +-----+ +------+ +--------+ +-----+ +----+
| NSACF | | AMF | | SMF | | | SMF | | AUSF | | NSSAAF | | PCF | | AF |
+-------+ +-----+ +-----+ | +-----+ +------+ +--------+ +-----+ +----+
/ | | | |
N1 N2 N4 | N4
/ | | | |
/ | | | |
+------+ +-------+ +-------+ | +--------+ +--------+
| UE |--| (R)AN |-N3-| UPF |--------N9-------------| UPF |--------N6 --------| DN |
+------+ +-------+ +-------+ | +--------+ +--------+
| | | | |
+--N9-+ | +-N9-+
VPLMN | HPLMN
The UE is in the visited network (left). There exists an N9 GTP-tunnel between the V-UPF and the H-UPF for traffic redirection.¶
In the HR-roaming mode, the UE IP address negotiation and allocation are similar to the general 5GS scenario as in the Section 3.2. When a mobile subscriber roams to the visited network, there are also two address management modes, i.e., the host-initiated static mode vs. the network-based dynamic mode.¶
Regardless of being host-initiated or network-based, the IP address negotiation and allocation are determined by the home-network side. A roamed UE has always to talk to its home network functions for mobility capability negotiation. In the HR-roaming, the home UPF or H-UPF behaves like a Home Agent or HA in the mobile IP domain. For example, as shown in the Figure 3, any data traffic destined to the UE must be transported from the home DN, going thru the H-UPF (N6), then tunneled to the visited UPF or V-UPF (N9), then thru the GTP-Tunnel (N3) to the visited (R)AN, and finally delivered to the UE (located in the visited network).¶
Different from the HR-based roaming, in LBO roaming architecture, the data session of a roaming subscriber is anchored in the visited network, without the need of redirecting toward the subscriber home network. The following Figure 4 shows the LBO-based roaming architecture. It shows clearly the N9 GTP-tunnel in the HR-based roaming does not exist anymore.¶
+------+ +-----+ +------+ +-----+ +----+ | +-----+ +-----+ +--------+
| NSSF | | NEF | | NRF | | PCF | | AF | | | UDM | | NRF | | NSSAAF |
+------+ +-----+ +-----+| +-----+ +----+ | +-----+ +-----+ +--------+
| | | | | | | | |
Nnssf | Nnef | Nnrf | Npcf | Naf| | Nudm| Nnrf| | Nnssaaf
| | | | | +-------+ N32 +-------+ | | |
----+----+---+----+---+---------++-------+-| vSEPP |------| hSEPP |----+-+------+-+------++-----+--
| | | +-------+ +------ + | | | |
| | | | | | | |
Namf | Nsmf | Nnsacf| | Nausf| Npcf| Nnef| |Nnsacf
+-------+ +-------+ +-------+ | +-----+ +-----+ +-----+ +-----+
| AMF | | SMF | | NSACF | | | AUSF| | PCF | | NEF | |NSACF|
+-------+ +-------+ +-------+ | +-----+ +-----+ +-----+ +-----+
/ | | |
N1 N2 N4 |
/ | | |
/ | | |
+------+ +-------+ +-------+ +----+ |
| UE |--| (R)AN |-N3-| UPF |---N6---| DN | |
+------+ +-------+ +-------+ +----+ |
| | |
+-N9-+ |
VPLMN | HPLMN
Also, similar to the general 5GS scenario as in the Section 3.2, in LBO roaming, the UE IP address negotiation and allocation are dynamically managed by the SMF, UPF, and/or DHCP mode in the visited network (marked as V-SMF, V-UPF and V-DHCP). This is different from the HR-roaming because the decision of HR-roaming belongs to the home network side.¶
Another discrepancy of the LBO- from the HR- roaming is that the visited PCF or V-PCF cannot access a UE subscriber record information from the UE home network. That is, there is no retrieval of the host-based IP address settings from the home UDM/UDR or H-UDM/H-UDR. This excludes fundamentally the host-initiated scheme for IP capability negotiation (from the home network), and only leaves the network-based scheme (as provided by the visited network) with the consideration of the rules generated by V-PCF based on locally-configured policies according to the roaming agreement between the visited and the home networks.¶
In the LBO-roaming, there is no need for a roamed UE to talk to its home network functions for IP capability negotiation. Thus, the visited UPF or V-UPF behaves like a Mobile Access Gateway or MAG in the mobile IP domain. For example, as shown in the Figure 4, the data traffic destined to the (roamed) UE will only transport through the visited DN, going toward the V-UPF (N6), then tunneled thru the GTP (N3) to the visited (R)AN, and finally delivered to the UE (located in the visited network). This shows clearly no involvement of the traffic redirection (via any HA or Home Agent) as in the HR-roaming case.¶
Generally, this function will not incur additional security issues.¶
A new authentication option or other signaling message option may be used based on the specific implementation.¶