Method and apparatus for communicating traffic offload policies to VPLMN for home routing session grooming

Abstract

Methods and apparatus are provided for transmitting policy information between a first network and a home network of a user equipment (UE) accessing an edge hosted environment (EHE) in the first network. A method implemented in a first session management function (SMF) in the first network (VPLMN) includes sending a request for packet data unit (PDU) session setup for the UE to a second SMF in the home network indicating that the first SMF requests authorization for home routing session grooming (HR-SBO) for the PDU session, and receiving, from the second SMF, a response message including one or more offload identifiers (IDs), each of the one or more offload IDs identifying one or more offload policies for edge computing (EC) services to be applied at the first network. The transmission offload policy itself is not always required, but only the ID is used.

Description

[0001] Related Applications

[0002] This application claims the benefit of Provisional Patent Application Serial No. 63 / 434,536, filed Dec. 22, 2022, the entire disclosure of which is hereby incorporated herein by reference. Technical Field

[0003] This disclosure relates to a wireless communication system, and more particularly, to a wireless communication system that supports policies in roaming for home routing and local breakout. Background Art

[0004] In Figure 2 a 5G wireless network, there can be various network functions, including but not limited to:

[0005] ● SMF (Session Management Function), which is responsible for session establishment, modification, and release, including the selection and control of UPF entities, maintaining the topology of the PSA UPFs involved, establishing and releasing tunnels between the AN and the UPF and between UPFs. It also configures traffic forwarding at the UPF. The SMF interacts with the UPF via the PFCP procedure through the N4 reference point.

[0006] ● UPF (User Plane Function), which processes user data traffic. In addition to this, it also provides an external PDU session point (PDU session anchor, PSA) for interconnection with the data network and implements packet routing & forwarding (e.g., supporting an uplink classifier (ULCL) to route traffic flows to instances of the data network, supporting a branch point to support multi-homed PDU sessions).

[0007] ● PCF (Policy Control Function), which supports a unified policy framework to manage network behavior. Specifically, for the present invention, the PCF provides PCC (Policy and Charging Control) rules to the PCEF (Policy and Charging Enforcement Function), i.e., the SMF / UPF that makes policy and charging decisions according to the provided PCC rules.

[0008] ● NEF (Network Exposure Function), which supports different functions, and specifically, in the context of this IvD, the NEF acts as an entry point to the operator's network, so that an external AF (content provider) interacts with the 3GPP core network through the NEF.

[0009] ●AF (Application Function): It can send requests to influence the SMF routing decision for the services of a PDU session. The AF request can influence the UPF (re)selection and allow routing the user services to the local access of the data network (identified by DNAI). The AF can communicate directly with the PCF in the SBA domain or indirectly through the NEF, i.e., it has an API to the NEF that conveys the AF communication to the PCF.

[0010] ●UDM (Unified Data Management): It is the front end of the user subscription data stored in the UDR. The UDM uses the subscription data that can be stored in the UDR to execute application logic such as access authorization, registration management, and reachability for termination events (e.g., SMS).

[0011] As described in section 5.13 of TS23.501 v.17.4.0, edge computing enables operators and third-party services to be hosted near the UE's attachment access point to achieve efficient service delivery with reduced end-to-end latency and load on the transport network. The 5G core network selects a UPF close to the UE and performs service steering from the UPF to the local data network via the N6 interface.

[0012] Many enablers that support edge computing either individually or in combination have been defined (in section 5.13 of TS23.501 v.17.4.0). The enablers include:

[0013] ● User plane (re)selection: The 5G core network (re)selects a UPF to route the user services to the local data network, as described in section 6.3.3 of TS23.501 v.17.4.0;

[0014] ● Local routing and service steering: The 5G core network selects the services to be routed to the applications in the local data network;

[0015] ○ This includes using a single PDU session with multiple PDU session anchors (UL CL / IP v6 multi-homing), as described in section 5.6.4 of TS23.501 v.17.4.0.

[0016] ● Session and service continuity for enabling UE and application mobility, as described in section 5.6.9 of TS23.501 v.17.4.0,

[0017] ● The Application Function (AF) can influence the UPF (re)selection and service routing via the PCF or NEF

[0018] Edge Computing (EC) enables operators and third-party services to be hosted near the UE's attachment access point to achieve efficient service delivery with reduced end-to-end latency and load on the transport network.

[0019] Figure 3A depicts the 5GS architecture for supporting non-roaming scenarios for edge computing with UL CL / BP Figure 3B depicts the 5GS architecture for supporting non-roaming scenarios for edge computing without UL CL / BB.

[0020] To support the Edge Application Server (EAS) discovery process, the Edge Application Server Discovery Function (EASDF) has been introduced in TS23.548, which implements (among other things) the processing of DNS messages according to instructions from the SMF, including:

[0021] - Receiving DNS message handling rules from the SMF

[0022] - Exchanging DNS messages from the UE

[0023] - Forwarding DNS messages to the Central DNS (C-DNS) or Local DNS (L-DNS) for DNS queries

[0024] - Adding the Extended DNS (EDNS) Client Subnet (ECS) option (as defined in RFC 7871) to DNS queries for FQDNs

[0025] - Notifying the SMF of EASDF-related information

[0026] - Terminating DNS security if TLS-based DNS (DoT), HTTPS-based DNS (DoH), or DTLS-based DNS is used.

[0027] The EASDF has a user plane connection with the PSA UPF via N6 for transporting DNS signaling exchanged with the UE. If a UE application wants to discover / access an EAS by using the mechanism defined in TS23.548, the DNS query generated by the UE should be sent to the EASDF as the DNS resolver indicated by the SMF.

[0028] There are certain challenges currently. More specifically, neither the Release 16 functions for Edge Computing (EC) defined in 3GPP TS23.501 nor the Release 17 enhancements defined in 3GPP TS23.548 v17.4.0 provide the function of accessing the Edge Hosting Environment (EHE) in the visited Public Land Mobile Network (VPLMN) during roaming. Therefore, this has been defined as a key issue to be addressed in the Release 18 study (Key Issue #1 in 3GPP TS23.700-48 v2.0.0). There are two alternative scenarios to consider, namely the UE accessing the EHE in the VPLMN via a Locally Broken-out (LBO) PDU session and the UE accessing the EHE in the VPLMN via a PDU session established as Home Routing (HR).

[0029] Figure 4 The UE roaming scenario of accessing the EHE in the HR PDU session, called the Home Routing Session Break-out (HR-SBO) scenario, is depicted in Figure 4 Fig. shows the 5G network architecture for home routing session break-out in the visited PLMN. The architecture includes a home PLMN and a visited PLMN. The NFs in the home PLMN are sometimes denoted with an "H-" prefix in this document, while the NFs in the visited PLMN are sometimes denoted with a "V-" prefix in this document. In this architecture, the visited PLMN includes a Network Exposure Function (NEF) 300, a Network Repository Function (NRF) 302, a Visited Policy Control Function (V-PCF) 324, an Access and Mobility Management Function (AMF) 322 (denoted as AMF in the visited network, similar to Figure 2 the AMF 200 in

[0030] Figure 5 the AMF 322 is connected to the Data Network (DN), which includes an Edge Application Server (EAS) 314 in this example. The home PLMN includes a Home Edge Application Server Discovery Function (H-EASDF) 318, a Home Policy Control Function (H-PCF) 312, a Unified Data Management (UDM) 308, a Home Session Management Function (H-SMF) 310, a Home Domain Name Server (H-DNS) 320, and a Home User Plane Function (H-UPF) 306 connected to a central DN 316.

[0031] The following further describes the steps that have been approved into the standard TS23.548 Figure 5 as follows:

[0032] Step 1: During the registration process, the AMF receives, from the UDM, the HR-SBO permission indication for each DNN / S-NSSAI in step 14b of the procedure in section 4.2.2.2.2 of TS23.502 V.17.4.0.

[0033] Step 2: During the PDU session establishment procedure for home routed roaming as in section 4.3.2.2.2 of TS23.502 V.17.4.0, if the AMF 322 received the HR-SBO permission indication for the requested DNN / S-NSSAI in step 1, the AMF 322 selects a V-SMF 328 that supports HR-SBO.

[0034] Editor's Note: It remains to be further studied (FFS) whether the AMF 322 sends an indication that the requested session is allowed for the HR-SBO PDU session to the V-SMF 328. If agreed, this indication can be used by the V-SMF 328 to decide whether to request an HR-SBO PDU session from the H-SMF 310.

[0035] Editor's Note: It remains to be further studied (FFS) when the V-SMF 328 selects the V-EASDF 316. In other words, the V-SMF 328 selects the V-EASDF 316 in the following cases: 1) before sending the Nsmf_PDUSession_Create request for the HR-SBO PDU session to the H-SMF 310, or 2) after receiving the Nsmf_PDUSession_Create response from the H-SMF 310.

[0036] The V-SMF 328 sends a request to establish an HR-SBO supported PDU session in the VPLMN and the V-EASDF 316 address to the H-SMF 310. The H-SMF 310 authorizes the request based on the SM subscription data and provides the V-SMF 328 with an optional VPLMN specific offloading policy (if available in the HPLMN based on the SLA between the HPLMN and the VPLMN) and the DNS server address of the HPLMN.

[0037] Editor's Note: The SM subscription data includes 1) the HR-SBO authorization indication or 2) the HR-SBO authorization information (including the VPLMN-specific offloading policy), which is FFS. If only the HR-SBO authorization indication is added, the H-SMF 310 retrieves the VPLMN-specific offloading policy from the H-PCF 312 (if available at the H-PCF 312) based on the SLA between the HPLMN and the VPLMN.

[0038] Editor's Note: The details of the VPLMN-specific offloading policy (e.g., FQDN range, IP range, AMBR for the local part of the DN, or charging policy) are FFS.

[0039] Note 2: The VPLMN-specific offloading policy can be pre-configured in the HPLMN based on the service level agreement between the VPLMN and the HPLMN.

[0040] The H-SMF 310 also constructs a Protocol Configuration Option (PCO) in which the DNS server address field is set to the V-EASDF address and sends the PCO to the V-SMF 328.

[0041] Step 3: The V-SMF 328 configures the DNS handling rules for the V-EASDF 316 using the optional VPLMN-specific offloading policy and the DNS server address of the HPLMN (if received from the H-SMF 310 in Step 2).

[0042] Editor's Note: How to implement the EAS (re)discovery process for the HR-SBO roaming scenario is subject to further study (FFS).

[0043] As will be described below, the embodiments address the editor's notes that describe issues subject to further study.

[0044] To understand the solution proposed herein, it is crucial to understand how the current technology addresses the subscription data in the UDM 308.

[0045] TS 23.502 V.17.4.0 lists the UE subscription data attributes as reproduced in Table 1 below:

[0046]

[0047]

[0048]

[0049]

[0050]

[0051]

[0052]

[0053]

[0054]

[0055] Table 1: UE Subscription Data Types (see Table 5.2.3.3.1-1 in TS23.502 V.17.4.0)

[0056] At least a mandatory key is required for each subscription data type to identify the corresponding data. Depending on the use case, for some subscription data types, one or more sub-keys may be used to further identify the corresponding data, as defined in TS23.502 V.17.4.0. For session management subscription data, the SUPI is the mandatory key, and the network slice (S-NSSAI), data network name (DNN), serving PLMN ID, and optional network identifier (NID) are defined as sub-keys. Summary of the Invention

[0057] Certain aspects and embodiments of the present disclosure can provide solutions to the above or other challenges.

[0058] The present disclosure proposes a solution for delivering offloading information (policies) to a VPLMN in an HR-SBO scenario, where the offloading policy is pre-configured and indexed in an H-SMF such that it is possible to derive a VPLMN-specific offloading policy based on an offloading ID received from the UDM that points to the corresponding configuration in the H-SMF.

[0059] The H-SMF applies the offloading ID as a label to the offloading policy sent to the V-SMF, based on which it is possible to re-send specific offloading information to the V-SMF only when needed, e.g., if the information has changed.

[0060] According to some embodiments, a method of implementing a first session management function SMF (e.g., a visited SMF in a visited PLMN) that transmits policy information between a first network (visited PLMN) and a home network (home PLMN) of a user equipment (UE) that accesses an edge hosting environment (EHE) in the first network (e.g., visited PLMN) is provided. The method includes: a first SMF (visited SMF) sending a request for a packet data unit (PDU) session establishment for the UE to a second SMF (home SMF) in the home network, which indicates that the first SMF requests authorization for home routed session breakout (HR-SBO) for the PDU session, and the first SMF (visited SMF) receiving from the second SMF (home SMF) a message indicating a response, the response including one or more offload identifiers (IDs), each of the one or more offload IDs identifying one or more first network specific offload policies for edge computing (EC) services to be applied on the first network.

[0061] For example, the message indicating the response further includes: at least one of the one or more first network specific offload policies identified by at least one of the one or more offload IDs.

[0062] For example, the request for PDU session establishment includes one or more previously provided offload IDs that identify one or more previously provided first network specific offload policies at the first network from the home network. This may include indicating to the home network which offload policies are available at the first network. The one or more previously provided offload IDs may be marked with a timestamp indicating when the one or more previously provided first network specific offload policies were provided at the first network. For example, if the offload policy associated with a previously provided offload ID included in the request for the PDU session is updated, the message indicating the response further includes the one or more previously provided offload IDs and the corresponding updated first network specific offload policy. If an updated policy or a new offload policy is received, the first SMF replaces the one or more previously provided first network specific offload policies with the updated first network specific offload policies corresponding to the one or more previously provided offload IDs. The first SMF also stores any newly received policies and their corresponding offload identifiers.

[0063] According to some examples, one or more of the offload IDs in the message correspond to one or more subscription offload IDs obtained from subscription data for the UE, and / or one or more generated offload IDs generated based on one or more previously provided offload IDs and one or more subscription offload IDs included in the request for PDU session establishment.

[0064] In one example, the first network-specific offloading policy or the updated first network-specific policy includes: a range of one or more fully qualified domain names (FQDNs) and / or Internet Protocol (IP) addresses for allowed edge computing services and / or non-allowed edge computing services.

[0065] According to some examples, the provided method further includes the step of: configuring a user plane function in a first network (visited PLMN) having an uplink classifier branch point (UL CL / BP) with the first network-specific offloading policy and / or the updated offloading policy.

[0066] Similarly, a method for transmitting policy information between a first network (visited PLMN) and a home network of a user equipment (UE) accessing an edge hosting environment (EHE) in the first network is provided, wherein the method is implemented in a second session management function (SMF) (H-SMF) in the home network. The method includes: receiving, by the second SMF (H-SMF), from a first SMF (V SMF) in a first network (VPLMN), a request for PDU session establishment, which indicates that the first SMF requests authorization for home routed session breakout (HR-SBO) of the PDU session, and obtaining, from a third network function, first network-specific service offloading information, which includes one or more offloading identifiers (IDs) subscribed to for policies for one or more edge computing (EC) services allowed for HR-SBO, and / or one or more offloading IDs subscribed to for policies for one or more edge computing (EC) services not allowed for HR-SBO, and finally sending, to the first SMF in the first network (visited PLMN), a message indicating a response including one or more offloading IDs, wherein the one or more offloading IDs are based on the one or more subscribed offloading IDs to be applied by the first network.

[0067] In one example, the policy (the same as the previously mentioned first network-specific offloading policy) corresponds to at least one of a list of destination IP ranges and fully qualified domain names (FQDNs). The one or more offloading IDs may directly correspond to the one or more subscribed offloading IDs, or may be generated based on an identifier of the first network and the one or more subscribed offloading identifiers.

[0068] In one example, the method further includes the step of: retrieving, by the second SMF (H-SMF), policies for each of the one or more offloading identifiers from a policy server in the home network or from an internal configuration of the second SMF, and if retrieved, the second SMF (H-SMF) includes them in a message to the first SMF (V-SMF), the message indicating a response to the request for PDU session establishment.

[0069] The request for PDU session establishment may also include one or more previously-provisioned offload IDs that identify any previously-provisioned one or more offload policies at the first SMF that may be timestamped, the timestamp indicating when the identified offload policy was provisioned. If the second SMF determines that the policy associated with the one or more previously-provisioned offload IDs needs to be updated at the first SMF, it sends the updated policy in a message in response to the indication to the first SMF so that the first SMF can update the policy for the offload ID.

[0070] According to some embodiments, there is provided a network node or server adapted to implement the method of any one of the embodiments described herein.

[0071] According to other embodiments, there is provided a network node or server that includes one or more processors and a memory, the memory including instructions that, when executed by the one or more processors, configure the network node or server to implement the method of any one of the embodiments described herein.

[0072] According to other embodiments, there is provided a non-transitory computer-readable storage medium that includes executable instructions that, when executed by a processor, cause the processor to implement any one of the embodiments described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] The drawings incorporated in and forming a part of this specification illustrate several aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0074] Figure 1 An example of a wireless communication system in which embodiments of the disclosure may be implemented is shown;

[0075] Figure 2 An example of the core network of a wireless communication system in which embodiments of the disclosure may be implemented is shown;

[0076] Figure 3A Another example of the core network of a wireless communication system is shown, which shows that the 5G system (5GS) provides access to the EAS in the case of having UL CL / BP for a non-roaming scenario;

[0077] Figure 3B Another example of the core network of a wireless communication system is shown, which shows that the 5G system (5GS) provides access to the EAS in the case of not having UL CL / BP for a non-roaming scenario;

[0078] Figure 4 An example of a 5G architecture for home routed session steering in a visited PLMN is shown;

[0079] Figure 5 illustrates the procedure for a PDU session to support HR-SBO in a VPLMN;

[0080] Figure 6 illustrates the detailed procedure for PDU session establishment according to an embodiment of the present disclosure.

[0081] Figure 6A and Figure 6B illustrates a flowchart of a method implemented by a first and a second session management function according to an embodiment of the present disclosure.

[0082] Figure 7 、 Figure 8 and Figure 9 are schematic block diagrams of example embodiments of network nodes. Detailed Description

[0083] In general, all terms used herein shall be interpreted according to their ordinary meaning in the relevant technical field, unless explicitly given and / or implied a different meaning from the context in which it is used. Unless otherwise explicitly stated, all references to an / one / the element, apparatus, component, member, step, etc. shall be construed openly as referring to at least one instance of the element, apparatus, component, member or step, etc. The steps of any method disclosed herein do not have to be implemented in the exact order disclosed, unless a step is explicitly described as after or before another step and / or where it is implied that a step must be after or before another step. Whenever appropriate, any feature of any embodiment disclosed herein can be applied to any other embodiment. Similarly, any advantage of any embodiment can be applied to any other embodiment, and vice versa. By the following description, other objects, features and advantages of the appended embodiments will become apparent.

[0084] Although embodiments are described using a 5G core network, those skilled in the art will understand that any core network supporting edge computing can implement these embodiments, including 4G, 6G and above.

[0085] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are also included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0086] Radio node: As used herein, "radio node" is a radio access node or a wireless communication device.

[0087] Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node that operates in a radio access network (RAN) of a cellular communication network to wirelessly transmit and / or receive signals. Some examples of radio access nodes include, but are not limited to: base stations (e.g., a new radio (NR) base station (gNB) in a 3rd Generation Partnership Project (3GPP) 5th Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), high-power or macro base stations, low-power base stations (e.g., micro base stations, pico base stations, home eNBs, etc.), relay nodes, network nodes that implement part of the functions of a base station (e.g., a network node that implements a gNB central unit (gNB-CU) or a network node that implements a gNB distributed unit (gNB-DU) or a network node that implements part of the functions of some other type of radio access node).

[0088] Core Network Node: As used herein, a "core network node" is any type of node or server in the core network, or any node or server. Some examples of core network nodes include nodes that implement the following: access and mobility management function (AMF), user plane function (UPF), session management function (SMF), authentication server function (AUSF), network slice selection function (NSSF), network exposure function (NEF), network function (NF) repository function (NRF), policy control function (PCF), unified data management (UDM), etc. A network function (NF) can be implemented as a network element on dedicated hardware, a software instance running on dedicated hardware, or a virtualized function instantiated on a suitable platform (e.g., cloud infrastructure). One or more network functions can be implemented or hosted on the same node / server, or can be distributed across multiple nodes / servers.

[0089] Communication Device: As used herein, a "communication device" is any type of device that can access an access network. Some examples of communication devices include, but are not limited to: mobile phones, smart phones, sensor devices, meters, vehicles, home appliances, medical devices, media players, cameras, or any type of consumer electronics, such as, but not limited to, televisions, radios, lighting devices, tablet computers, laptop computers, or personal computers (PCs). A communication device can be a portable, hand-held, computer-included, or vehicle-mounted mobile device capable of transmitting voice and / or data via a wireless or wired connection.

[0090] Wireless communication device: One type of communication device is a wireless communication device, which can be any type of wireless device capable of accessing a wireless network (such as a cellular network) (i.e., being served by a wireless network). Some examples of wireless communication devices include, but are not limited to: user equipment (UE) in a 3GPP network, machine type communication (MTC) devices, and Internet of Things (IoT) devices. Such a wireless communication device can be or can be integrated into: a mobile phone, a smart phone, a sensor device, a meter, a vehicle, a household appliance, a medical device, a media player, a camera, or any type of consumer electronics, such as, but not limited to, a television, a radio, a lighting device, a tablet computer, a laptop computer, or a PC. The wireless communication device can be a portable, hand-held, computer-included, or vehicle-mounted mobile device capable of transmitting voice and / or data via a wireless connection.

[0091] Network node: As used herein, a "network node" is any node that is part of the core network or RAN of a cellular communication network / system.

[0092] Note that the description given herein focuses on 3GPP cellular communication systems, and thus, 3GPP terms or terms similar to 3GPP terms are often used. However, the concepts disclosed herein are not limited to 3GPP systems.

[0093] Note that in the description herein, the term "cell" may be referred to; however, especially with respect to the 5G NR concept, beams can be used instead of cells, and thus, it is important to note that the concepts described herein apply equally to both cells and beams.

[0094] Figure 1FIG. 0 shows an example of a cellular communication system 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communication system 100 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC). In this example, the RAN includes base stations 102-1 and 102-2, which include NR base stations (gNBs) in the 5GS and control corresponding (macro) cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to as base station 102 herein and individually as base station 102. Similarly, the (macro) cells 104-1 and 104-2 are generally referred to as (macro) cell 104 herein and individually as (macro) cell 104. The RAN may also include a plurality of low-power nodes 106-1 to 106-4 that control corresponding small cells 108-1 to 108-4. The low-power nodes 106-1 to 106-4 may be small base stations (such as pico or femto base stations) or RRHs, etc. It is noted that although not shown, one or more of the small cells 108-1 to 108-4 may optionally be provided by the base station 102. The low-power nodes 106-1 to 106-4 are generally referred to as low-power node 106 herein and individually as low-power node 106. Similarly, the small cells 108-1 to 108-4 are generally referred to as small cell 108 herein and individually as small cell 108. The cellular communication system 100 further includes a core network 110, which is referred to as 5GC in the 5G system (5GS). The base stations 102 (and optionally the low-power nodes 106) are connected to the core network 110.

[0095] The base stations 102 and the low-power nodes 106 provide services to wireless communication devices 112-1 to 112-5 in the corresponding cells 104 and 108. The wireless communication devices 112-1 to 112-5 are generally referred to as wireless communication device 112 herein and individually as wireless communication device 112. In the following description, the wireless communication device 112 is generally a UE, but the present disclosure is not limited thereto.

[0096] Figure 2 FIG. 7 shows a wireless communication system represented as a 5G network architecture consisting of core network functions (NFs), where the interaction between any two NFs is represented by point-to-point reference points / interfaces. Figure 2 can be regarded as Figure 1 a specific implementation of the cellular communication system 100.

[0097] A network function (NF) may be implemented as a network element on dedicated hardware, a software instance running on dedicated hardware, or a virtualized function instantiated on a suitable platform (such as a cloud infrastructure).

[0098] From the access side, Figure 2The 5G network architecture shown in [Figure] includes multiple UEs 112 connected to the RAN 102 or access network (AN) and the AMF 200. Generally, the R(AN) 102 includes base stations such as eNBs, gNBs, or the like. From the core network side, Figure 2 The 5GC NFs shown in [Figure] include the NSSF 202, AUSF 204, UDM 206, AMF 200, SMF 208, PCF 210, and application function (AF) 212.

[0099] The reference points of the 5G network architecture are used to develop detailed call flows in specification standardization. The N1 reference point is defined to carry signaling between the UE 112 and the AMF 200. The reference points used for connection between the AN 102 and the AMF 200 and between the AN 102 and the UPF 214 are defined as N2 and N3, respectively. There is a reference point N11 between the AMF 200 and the SMF 208, which means that the SMF 208 is at least partially controlled by the AMF 200. N4 is used by the SMF 208 and the UPF 214 so that the UPF 214 can be set using the control signals generated by the SMF 208, and the UPF 214 can report its status to the SMF 208. Separately, N9 is the reference point for connection between different UPF 214s, and N14 is the reference point for connection between different AMF 200s. Since the PCF 210 applies policies to the AMF 200 and the SMF 208 respectively, N15 and N7 are defined. N12 is required for the AMF 200 to implement the authentication of the UE 112. Since the subscription data of the UE 112 is required for the AMF 200 and the SMF 208, N8 and N10 are defined.

[0100] The 5GC network aims to separate the U-plane and the C-plane. The U-plane carries user traffic, while the C-plane carries signaling in the network. In Figure 2 [Figure], the UPF 214 is located in the U-plane, and all other NFs, namely the AMF 200, SMF 208, policy control function (PCF) 210, AF 212, network slice selection function (NSSF) 202, authentication server function (AUSF) 204, and UDM 206, are located in the C-plane. Separating the U-plane and the C-plane ensures that each plane resource is scaled independently. It also allows the UPF to be deployed in a distributed manner separately from the C-plane functions. In this architecture, the UPF can be deployed very close to the UE to shorten the round-trip time (RTT) between the UE and the data network for some applications that require low latency.

[0101] The core 5G network architecture consists of modular functions. For example, the AMF 200 and the SMF 208 are independent functions in the CP. The separated AMF 200 and SMF 208 allow for independent evolution and scaling. Other CP functions, such as the PCF 210 and the AUSF 204, can be separated as shown in Figure 2 . The modular function design enables the 5GC network to flexibly support various services.

[0102] Each NF directly interacts with another NF. Intermediate functions can be used to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as a service so that its reuse becomes possible. This service enables the support of modularity. The UP supports interactions between different UPFs, such as forwarding operations.

[0103] 3GPP TR 23.700-48 lists two main scenarios in Section 5.1.2:

[0104] 2.1) The HPLMN knows the EAS deployment information in the VPLMN for a specific service. The HPLMN triggers EAS discovery and local traffic routing in the VPLMN.

[0105] 2.2) The HPLMN does not know the EAS deployment information in the VPLMN. The VPLMN triggers EAS discovery and local traffic routing in the VPLMN.

[0106] From the perspective of sending traffic offloading information (also known as the VPLMN-specific offloading policy), the most difficult is scenario 2.1. The main problem with this scenario is that since the HPLMN knows the EDI (Edge Deployment Information, as defined in TS23.548 and incorporated herein by reference), this assumes that the HPLMN has a business relationship with an EC (Edge Computing) service provider.

[0107] In various embodiments disclosed herein, the UDM can be used to indicate an appropriate reference to the H-SMF to select the required VPLMN-specific offloading policy.

[0108] The amount of information exchanged between the HPLMN and the VPLMN can be reduced.

[0109] According to the embodiments proposed herein, the following offloading information needs to be conveyed to the VPLMN for home routed session offloading (HR-SBO). In this case, session offloading uses an uplink classifier or an IPv6 branch point (as per TS23.501):

[0110] 1. Authorization for HR-SBO from the HPLMN

[0111] 2. Policies related to the PDU session, such as AMBR

[0112] 3. Information based on which the VPLMN can implement UL CL / BP and local PSA selection.

[0113] 4. Other potential service SLA-related information.

[0114] Regarding the above point 3, for the information conveyed to support session steering, the following alternatives can be seen:

[0115] 1. All the information required (including EDI as defined in TS23.548) is conveyed. This is to support the complete EAS rediscovery process as in TS23.548. This means that a large amount of information such as EDI, which is (usually) not PDU session-related information, is conveyed for each PDU session. Providing the EDI related to the VPLMN topology to the HPLMN assumes that the SP has service agreements with both the VPLMN and the HPLMN. This is because the VPLMN DNAI in the EDI should first be agreed upon and exchanged between the service provider (SP) and the VPLMN, and only then can the SP provide the EDI related to the VPLMN DNAI to the HPLMN. The same communication chain is also required when the VPLMN DNAI changes.

[0116] 2. The offloading policy information includes the EC FQDN and (optionally) the IP ranges to be configured in the UL CL / BP. In this case, the V-SMF selects the UL CL or BP and the L-PSA based on the UE location, without considering the EAS deployment information. This is proposed in solutions #02, #03, #05, and #25 from TR 23-700-48.

[0117] According to the proposed embodiment, this information should be stored in the H-SMF and correctly indexed. In the case of the EDI from point 1 above, each EDI is stored and indexed separately. Similarly, the offloading policy information from point 2 above can also be indexed. An example is shown in Table 2 below.

[0118]

[0119] Table 2 FQDN and IP address ranges for allowed EC services indexed according to EC services

[0120] In the proposed embodiment, different rows in Table 2 marked with offload_ID_A, offload_ID_B, etc. in the table will correspond to traffic offload policies for specific EC services. Thus, the FQDN can be used to provision V-EASDF through DNS-based EAS discovery in the case of session steering, while the list of IP ranges is the list of EAS IP ranges authorized for a given service in UL CL / BP. Note that the service-related offload information A, B, etc. is independent of the VPLMN, although some EAS IP ranges will never be configured for a specific VPLMN because they represent service provider deployments in different countries and PLMNs (assuming that when the DNS response contains both the EAS IP address and the ECS belonging to a given IP address range, a UL CL configuration update for that given IP address range occurs).

[0121] In the example, each row in Table 2 is within a country-specific IP address range, and then keys A1, A2, B1, B2, etc. will identify both the service and the geographical area (e.g., MCC) associated with the IP range. This is shown in Table 3 below. Note that offload IDs A1, A2, B1, B2, etc. can be derived based on the offload ID for the service and the VPLMN ID respectively.

[0122]

[0123] Table 3 FQDNs for allowed EC services indexed by EC service together with IP address ranges using MCC

[0124] As the information structure proposed in Tables 2 and 3 does not require VPLMN DNAI, this method simplifies the information exchanged between all parties (VPLMN DNAI in EDI to HPLMN requires the home MNO to know the VPLMN DNAI, the HPLMN shares these VPLMN DNAIs with the service provider (SP) with which it has an agreement, the SP provides the EDI related to the VPLMN DNAI and modifies it in case the VPLMN DNAI changes). It also reduces the information that the H-SMF needs to provide to the V-SMF.

[0125] The above shows that the VPLMN-specific offload policy can include traffic descriptors (FQDN and IP address ranges) allowed for HR-SBO.

[0126] The VPLMN-specific offload policy can have different components depending on which MNO the service provider (SP) has a contract with.

[0127] If there is an agreement between the SP and the VPLMN, then EC application information (e.g., EDI) is available in the VPLMN. In this case, the HPLMN may minimally provide only the HR-SBO authorization indication to the VPLMN. However, the HPLMN may provide other services for a given UE and PDU session and other non-EC applications. If this is the case, then these applications should not be allowed for SBO in the VPLMN. Therefore, the VPLMN-specific offloading policy may include service descriptors (e.g., destination IP range, port, FQDN) not allowed for HR-SBO.

[0128] Table 4 contains an example of how to extend session management subscription data based on the existing UE subscription data as shown in Table 1 (i.e., Table 5.2.3.3.1-1 in TS23.502). The data can be extended with the following information:

[0129]

[0130] Table 4 presents the HR-SBO for the existing UE subscription data (i.e., Table 5.2.3.3.1-1 in TS23.502 V.17.4.0)

[0131] Related additional session management subscription data

[0132] Each offloading identifier identifies a service composed of a list of FQDNs and / or a list of IP address ranges defined in Table 2 or Table 3 above. Therefore, in some embodiments, it is sufficient for the H-SMF to send the offloading identifier to the V-SMF instead of the entire information. By doing so, the amount of information exchanged between the HPLMN and the VPLMN can be reduced.

[0133] Figure 6 The process of PDU session establishment according to an embodiment of the present disclosure is shown.

[0134] Step 1: The UE sends a PDU session establishment request to the V-SMF 328 selected by the AMF 322.

[0135] Step 2: The V-SMF 328 selects a UPF in the VPLMN (which can be based on the policy obtained from the V-PCR), and sends an Nsmf_PDUSession_Create request to the H-SMF 310, where it sends a support and / or authorization request for HR-SBO and provides the V-EASDF 316 address to the H-SMF 310. The V-SMF 328 also sends the offloading ID for the offloading information previously received from the H-SMF 310 (if any), and the offloading ID can be marked with a timestamp regarding the time when they were received.

[0136] Step 3: The H-SMF 310 requests the session management subscription data using Nudm_SDM_Get (SUPI, session management subscription data, selected DNN, S-NSSAI of the HPLMN, serving PLMN ID, [NID]) and subscribes using Nudm_SDM_Subscribe to be notified when the subscription data is modified.

[0137] Step 4: The UDM 308 responds with the session management subscription data. This data includes VPLMN-specific service offloading information, for example, as shown in Table 4 according to an embodiment of the present disclosure.

[0138] Step 5: The H-SMF 310 then checks the offloading ID in the VPLMN-related offloading information received from the UDM 308, and it can generate a further offloading ID based on the offloading ID received from the UDM 308 and the VPLMN ID indicated in the request from the V-SMF 328. Non-limiting examples of how the H-SMF 310 generates the offloading ID include: using an algorithm to derive the Mobile Country Code (MCC) from the received VPLMN ID, and then the offloading identifier can be generated using the following:

[0139] ● The offloading identifier (describing the FQDN of the EC service) received from the subscription server (e.g., UDM 308),

[0140] and

[0141] ● The MCC derived from the VPLMN iD

[0142] Then, the generated offloading identifier will identify the IP address range in the service offloading policy of a given EC service belonging to the geographical area identified by the MCC. Thus, based on the above generation algorithm, the generated offloading identifiers will be derived for each region of a specific country.

[0143] Note that in this way, the same identifier may result in different VPLMNs in a specific country. These offloading IDs can be used to identify the EAS IP address range for the EC service in the geographical area, e.g., the MCC of the VPLMN, as shown in Table 2.

[0144] The H-SMF 310 can compare the offloading ID from the subscription and the further generated offloading ID with the offloading ID received from the V-SMF 328. For some offloading IDs received from the UDM 308-related information or offloading IDs generated by the H-SMF 310, it can also check whether the configuration information (i.e., offloading policy) has changed based on the received timestamp.

[0145] Step 6: The H-SMF 310 sends an Nsmf_PDUSession_Create response to the V-SMF 328, which includes a VPLMN-specific offloading policy (also including the associated offloading ID). The associated offloading ID may include:

[0146] - The offloading ID received from the UDM and / or generated by the H-SMF 310 and the corresponding offloading policy (optional), and if there is no requirement to update the corresponding policy, no offloading ID received from the V-SMF 328, or

[0147] - The offloading ID received from the UDM 308 and / or generated by the H-SMF 310 and the corresponding offloading policy (optional), and if the corresponding policy has been updated during this period, also the offloading ID received from the V-SMF,

[0148] and the associated updated policy information.

[0149] Optionally, the response includes all offloading IDs and the corresponding offloading policy information, which will overwrite all offloading policies in the V-SMF 328.

[0150] Optionally, when there is no requirement to update the policy for the offloading ID provided by the V-SMF, the response may include the offloading ID and the associated offloading policy information (from subscription and / or generation), or it may only include the offloading ID provided by the V-SMF 328 for the unchanged policy already available in the V-SMF 328, to indicate to the V-SMF 328 that the unchanged policy is still valid. It will be apparent to those skilled in the art that any combination of adding, updating, or deleting offloading policies and associated offloading IDs from the H-SMF 310 to the V-SMF 328 is supported.

[0151] Step 7: The V-SMF stores any offloading policies (if received) and offloading IDs provided by the H-SMF 310 and sends a PDU session establishment response to the UE.

[0152] The processes described herein are described between a home PLMN and a visited PLMN and between a visited SMF and a home SMF. However, Figure 6 embodiments of can also be implemented between an SMF in a PLMN and a non-public network (NPN).

[0153] Figure 6AIt is a flowchart showing a method of a first SMF in a first network initiating a PDU session establishment request to a second SMF in a second network. The first SMF is exemplified as a visited SMF (V-SMF) in a visited PLMN, and the second SMF is exemplified as a home SMF (H-SMF) in an HPLMN, but is not limited thereto.

[0154] In step 610A, when the first SMF receives a PDU session establishment request for a UE from the AMF, the AMF may indicate to the first SMF that the requested session is allowed for HR-SBO. After the first SMF selects a UPF in the VPLMN (which may be based on policies obtained from a PCF in the first network) and sends an Nsmf_PDUSession_Create request to the second SMF in the second network, it includes a support and / or authorization request for HR-SBO. The first SMF also provides the V-EASDF address to the H-SMF. If any, the first SMF also includes the offload ID of a previously provided offload policy. The offload ID may be marked with a timestamp indicating when the corresponding policy was received and provided.

[0155] In step 620A, the first SMF receives an Nsmf_PDUSession_Create response from the second SMF. The response includes one or more offload IDs, each offload ID identifying a first network-specific offload policy to be applied by the first SMF for home routed session steering.

[0156] The response may also include the first network-specific offload policies identified by each of the one or more offload IDs, where the one or more offload IDs correspond to offload IDs from subscription data or offload IDs generated therefrom.

[0157] If the PDU session establishment request in 610A includes one or more previously provided offload IDs and optionally includes a timestamp when the corresponding policy was received or provided, the response includes at least one of the following:

[0158] ● One or more previously provided offload IDs (as included in request step 610A) and the corresponding updated offload policy; and

[0159] ● One or more first network-specific policies and the associated offload identifiers corresponding to offload identifiers obtained or generated from subscription data.

[0160] In another example, the first SMF may also receive a response that does not contain any specific offloading policy and related offloading ID. If the V-SMF has included an existing or previously provisioned offloading ID in the request in step 610A, the V-SMF may interpret the response that does not include any updated offloading policy for the related offloading ID as maintaining any existing offloading policy and related offloading ID, i.e., the previous offloading policy has not expired.

[0161] Optionally, the response may include the previously provisioned offloading ID included in the request, without including the corresponding offloading policy information, as an acknowledgement by the second SMF that those previously provisioned offloading policies are still valid. The first SMF shall interpret using the same policy corresponding to the previously provisioned offloading ID.

[0162] The first SMF stores and executes any received offloading policy with a related offloading identifier.

[0163] The offloading policy information includes the EC FQDN and (optionally) the IP ranges to be configured in the UL CL / BP for allowed and / or non-allowed edge computing (EC) services. In this case, the first SMF selects the UL CL or BP and the L-PSA based on the UE location, regardless of the EAS deployment information. Additionally, other information that may be conveyed in the response includes the EDI defined in TS23.548. This is to support the refined EAS rediscovery process as in TS23.548. This means that a large amount of information such as the EDI is conveyed for each PDU session, which is (usually) not PDU session-related information. Providing the EDI related to the first network (e.g., VPLMN) topology to the second network (e.g., HPLMN) assumes that the SP has service agreements with both the first and second networks (e.g., VPLMN and HPLMN). This is because the first network DNAI in the EDI should first be agreed upon and exchanged between the service provider (SP) and the first network, and only then can the SP provide the EDI related to the first network DNAI to the second network. The same communication chain is also required when the first network DNAI changes. The first SMF updates and stores the offloading ID and its corresponding offloading policy information received from the second SMF. The first SMF sends a PDU session establishment response to the UE and executes the policy for HR-SBO.

[0164] Figure 6B is a flowchart showing a method for providing a first network-specific policy to a first SMF in a first network during a PDU session establishment process implemented by a second SMF in a second network. The first SMF is exemplified as the visited SMF in the visited PLMN, and the second SMF is exemplified as the home SMF in the HPLMN, but is not limited thereto.

[0165] In step 610B, the method includes the step of receiving a request for PDU session establishment from a first SMF in the first network, the request including an indication that the first SMF supports home routing session breakout (HR-SBO) and / or requests authorization for home routing session breakout (HR-SBO) from a second SMF in the second network. In step 620B, the second SMF continues to obtain session management subscription data from a subscription server (such as UDM). The subscription data includes first network specific service offload information, which includes the information in Table 4 above, namely:

[0166] - An indication of whether the first network is authorized for HR-SBO, which can be one or both of the following:

[0167] o Destination IP range for one or more Edge Compute (EC) services allowed for HR-SBO and

[0168] One or more uninstall identifiers and / or a list of FQDNs, and

[0169] o One or more offload identifiers for a list of destination IP ranges and / or FQDNs for one or more edge computing (EC) services that are not allowed for HR-SBO.

[0170] The UDM only needs to indicate the offload identifier to the second SMF, and does not need to provide the offload policy itself.

[0171] Optionally, in step 625B, the second SMF may generate further offload IDs based on the offload ID received from the subscription server (e.g., UDM) and the first network ID (e.g., VPLMN ID) indicated in the request from the first SMF (as described above). These further generated offload IDs may be used to identify the EAS IP address ranges of EC services in a geographic area, for example, the MCC of the first network (e.g., VPLMN), as shown in Table 2. Offload policies indexed by the offload identifiers (from subscription or generated) are configured in the second SMF. Optionally, the second SMF may retrieve offload policies from a memory or server (such as a policy server) by using the offload identifiers as one or more indexes of the offload policies it requires.

[0172] In step 630B, the second SMF sends a response message to the first SMF, and the response message includes: one or more offload identifiers obtained from the subscription server, each offload identifier identifying a first network-specific offload policy for home routed session steering to be applied by the first SMF, and / or one or more offload identifiers further generated by the second SMF based on the offload identifiers received in the subscription data, each offload identifier identifying a first network-specific offload policy for home routed session steering to be applied by the first SMF. The message may also include the relevant offload policies retrieved for the relevant one or more offload identifiers (subscribed and / or generated).

[0173] In one example, the method further includes: receiving, in a request for PDU session establishment, one or more previously-provisioned offload identifiers that identify one or more first network-specific offload policies previously provisioned at a first SMF in a first network, wherein each of the one or more previously-provisioned offload identifiers is optionally marked with a timestamp that indicates when the identified first network-specific offload policy was provisioned.

[0174] In one example, when one or more previously-provisioned offload identifiers are received in a request for PDU session establishment, once the session management subscription data and one or more offload identifiers are received (step 620B), the second SMF may generate further offload identifiers based on the VPLMN ID and the offload identifiers received in the session management subscription data. Then, the second SMF determines whether the one or more previously-provisioned offload identifiers received from the first SMF are the same as or different from the one or more offload identifiers included in the session management subscription data and / or the further-generated offload identifiers. In this example, the only criterion is the matching of the offload identifiers. If the identifiers are the same or match, the second SMF retrieves one or more first network-specific offload policies corresponding to the matching one or more offload identifiers. However, the second SMF also retrieves the corresponding offload policies for the non-matching one or more offload identifiers for the offload identifiers included in the subscription data and / or further-generated. Then, the second SMF includes, in the response message to the first SMF, one or more first network-specific offload policies retrieved for each of the associated one or more offload identifiers (i.e., for both the matching and non-matching offload identifiers included in the subscription data / further-generated (if any)).

[0175] In another example, after receiving one or more previously-provisioned offload identifiers (including a timestamp) in a request for PDU session establishment, once session management subscription data and one or more offload identifiers are received (step 620B), and optionally further offload identifiers are generated based on the session management subscription data and a first network identifier (see above), the second SMF in the second network determines whether one or more previously-provisioned offload identifiers received from the first SMF are the same (i.e., match) or different from one or more offload identifiers received in the session management subscription data and / or one or more offload identifiers further generated by the second SMF as explained above.

[0176] If, in this another example, the offload identifiers are the same / match, the second SMF determines whether the timestamp provided together with one or more previously-provisioned offload identifiers indicates that a corresponding previously-provisioned first network-specific offload policy has expired or needs to be updated, and in response to determining that one or more previously-provisioned first network-specific offload policies have expired or need to be updated, the second SMF proceeds to retrieve one or more updated first network-specific offload policies for the matching one or more offload identifiers (subscribed / further-generated offload identifiers). However, in response to determining that one or more previously-provisioned first network-specific offload policies have not expired or do not need to be updated, the second SMF does not need to retrieve one or more first network-specific offload policies for the matching one or more offload identifiers, as those policies are assumed to still be valid in the first SMF. The second SMF proceeds by including at least one of the following in the message indicating the response:

[0177] ● One or more updated first network-specific offload policies retrieved for each offload identifier among the one or more associated offload identifiers that match one or more previously-provisioned offload identifiers included in the request

[0178] ● And any one or more first network-specific policies retrieved for one or more non-matching offload identifiers obtained from the subscription data and / or for offload identifiers further generated by the second SMF.

[0179] In yet another example, after receiving one or more previously-provisioned offload identifiers (including a timestamp) in a request for PDU session establishment, once the session management subscription data and one or more offload identifiers are received (step 620B), and optionally a further offload identifier is generated based on the offload identifiers included in the session management subscription data and the first network identifier included in the request from the first SMF (see above), the second SMF in the second network determines whether the one or more previously-provisioned offload identifiers received from the first SMF are the same (i.e., match) or different (do not match) from the one or more offload identifiers received in the session management subscription data and / or further generated by the second SMF. If the second SMF determines that the offload identifiers are different / do not match, the second SMF determines whether the timestamp provided together with the one or more previously-provisioned offload identifiers indicates that the corresponding one or more first network-specific offload policies have expired or need to be updated. In response to determining that the one or more first network-specific offload policies have expired or need to be updated, in this yet another example, the second SMF retrieves one or more updated first network-specific offload policies for the expired policies, and one or more first network-specific offload policies for the one or more offload identifiers from the session management subscription data and / or the one or more further generated offload identifiers. Additionally, in response to determining that the one or more first network-specific offload policies have not expired, the second SMF will retrieve one or more first network-specific offload policies only for the one or more offload identifiers from the session management subscription data (in this case, all offload identifiers do not match the offload identifiers included in the PDU session request), and the second SMF continues by including at least one of the following in the response to the first SMF:

[0180] ● one or more first network-specific offload policies retrieved for each of the associated one or more offload identifiers from the subscription data and / or for each of the offload identifiers further generated by the second SMF,

[0181] ● one or more updated first network-specific offload policies retrieved for each of the associated one or more previously-provisioned offload identifiers indicated as expired.

[0182] In another example, after receiving one or more previously-provisioned offload identifiers (which may or may not include a timestamp) in a request for PDU session establishment, once session management subscription data and one or more offload identifiers are received (step 620B), and optionally a further offload identifier is generated based on the offload identifiers included in the session management subscription data and the first network identifier included in the request from the first SMF (see above), the second SMF in the second network determines whether one or more previously-provisioned offload identifiers received from the first SMF are the same (i.e., match) or different from one or more offload identifiers received in the session management subscription data and / or further generated by the second SMF. If the second SMF determines that they are different / do not match, the second SMF retrieves one or more first network-specific offload policies for one or more offload identifiers included in the session management subscription data (from configuration, memory, or a server, such as a PCF), and includes in the PDU session establishment response message to the first SMF information indicating the one or more first network-specific offload policies retrieved for each of the associated one or more offload identifiers from the subscription data and / or for each of the associated one or more offload identifiers generated by the second SMF.

[0183] In some examples, the first network-specific offload policy includes one or more fully qualified domain names (FQDNs), and optionally includes a range of Internet Protocol (IP) addresses for permitted and / or non-permitted edge computing services.

[0184] Other information that can be included as part of the offloading policy stored, retrieved, and provided by the second SMF to the first SMF includes EDI as defined in TS23.548. This is to support the refined EAS rediscovery process as in TS23.548. This means that a large amount of information such as EDI is conveyed for each PDU session, which is (usually) not PDU session-related information. Providing EDI related to the first network (e.g., VPLMN) topology to the second network (e.g., HPLMN) assumes that the SP has service agreements with both the first network and the second network (e.g., VPLMN and HPLMN). This is because the first network / VPLMN DNAI in the EDI should first be agreed upon and exchanged between the service provider (SP) and the first network / VPLMN, and only then can the SP provide the EDI related to the first network / VPLMN DNAI to the HPLMN. The same communication chain is also required when the first network / VPLMN DNAI changes. The first SMF updates and stores the offloading ID and its corresponding offloading policy information as received from the second SMF. The first SMF sends a PDU session establishment response to the UE and enforces the policy for HR-SBO.

[0185] As previously indicated, the first network and the second network are not limited to VPLMN and HPLMN, and the embodiments can be applied between a PLMN and an NPN, and may also be applied between two NPNs.

[0186] In another embodiment, a subscription server (e.g., UDM in 5G) maintains and provides subscription data to the SMF. The subscription data can be maintained in a UDR (repository) and retrieved from the UDM when requested by a consumer such as the SMF. The session management subscription data is extended to include additional data for HR-SBO. Information is stored for each serving PLMN and DNN in a network slice. Details of the subscription data are shown in Table 4.

[0187] If the consumer (SMF) subscribes to be notified of any changes, the UDM provides the subscription data when the subscription data is requested or when it is modified.

[0188] Figure 7FIG. 0 is a schematic block diagram of a network node 700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. For example, the network node 700 may be a core network node implementing an NF (e.g., AMF 200, SMF 208, V-SMF 328, UL CL / BP330-1, V-EASDF 316, H-SMF 310, UDM 308, H-DNS 320, or H-EASDF 318), or a network node that implements all or part of the functions of an NF (e.g., all or part of the functions of the AMF 200, SMF 208, V-SMF 308, UL CL / BF330-1, V-EASDF 316, H-SMF 310, UDM 308, H-DNS 320, or H-EASDF 318 described herein). As shown, the network node 700 includes one or more processors 704 (e.g., a central processing unit (CPU), an application specific integrated circuit (ASIC), and / or a field programmable gate array (FPGA), etc.), a memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. The one or more processors 704 operate to provide one or more functions of the network node 700 as described herein (e.g., one or more functions of the AMF 200, SMF 208, V-SMF 328, UL CL / BP 330-1, V-EASDF 316, H-SMF 310, UDM 308, H-DNS 320, or H-EASDF 318 described herein). In some embodiments, the functions are implemented in software, which is stored, for example, in the memory 706 and executed by the one or more processors 704.

[0189] Figure 8FIG. 0 is a schematic block diagram showing a virtualized implementation of network node 700 according to some embodiments of the present disclosure. Similarly, optional features are represented by dashed boxes. As used herein, a “virtualized” network node is an implementation of network node 700 in which at least a portion of the functionality of network node 700 is implemented as virtual components (e.g., via virtual machines executed on physical processing nodes in the network). As shown, in this example, network node 700 includes one or more processing nodes 800 coupled to or included as part of network 802. Each processing node 800 includes one or more processors 804 (e.g., CPUs, ASICs, and / or FPGAs, etc.), a memory 806, and a network interface 808. In this example, the functionality 810 of network node 700 described herein (e.g., one or more of the functions of AMF 200, SMF 208, V-SMF 328, ULCL / BP 330-1, V-EASDF 316, H-SMF 310, UDM 308, H-DNS 320, or H-EASDF 318 described herein) is implemented at one or more of the processing nodes 800, or distributed in any desired manner across two or more of the processing nodes 800. In some particular embodiments, some or all of the functionality 810 of network node 700 described herein is implemented as virtual components executed by one or more virtual machines implemented in a virtual environment hosted by the processing nodes 800.

[0190] In some embodiments, a computer program including instructions is provided that, when executed by at least one processor, causes the at least one processor to perform the functionality of network node 700 according to any of the embodiments described herein or of a node (e.g., processing node 800) that implements one or more of the functionality 810 of network node 600 in a virtual environment. In some embodiments, a carrier including the above computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).

[0191] Figure 9 FIG. 7 is a schematic block diagram of network node 700 according to some other embodiments of the present disclosure. Network node 700 includes one or more modules 900, each implemented in software. The modules 900 provide the functionality of network node 700 described herein. This discussion applies equally to Figure 8 processing node 800, where the modules 800 may be implemented at one of the processing nodes 800 or distributed across multiple processing nodes 800.

[0192] Any suitable steps, methods, features, functions, or benefits disclosed herein may be implemented by one or more functional units or modules of one or more virtual devices. Each virtual device may include a plurality of such functional units. These functional units may be implemented via a processing circuit, which may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include a digital signal processor (DSP), dedicated digital logic, etc. The processing circuit may be configured to execute program code stored in a memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache, flash memory devices, optical storage devices, etc. The program code stored in the memory includes program instructions for executing one or more telecommunication and / or data communication protocols, as well as instructions for performing one or more of the techniques described herein. In some implementations, the processing circuit may be used to cause the corresponding functional units to implement corresponding functions according to one or more embodiments of the present disclosure.

[0193] Although the processes in the figures may show a specific order of operations implemented by certain embodiments of the present disclosure, it should be understood that this order is exemplary (e.g., alternative embodiments may implement the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0194] Example:

[0195] The following are example non-limiting claim embodiments that are used as the basis for future claims. However, the complete content of this application will be used as the basis for future claims.

[0196] Group A: V-SMF

[0197] Embodiment 1. A method for providing offloading information from a first network to a second network, the method being implemented in a first session management function in the first network, the method comprising:

[0198] Sending, by a first SMF in the first network, a request for PDU session establishment to a second SMF in the second network, which indicates that the first SMF supports and / or requests authorization for home routed session steering of the PDU session;

[0199] Receiving, from the second SMF, a message indicating a response, the response including one or more offloading IDs, each offloading ID identifying a first network-specific offloading policy to be applied by the first SMF for home routed session steering.

[0200] Example 2. The method according to Example 1, wherein the message indicating the response further comprises: the first network-specific offloading policy identified by each of the one or more offloading IDs.

[0201] Example 3. The method according to Example 1, wherein the request for the PDU session establishment comprises: one or more previously-provisioned offloading IDs identifying the one or more previously-provisioned first network-specific offloading policies, wherein each of the one or more previously-provisioned offloading IDs is optionally marked with a timestamp indicating when the identified previously-provisioned first network-specific offloading policy was provisioned.

[0202] Example 4. The method according to any one of Examples 1-3, wherein the message indicating the response comprises at least one of the following:

[0203] - the one or more previously-provisioned offloading IDs and the corresponding updated offloading policies;

[0204] - the one or more first network-specific policies and the associated offloading identifiers corresponding to the offloading identifiers obtained from the subscription data, and / or one or more offloading identifiers generated according to the offloading identifiers obtained from the subscription data.

[0205] Example 5. The method according to any one of Examples 1 to 4, wherein the method further comprises: storing the first network-specific policies (existing, received (new), and updated).

[0206] Example 6. The method according to Example 1, wherein the first network-specific offloading policy comprises: one or more fully qualified domain names (FQDNs) and an optional range of Internet Protocol (IP) addresses for the allowed edge computing services.

[0207] Example 7. The method according to Example 1, wherein the first network-specific offloading policy comprises: one or more fully qualified domain names (FQDNs) and an optional range of Internet Protocol (IP) addresses for the non-allowed edge computing services.

[0208] Example 8. The method according to Example 6 or 7, wherein the method further comprises: configuring the UL CL / BP with the received (or updated) first network-specific offloading policy.

[0209] Example 9. The method according to any one of Examples 1 to 2, wherein the first network is a VPLMN, the second network is an HPLMN, the first SMF is a visited SMF, and the second SMF is an H-SMF.

[0210] Group B: H-SMF

[0211] Example 10. A method for providing offloading information from a second network to a first network, the method being implemented in a second session management function in the second network, the method comprising:

[0212] Receiving a request for PDU session establishment from a first SMF in the first network, which indicates that the first SMF supports and / or requests authorization for home routed session offloading (HR-SBO) of the PDU session;

[0213] Obtaining session management subscription data including first network specific service offloading information, including:

[0214] ■ An indication of whether the first network is authorized for HR-SBO and at least one of the following:

[0215] ■ One or more offloading identifiers of a list of destination IP ranges and / or FQDNs of one or more edge computing (EC) services allowed for HR-SBO, and

[0216] ■ One or more offloading identifiers of a list of destination IP ranges and / or FQDNs of one or more edge computing (EC) services not allowed for HR-SBO,

[0217] Sending a message indicating a response to the first SMF, the response including one or more offloading identifiers, each offloading identifier identifying a first network specific offloading policy for home routed session offloading to be applied by the first SMF.

[0218] Example 11. The method according to Example 10, further comprising: further generating one or more offloading identifiers based on the one or more offloading identifiers and a first network identifier obtained in the session management subscription data, and including the generated one or more identifiers in the message of the indication response to the first SMF.

[0219] Example 12. The method according to Example 10 or 11, wherein the method further comprises: retrieving the first network specific offloading policy for each offloading identifier included in the subscription data management and / or for each offloading identifier of the generated one or more offloading identifiers.

[0220] Example 13. The method according to any one of Examples 11-12, wherein the step of retrieving the first network specific offloading policy comprises: obtaining the first network specific offloading policy from the internal configuration or memory or policy server of the second SMF.

[0221] Example 14. The method according to any one of Examples 11 - 12, wherein the message indicating the response further comprises: a first network - specific offloading policy retrieved for each offloading identifier included in the subscription data management and / or for each of the one or more generated offloading identifiers.

[0222] Example 15. The method according to Example 10, wherein the request for the PDU session establishment comprises: one or more previously - provisioned offloading identifiers identifying one or more previously - provisioned first network - specific offloading policies at the first SMF, wherein each of the one or more previously - provisioned offloading identifiers is optionally marked with a timestamp indicating when the identified first network - specific offloading policy was provisioned.

[0223] Example 16. The method according to any one of Examples 11, 12, and 15, wherein the method further comprises: determining whether the one or more previously - provisioned offloading identifiers received from the first SMF are the same as or different from the one or more offloading identifiers from the session management subscription data and / or from the one or more generated offloading identifiers,

[0224] if the same, retrieving the one or more first network - specific offloading policies for the matching one or more offloading identifiers, and

[0225] if not the same, retrieving the one or more first network - specific offloading policies for the one or more offloading identifiers from the subscription data and / or for the one or more generated offloading identifiers, and

[0226] including the retrieved one or more first network - specific offloading policies and the associated one or more offloading identifiers in the message indicating the response, the associated one or more offloading identifiers corresponding to one or more matching offloading identifiers and one or more non - matching offloading identifiers obtained from the subscription data and / or from the generation.

[0227] Example 17. The method according to any one of Examples 11, 12, and 15, wherein the method further comprises: determining whether the one or more previously - provisioned offloading identifiers received from the first SMF are the same (match) as or different from the one or more offloading identifiers from the session management subscription data and / or from the one or more generated offloading identifiers,

[0228] If they are the same / match, determine whether the timestamps provided together with the one or more previously supplied offloading identifiers indicate that a corresponding previously supplied first network-specific offloading policy has expired or needs to be updated.

[0229] In response to determining that the one or more previously supplied first network-specific offloading policies have expired or need to be updated, retrieve one or more updated first network-specific offloading policies for the matching one or more offloading identifiers.

[0230] In response to determining that the one or more previously supplied first network-specific offloading policies have not expired or do not need to be updated, avoid retrieving the one or more first network-specific offloading policies for the matching one or more offloading identifiers.

[0231] Include, in the message indicating the response, one or more updated first network-specific offloading policies retrieved for each of the one or more offloading identifiers associated with and matching the one or more previously supplied offloading identifiers included in the request.

[0232] Example 18. The method according to Example 17, wherein the message indicating the response further includes: any one or more first network-specific policies retrieved for one or more non-matching offloading identifiers obtained from the subscription data and / or one or more non-matching offloading identifiers generated.

[0233] Example 19. The method according to any one of Examples 11, 12, and 15, wherein the method further includes: determining whether the one or more previously supplied offloading identifiers received from the first SMF are the same (match) or different from the one or more offloading identifiers from the session management subscription data and / or from the one or more generated offloading identifiers.

[0234] If they are different / do not match, retrieve the one or more first network-specific offloading policies for the one or more offloading identifiers obtained in the session management subscription data, and

[0235] Include, in the message indicating the response, one or more first network-specific offloading policies retrieved for each of the one or more offloading identifiers associated with and from the subscription data and / or from the generated ones.

[0236] Example 20. The method according to any one of Examples 14 to 19, wherein the first network-specific offloading policy includes: one or more fully qualified domain names (FQDNs) and an optional range of Internet Protocol (IP) addresses for permitted edge computing services.

[0237] Example 21. The method according to any one of Examples 14 to 19, wherein the first network-specific offloading policy comprises: one or more fully qualified domain names (FQDNs) and an optional range of Internet Protocol (IP) addresses for non-permitted edge computing services.

[0238] Example 22. A network node adapted to implement the method according to any one of Examples 1 to 21.

[0239] Example 23. A non-transitory computer-readable storage medium comprising executable instructions which, when executed by a processor, cause the processor to implement the method according to any one of Examples 1 to 21.

[0240] The following describes additional 3GPP materials, including additional examples based on the examples described in the present disclosure. The subject matter of this material is not restrictive and can be used to derive future claims:

[0241]

[0242] 1 Introduction

[0243] CR S2211366 of TS 23.548 related to the roaming HR-SBO scenario (Key Issue 1) has been accepted during SA2 #154 and has the following editorial notes:

[0244] Editorial Note: The user plane topology in the VPLMN supporting HR-SBO is FFS.

[0245] Editorial Note: Whether the AMF sends an indication to the V-SMF that the requested session is allowed for the HR-SBO PDU session is FFS. If agreed, this indication can be used by the V-SMF to decide whether to request an HR-SBO PDU session from the H-SMF.

[0246] Editorial Note: When the V-SMF selects the V-EASDF is FFS. In other words, the V-SMF selects the V-EASDF in the following cases: 1) before sending a Nsmf_PDUSession_Create request for the HR-SBO PDU session to the H-SMF, or 2) after receiving a Nsmf_PDUSession_Create response from the H-SMF.

[0247] Editor's Note: It is FFS that the SM subscription data includes 1) HR-SBO authorization indication or 2) HR-SBO authorization information (including VPLMN specific offloading policy). If only the HR-SBO authorization indication is added, the H-SMF retrieves the VPLMN specific offloading policy from the H-PCF (if available at the H-PCF) based on the SLA between the HPLMN and the VPLMN.

[0248] Editor's Note: Details of the VPLMN specific offloading policy (such as FQDN range, IP range, AMBR for the local part of the DN, or charging policy) are FFS.

[0249] Editor's Note: How to implement the EAS (re)discovery process for the HR-SBO roaming scenario is FFS.

[0250] These issues will be discussed below and directions for moving forward will be proposed for them.

[0251] 2 Discussion

[0252] 2.1 Indicating Permitted HR-SBO Sessions to the V-SMF

[0253] After selecting the V-SMF, the AMF contacts it to establish a PDU session towards the H-SMF. To handle HR-SBO, it requests specific V-SMF functions (selecting the V-EASDF, requesting an HR-SBO PDU session from the H-SMF, etc.), which are not typical of the V-SMF. To make the V-SMF aware that this function is requested, the AMF should send an indication to the V-SMF that the requested session is permitted for HR-SBO PDU sessions.

[0254] Recommendation 1: The AMF should send an indication to the V-SMF that the requested session is permitted for HR-SBO PDU sessions.

[0255] 2.2 Selection of the V-EASDF

[0256] Since the H-SMF may need the V-EASDF IP (to send it to the UE in the PCO message), this means that the V-SMF should have already selected the V-EASDF IP address and sent it to the H-SMF in the Nsmf_PDUSession_Create request for the HR-SBO PDU session. Otherwise, another signaling message would be needed to convey the V-EASDF information. If for some reason the H-SMF ultimately does not authorize HR-SBO, there will still be no unnecessary signaling or resource waste in the VPLMN.

[0257] Recommendation 2: Before sending a Nsmf_PDUSession_Create request for an HR-SBO PDU session, the V-SMF shall select a V-EASDF.

[0258] 2.3 Components of the VPLMN-specific offloading policy The VPLMN-specific offloading policy may have different components depending on which MNO the service provider (SP) has a contract with.

[0259] If there is an agreement between the SP and the VPLMN, then EC application information (e.g., EDI) is available in the VPLMN. In this case, the HPLMN may provide only a minimal HR-SBO authorization indication to the VPLMN. However, the HPLMN may provide other services for a given UE and PDU session and other non-EC applications. If this is the case, then these applications shall not be allowed for SBO in the VPLMN.

[0260] Recommendation 3: The VPLMN-specific offloading policy shall possibly include service descriptors (e.g., destination IP range, port, FQDN) not allowed for HR-SBO.

[0261] If there is an agreement between the SP and the HPLMN, then the HPLMN needs to provide the offloading policy required for HR-SBO to the VPLMN. Regarding the information communicated to support session steering, see the following alternatives:

[0262] - All the information required (including the EDI defined in TS 23.548) is communicated. This is to support a complete EAS rediscovery process as in TS 23.548. This means that a large amount of information such as EDI is transferred for each PDU session, which may not necessarily be PDU session-related information. Providing EDI related to the VPLMN topology to the HPLMN assumes that the SP has service agreements with both the VPLMN and the HPLMN. This is because the VPLMN DNAI in the EDI shall first be agreed upon and exchanged between the service provider (SP) and the VPLMN, only then can the SP provide the HPLMN with the EDI related to the VPLMN DNAI. The same communication chain is also required when the VPLMN DNAI changes.

[0263] - The offloading policy information includes the EC FQDN to be configured in the V-EASDF and the IP range to be configured in the UL CL / BP. In this case, the V-SMF selects the UL CL or BP and the L-PSA based on the UE location, regardless of the EAS deployment information. This is proposed in solutions #02, #03, #05, and #25 of TR 23-700-48.

[0264] In this case, the information can be constructed as follows:

[0265] Offload_ID_A: FQDN_1,..., FQDN_K: IP range_1,..., IP range_n...

[0266] Offload_ID_B: FQDN_K+1,..., FQDN_M: IP range_n+1,..., IP range_p...

[0267] ...

[0268] Table 1: FQDN and IP address ranges for permitted EC services

[0269] Here, the different rows marked with Offload_ID_A, Offload_ID_B, etc. in the table will correspond to the service offloading policies for specific EC services. Thus, the FQDN can be used to supply the V-EASDF in the case of dynamic PSA insertion based on DNS-based EAS discovery, while the list of IP ranges is the list of EAS IP ranges that should be configured in the UL CL / BP for a given service. Note that the service-related offloading information A, B, etc. is independent of the VPLMN, although some EAS IP ranges will never be configured for a specific VPLMN because they represent service provider deployments in different countries and PLMNs (assuming that when the DNS response contains both the EAS IP address and the ECS belonging to a given IP address range, a UL CL configuration update for the given IP address range occurs).

[0270] Another example is to split each row in Table 2 into country-specific IP address ranges, and then keys A1, A2, B1, B2, etc. will identify the services and geographical regions (e.g., MCC) associated with the IP ranges. This is shown in Table 2 below. Note that the offload IDs A1, A2, B1, B2, etc. can be derived based on the offload ID for the service and the VPLMN ID respectively.

[0271]

[0272] Table 2: FQDN for permitted EC services indexed by EC service together with IP address ranges using MCC

[0273] Therefore, this information structure does not require the VPLMN DNAI, thus simplifying the information exchanged among all parties (the VPLMN DNAI in the EDI to the HPLMN requires the home MNO to know the VPLMN DNAI, and then the HPLMN shares these VPLMN DNAIs with the service providers (SPs) it has agreements with. The SP provides the EDI related to the VPLMN DNAI and modifies it when the VPLMN DNAI changes). It also reduces the information that the H-SMF needs to provide to the V-SMF.

[0274] Recommendation 4: The VPLMN-specific offloading policy should potentially include the traffic descriptors (FQDN and IP address range) that allow HR-SBO.

[0275] Note: The traffic offloading policies for allowed and disallowed traffic should be mutually exclusive, i.e., a list of allowed traffic descriptors or a list of disallowed traffic descriptors should be sent, rather than both.

[0276] Recommendation 5: In the case where the VPLMN-specific offloading policy includes allowed EC application information as in Recommendation 4 above, the V-SMF selects the UL CL and L-PSA based on the UE location, regardless of the EAS deployment information.

[0277] 2.4 HR-SBO-related information in the SM subscription data in the HPLMN

[0278] As described in Section 2.3 above, the VPLMN-specific offloading policy can include application information for allowing or disallowing HR-SBO, as well as the FQDN and related IP address ranges, as shown in Table 1 above. Such information is not typical PCC information, so it cannot be received from the H-PCF. Instead, this information should be pre-configured in the H-SMF and updated when the relevant SLA changes. In addition, the SM subscription data in the UDM can be used to notify the H-SMF which traffic offloading information should be conveyed to a specific V-SMF.

[0279] The following table contains an example of how the session management subscription data of the existing UE subscription data (i.e., Table 5.2.3.3.1-1 in TS23.502) can be extended to have this information:

[0280]

[0281] Table 3: Additional session management subscription data proposed for the existing UE subscription data (for Table 5.2.3.3.1-1) Each offloading identifier identifies a service consisting of the FQDN list and IP address range list defined in Table 1 above. This list can be pre-configured in the H-SMF and updated as needed.

[0282] Another advantage is that the H-SMF can also apply the offload identifier as a label to the list of HR-SBO related information to be sent to the V-PLMN. If a given V-SMF has received a traffic offloading policy for certain offload identifiers, this can be indicated to the H-SMF in any subsequent request for another HR-PDU session from the same V-SMF. Therefore, it is sufficient for the H-SMF to send the offload identifier instead of resending the entire information again. In this way, the amount of information exchanged between the HPLMN and the VPLMN can be reduced. This is shown in the detailed process of HR-PDU session establishment using the UDM and offload identifiers as described below: Figure 6 in the detailed process of HR-PDU session establishment using the UDM and offload identifiers:

[0283] 1. The UE sends a PDU session establishment request to the V-SMF selected by the AMF.

[0284] 2. The V-SMF selects a UPF in the VPLMN (which can be based on policies obtained from the V-PCR) and sends an Nsmf_PDUSession_Create request to the H-SMF, where it sends a support and authorization request for HR-SBO and provides the V-EASDF address to the H-SMF. The V-SMF also sends the offload ID of the offload information previously received from the H-SMF (if any), tagged with a timestamp regarding when the offload ID was received).

[0285] 3. The SMF uses Nudm_SDM_Get(SUPI, session management subscription data, the selected DNN, the S-NSSAI of the HPLMN, the serving PLMNID, [NID]) to request session management subscription data and uses Nudm_SDM_Subscribe to subscribe to be notified when this subscription data is modified.

[0286] 4. The UDM responds with the session management subscription data. This data includes VPLMN-specific traffic offloading information, as shown in Table 4.

[0287] 5. The H-SMF checks the offload IDs received in the VPLMN-related offload information, and it can generate further offload IDs based on the offload IDs received from the UDM and the VPLMN ID. These offload IDs can be used to identify the EAS IP address range for the EC service in a geographical area, such as the MCC of the VPLMN, as shown in Table 2. Then, the H-SMF compares the offload IDs received from the UDM with the offload IDs received from the V-SMF. For certain offload IDs received from the UDM-related information, it also checks whether the configuration information has changed based on the received timestamp.

[0288] 6. The H-SMF sends an Nsmf_PDUSession_Create response to the H-SMF. In this process, it sends the VPLMN-specific offloading policy (including the relevant offloading ID) corresponding to the offloading ID received from the UDM, in addition to those policies for the offloading ID received from the V-SMF, unless there has been an update during this period.

[0289] 7. The V-SMF sends a PDU session establishment response to the UE.

[0290] Recommendation 6: The IP ranges and FQDNs in the service-specific offloading policies (if available) can be configured in the H-SMF, and the VPLMN-specific policies to be used can be included in the SM subscription data in the UDM as offloading identifiers.

[0291] 3 Recommendations

[0292] It is recommended that the above recommendations should be considered in the specification work for the HR-SBO scenario.

[0293] Abbreviation:

[0294] At least some of the following abbreviations can be used in this disclosure. If there are inconsistencies between the abbreviations, the above usage should be preferred. If listed multiple times below, the first listing should be preferred over any subsequent listings.

[0295] ● 3GPP Third Generation Partnership Project

[0296] ● 5G Fifth Generation

[0297] ● 5GC Fifth Generation Core

[0298] ● 5GS Fifth Generation System

[0299] ● AF Application Function

[0300] ● AMF Access and Mobility Management Function

[0301] ● AN Access Network

[0302] ● ASIC Application Specific Integrated Circuit

[0303] ● AUSF Authentication Server Function

[0304] ● CPU Central Processing Unit

[0305] ● DCI Downlink Control Information

[0306] ● DN Data Network

[0307] ● DSP Digital Signal Processor

[0308] ● Edge Application Server (EAS)

[0309] ● Edge Computing (EC)

[0310] ● EAS Deployment Information (EDI)

[0311] ● DNS Extension (EDNS)

[0312] ● Edge Hosting Environment (EHE)

[0313] ● Enhanced or Evolved Node B (eNB)

[0314] ● Evolved Packet Core (EPC)

[0315] ● Evolved Universal Terrestrial Radio Access (E-UTRA)

[0316] ● Field Programmable Gate Array (FPGA)

[0317] ● Fully Qualified Domain Name (FQDN)

[0318] ● New Radio Base Station (gNB)

[0319] ● Home Public Land Mobile Network (HPLMN)

[0320] ● Home Routing Session Steering (HR-SBO)

[0321] ● Internet Protocol (IP)

[0322] ● Local Steering (LBO)

[0323] ● Long Term Evolution (LTE)

[0324] ● Machine Type Communication (MTC)

[0325] ● Network Exposure Function (NEF)

[0326] ● Network Function (NF)

[0327] ● Non-Public Network (NPN)

[0328] ● New Radio (NR)

[0329] ● Network Function Repository Function (NRF)

[0330] ● Network Slice Selection Function (NSSF)

[0331] ● Over-the-Top (OTT)

[0332] ● Personal Computer (PC)

[0333] ● Policy Control Function (PCF)

[0334] ●PDU Packet Data Unit

[0335] ●RAM Random Access Memory

[0336] ●RAN Radio Access Network

[0337] ●ROM Read Only Memory

[0338] ●RP Reception Point

[0339] ●RRH Remote Radio Head

[0340] ●RTT Round Trip Time

[0341] ●SM Session Management

[0342] ●SMF Session Management Function

[0343] ●UDM Unified Data Management

[0344] ●UE User Equipment

[0345] ●UPF User Plane Function

[0346] ●VPLMN Visited Public Land Mobile Network

Claims

1. A method for transmitting policy information between a first network and a home network of a user equipment (UE) accessing an edge-hosted environment (EHE) in the first network, the method being implemented in a first session management function (SMF) of the first network, the method comprising: sending, by the first SMF in the first network, a request for a packet data unit (PDU) session establishment for the UE to a second SMF in the home network, the request indicating that the first SMF requests authorization for a home routed session offload (HR-SBO) for the PDU session; and receiving, from the second SMF, a message indicating a response, the response including one or more offload identifiers (IDs), each of the one or more offload IDs identifying one or more first-network-specific offload policies for edge computing (EC) services to be applied at the first network.

2. The method according to claim 1, wherein The message indicating the response further includes: at least one of the one or more first-network-specific offload policies identified by at least one of the one or more offload IDs.

3. The method according to claim 1, wherein The request for the PDU session establishment includes one or more previously-provisioned offload IDs, the one or more previously-provisioned offload IDs identifying one or more previously-provisioned first-network-specific offload policies from the home network at the first network.

4. The method according to claim 3, wherein, Each of the one or more previously-provisioned offload IDs is marked with a timestamp indicating when the one or more previously-provisioned first-network-specific offload policies were provisioned.

5. The method according to any one of claims 1-4, wherein, The message indicating the response further includes: the one or more previously-provisioned offload IDs and the corresponding updated first-network-specific offload policies.

6. The method according to claim 5, wherein, The method further includes: replacing the one or more previously-provisioned first-network-specific offload policies with the corresponding updated first-network-specific offload policies.

7. The method according to any one of claims 1 to 3, wherein The one or more offload IDs in the message correspond to at least one of the following: - one or more subscription offload IDs obtained from subscription data for the UE, and - one or more offload IDs generated based on the one or more previously-provisioned offload IDs and the one or more subscription offload IDs included in the request for the PDU session establishment.

8. The method according to claim 2, wherein The method further includes: storing the one or more received first-network-specific offload policies identified by the one or more offload IDs.

9. The method according to any one of claims 1 to 8, wherein For allowed edge computing services, the first-network-specific offload policy includes at least one of the following: - one or more fully qualified domain names (FQDNs); and - a range of Internet protocol (IP) addresses.

10. The method according to any one of claims 1 to 8, wherein, For non-allowed edge computing services, the first-network-specific offload policy includes at least one of the following: - one or more fully qualified domain names (FQDNs); and - a range of Internet protocol (IP) addresses.

11. The method according to any one of claims 1 to 10, wherein The method further includes: configuring a user plane function having an uplink classifier branch point UL CL / BP with the first network-specific offloading policy and / or the updated offloading policy.

12. The method according to any one of claims 1 to 11, wherein The first network is a visited public land mobile network VPLMN, the first SMF is a visited SMF, i.e., V-SMF, and the second SMF is a home SMF, i.e., H-SMF.

13. A method for transmitting policy information between a first network and a home network of a user equipment UE accessing an edge hosting environment EHE in the first network, the method being implemented in a second session management function SMF in the home network, the method comprising: Receiving, from a first SMF in the first network, a request for PDU session establishment, which indicates that the first SMF requests authorization for home routed session offloading HR-SBO of the PDU session; Obtaining first network-specific service offloading information from a third network function, including: ■ one or more offloading identifiers IDs subscribed to for policies for one or more edge computing EC services allowed for HR-SBO, and ■ one or more offloading IDs subscribed to for policies for one or more edge computing EC services not allowed for HR-SBO, and Sending a message indicating a response to the first SMF, the response including one or more offloading IDs, wherein the one or more offloading IDs are based on the one or more subscribed offloading IDs to be applied by the first network.

14. The method according to claim 13, wherein, The policy corresponds to at least one of a destination IP range and a list of fully qualified domain names FQDNs.

15. The method according to claim 13, wherein, The one or more offloading IDs correspond to the one or more subscribed offloading IDs.

16. The method according to claim 13, wherein, The one or more offloading identifiers are generated based on the one or more subscribed offloading identifiers and an identifier of the first network.

17. The method according to any one of claims 13 to 16, wherein, The method further includes: retrieving a policy for each of the one or more offloading identifiers from an internal configuration of the second SMF or from a policy server in the home network.

18. The method according to any one of claims 13-17, wherein, The message indicating the response further includes: an offloading policy retrieved for each of the one or more offloading identifiers.

19. The method according to claim 13, wherein The request for the PDU session establishment includes: one or more previously-provisioned offloading IDs identifying one or more previously-provisioned offloading policies at the first SMF.

20. The method according to claim 19, wherein, Each of the one or more previously-provisioned offloading IDs is marked with a timestamp indicating when the identified offloading policy was provisioned.

21. The method according to any one of claims 19 - 20, wherein, The method further includes: determining whether a policy associated with the one or more previously-provisioned offloading IDs needs to be updated at the first SMF, and in response to determining that the policy for the one or more previously-provisioned offloading IDs needs to be updated, including the updated policy in the message indicating the response to the first SMF.

22. A network node adapted to implement the method according to any one of claims 1 to 21.

23. A network node includes one or more processors and a memory, the memory including instructions that, when executed by the one or more processors, configure the network node to implement the method according to any one of claims 1 to 21.

24. A non-transitory computer-readable storage medium includes executable instructions that, when executed by a processor, cause the processor to implement the method according to any one of claims 1 to 21.

Images