DMM Working Group Z.W. Yan Internet-Draft CNNIC Intended status: Informational T. Jiang Expires: 5 January 2024 China Mobile J.F. Guan T. Huang BUPT J.-H. Lee Sejong University 4 July 2023 Mobility Capability Negotiation draft-yan-dmm-man-11 Abstract Mobile peers exchange signals with networks, for both IP 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 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. Status of This Memo 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/. Yan, et al. Expires 5 January 2024 [Page 1] Internet-Draft MCN July 2023 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 5 January 2024. Copyright Notice Copyright (c) 2023 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Protocol Categories for Management and Negotiation . . . 3 1.3. General Procedure of Negotiation . . . . . . . . . . . . 5 2. Mobility capability negotiation on IPv6 domain . . . . . . . 6 3. The general 3GPP 5GS-based mobility capability negotiation . 8 3.1. 5GS Wireless-specific Mobility Capability Negotiation . . 8 3.2. 5GS UE IP-address Negotiation & Management . . . . . . . 10 4. Mobility capability negotiation for 5GS-based roaming . . . . 11 4.1. Mobility Capability Negotiation in Home-Routed (HR) Roaming . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mobility Capability Negotiation in Local Break Out (LBO) Roaming . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Yan, et al. Expires 5 January 2024 [Page 2] Internet-Draft MCN July 2023 1. Introduction 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 mobile IP domain, they would mostly focus on the negotiation of IP-related address allocation, provisioning, traffic switching and redirection, as well as optimization. While for devices in the wireless domain, e.g., 5G system (5GS), apart from the mentioned mobile IP-related capabilities, there are other wireless-specific categories required 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]. 1.1. Terminologies * Home network in wireless: the home public land mobile network (H-PLMN) in which a mobile subscriber's profile is held. Mobile subscribers roaming to other networks (or the so-named visited network) will receive subscription information from the home network. * Visited network in wireless: the visited public land mobile network (V-PLMN) in which the mobile subscriber has roamed when leaving its home public land mobile network. 1.2. Protocol Categories for Management and Negotiation 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 Yan, et al. Expires 5 January 2024 [Page 3] Internet-Draft MCN July 2023 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. Simultaneously, they might be applied in 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 can be implementation-dependent because both the home, the visited network entities, 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: * What principles should be followed for the protocol negotiation and selection? * What procedure should be adopted for the protocol negotiation and selection? 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: * Host-initiated protocols: defining the mobility management protocols that require the involvement of mobile end devices in order to accomplish the mobility management. * Network-based protocols: indicating the mobility management protocols that require the non-involvement of mobile end devices in order to accomplish the mobility management. Yan, et al. Expires 5 January 2024 [Page 4] Internet-Draft MCN July 2023 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 and the 3GPP 5G system. 1.3. General Procedure of Negotiation 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: (a) Upon the initialization of mobile devices, the network-based protocol shall be used as the default mobility management protocol once the network supports it, depending on local policy configuration. (b) If a mobile node or UE prefers the host-initiated protocol and the local policy also grants it, then the protocol negotiation will be conducted to switch from the network-based to the host- initiated protocol. (c) After the initial attachment (or registration in 5GS term) of a host, a mobile profile could be generated in the UE's management repository to store the selected protocol. (d) If the UE migration or roaming happens, the network will check the currently-selected or the UE preferred protocol during the re-registration process. The network also needs to notify the host if the selected protocol cannot be supported herein. Yan, et al. Expires 5 January 2024 [Page 5] Internet-Draft MCN July 2023 Evidently, when a mobile host accesses the network, an authentication should be executed before the mobility management service would be provided. In order to support the mobility management protocol selection, a new setting might be recorded by the network after the successful authentication. The newly introduced information shows the selected mobility management protocol and should be updated when the adopted protocol changes. 2. Mobility capability negotiation on IPv6 domain 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: (a) Mobile IPv6 (MIPv6) protocol: the mobility management scheme based on [RFC6275] (b) 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. * The protocols for function extension are proposed to support some specific scenarios or functions, such as the Dual-stack Mobile IPv6 (DSMIPv6) [RFC5555] for mobility of the dual- stack nodes, the Multiple Care-of-Address (MCoA) [RFC5648] for hosts with multiple access interfaces, as well as the Network Mobility (NEMO) [RFC3963] for mobility of sub- network. * The protocol type for performance enhancement of mobility management, such as the Fast Mobile IPv6 (FMIP6) [RFC5568] for fast handover, the Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] for hierarchical mobility optimization. (c) Proxy Mobile IPv6 (PMIPv6) protocol: the mobility management scheme based on [RFC5213]. (d) PMIPv6 suit protocols: in order to reduce the protocol cost and further enhance the handover performance, this suit of proxy- based mobility management protocols is proposed. Based on Yan, et al. Expires 5 January 2024 [Page 6] Internet-Draft MCN July 2023 PMIPv6, the suit is comprised of a series of standardized extensions, such as the Dual-stack Proxy Mobile IPv6 (DS-PMIPv6) [RFC5844], and the Distributed Mobility Management Proxy Mobile IPv6 (DMM-PMIPv6) [RFC7333]. Different from the MIPv6 suit protocols, the location update of the PMIPv6 suit protocols is triggered by the network entity and the transport tunnel is established between the anchor point and the UE's current visited network entity. The mobile host itself needs to do nothing about the signaling exchange during the mobility (or roaming). Particularly, the mobility is transparent to the IP layer of the host. Based on definitions from the Section 1.2, the above four types can be bucketed into either host-initiated or network-based protocols: * Host-initiated protocols: Including the MIPv6 and MIPv6 suit protocols, along with some other solutions, e.g., the Host Identity Protocol (HIP) [RFC7401] and the IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555]. * Network-based protocols: Including the PMIPv6 and PMIPv6 suit protocols, along with some other solutions, e.g., the GPRS Tunneling Protocol (GTP) [TS.29274][TS.29281]. 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 ||| ||+------------+|| ||+------------+|| |+--------------+| |+--------------+| +----------------+ +----------------+ Figure 1: Scopes of different protocol types 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]. Yan, et al. Expires 5 January 2024 [Page 7] Internet-Draft MCN July 2023 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. 3. The general 3GPP 5GS-based mobility capability negotiation 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. 3.1. 5GS Wireless-specific Mobility Capability Negotiation 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: Yan, et al. Expires 5 January 2024 [Page 8] Internet-Draft MCN July 2023 +------+ +-----+ +------+ +-----+ +-----+ +------+ +---------+ | 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+ Figure 2: 5GS Wireless-specific Mobility Capability Negotiation 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 Yan, et al. Expires 5 January 2024 [Page 9] Internet-Draft MCN July 2023 on the system settings. This wireless-specific negotiation procedure is clearly an integration of the host-initiated and the network-based modes. 3.2. 5GS UE IP-address Negotiation & Management 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: (a) To be allocated by the SMF (of a PDU session), e.g., retrieved from the address pool corresponding to the PSA UPF for the said PDU session; (b) To be allocated via DHCPv4/DHCPv6 with the SMF itself being the DHCP server; (c) To be allocated via DHCPv4/DHCPv6 with external DHCP servers. In this case, the SMF will serve as the DHCP relay agent toward the DHCP server located in an external network. 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 Yan, et al. Expires 5 January 2024 [Page 10] Internet-Draft MCN July 2023 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. 4. Mobility capability negotiation for 5GS-based roaming 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). 4.1. Mobility Capability Negotiation in Home-Routed (HR) Roaming 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. Yan, et al. Expires 5 January 2024 [Page 11] Internet-Draft MCN July 2023 +------+ +-----+ +------+ +-----+ | +-----+ +-----+ +-----+ +------+ +-------+ | 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 Figure 3: Mobility Capability Negotiation in Home-Routed (HR) Roaming 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. * Network-based mode: while the UE is in visited network (i.e., the VPLMN as shown in the figure), it has to, via the visited 5GC, connect back to its home 5GC for address and parameters negotiation. When the CP connectivity is established toward the home network, the three different ways for address management as explained in the Section 3.2 can be applied. Please note that the mentioned SMF, UPF, DHCP, etc. are network functions in the home (wireless) network, which can be marked as H-SMF, H-UPF, or H-DHCP mode. Yan, et al. Expires 5 January 2024 [Page 12] Internet-Draft MCN July 2023 * Host-initiated mode: in this case, while an UE is in the visited network, the UE subscriber record must be retrieved from the UDM/ UDR located in the home network (or so marked as H-UDM/H-UDR). 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). 4.2. Mobility Capability Negotiation in Local Break Out (LBO) Roaming 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 Yan, et al. Expires 5 January 2024 [Page 13] Internet-Draft MCN July 2023 Figure 4: Mobility Capability Negotiation in Local Break Out (LBO) Roaming 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. 5. Security Considerations Generally, this function will not incur additional security issues. 6. IANA Considerations A new authentication option or other signaling message option may be used based on the specific implementation. 7. References 7.1. Normative References [MN-AR.IF] Laganier, J., Narayanan, S., and P. McCann, "Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile Node", draft-ietf-netlmm-mn-ar-if-03, February 2008. Yan, et al. Expires 5 January 2024 [Page 14] Internet-Draft MCN July 2023 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, . [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, . [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 2009, . [RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, DOI 10.17487/RFC5568, July 2009, . [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, DOI 10.17487/RFC5648, October 2009, . [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . Yan, et al. Expires 5 January 2024 [Page 15] Internet-Draft MCN July 2023 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [TS.23.288] "3GPP TS 23.288 (V17.3.0): Architecture enhancements for 5G System (5GS) to support network data analytics services", 3GPP TS 23.288, December 2021. [TS.23.501] "3GPP TS 23.501 (V17.0.0): System Architecture for 5G System; Stage 2", 3GPP TS 23.501, March 2021. [TS.24.501] "3GPP TS 24.501: Non-Access-Stratum (NAS) protocol for 5G System (5GS)", 3GPP TS 24.501, September 2022. [TS.29274] "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 8.10.0, June 2011. [TS.29281] "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 2011. [TS.38.300] "3GPP TS 38.300: NR and NG-RAN Overall description", 3GPP TS 38.300, September 2022. 7.2. Informative References [PaperCombiningMobilityStandards] Oliva, A., Soto, I., Calderon, M., Bernardos, C., and M. Sanchez, "The costs and benefits of combining different IP mobility standards", Computer Standards and Interfaces, February 2013. Authors' Addresses Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China Email: yan@cnnic.cn Yan, et al. Expires 5 January 2024 [Page 16] Internet-Draft MCN July 2023 Tianji Jiang China Mobile Email: tianjijiang@chinamobile.com Jianfeng Guan BUPT No.10 Xitucheng Road, Haidian District Beijing 100876 China Email: jfguan@bupt.edu.cn Tao Huang BUPT No.10 Xitucheng Road, Haidian District Beijing 100876 China Email: htao@bupt.edu.cn Jong-Hyouk Lee Sejong University 209, Neungdong-ro, Gwangjin-gu Seoul 05006 Republic of Korea Email: jonghyouk@sejong.ac.kr Yan, et al. Expires 5 January 2024 [Page 17]