Method and apparatus for communicating traffic load policies to a VPLMN for home routing session breakout

Abstract

[0006] A method and apparatus are provided 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. One method, implemented in a first session management function (SMF) in the first network (VPLMN), includes sending a request for PDU session establishment for the UE to a second SMF in the home network, indicating that the first SMF is requesting authorization for a home routing session breakout (HR-SBO) for a packet data unit session, and receiving a response message from the second SMF including one or more offload identifiers (IDs), each of which identifies one or more offload policies for edge computing (EC) services to be applied in the first network. Transmitting the offload policies themselves is not always required; only the IDs are used.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of Provisional Patent Application No. 63 / 434536, filed December 22, 2022, the entire disclosure of which is incorporated herein by reference.

[0002] The present disclosure relates to wireless communication systems, and more particularly to wireless communication systems that support roaming policies for home routing and local breakout. [Background technology]

[0003] In the 5G wireless network of FIG. 2, various network functions may exist, including but not limited to: The Session Management Function (SMF) is responsible for establishing, modifying and releasing sessions, including selecting and controlling UPF entities, maintaining the topology of the involved PSA UPFs, and establishing and releasing tunnels between the AN and the UPF and between UPFs. The SMF also configures traffic forwarding in the UPF. The SMF interacts with the UPF via the N4 reference point using PFCP procedures. UPF (User Plane Function) handling user data traffic. Among other things, the UPF provides the external PDU session point (PDU Session Anchor (PSA)) for interconnection to the data network and performs packet routing and forwarding (e.g. support for Uplink Classifier (UL CL) for routing traffic flows to instances of the data network, support for branching points to support multi-homed PDU sessions). PCF (Policy Control Function) supports a unified policy framework to govern network behavior. In particular, with respect to 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, which enforces policy and charging decisions according to the provisioned PCC rules. The NEF (Network Exposure Function) supports various functions and, in particular, in this IvD context, acts as an entry point into the operator's network, so that external AFs (content providers) interact with the 3GPP core network through the NEF. An AF (Application Function) may send a request to influence SMF routing decisions regarding PDU session traffic. The AF request may influence UPF (re)selection and allow user traffic to be routed to a local access to the data network (identified by the DNAI). The AF may communicate with the PCF directly within the SBA domain or indirectly through the NEF, i.e., it has an API to the NEF that conveys AF communications to the PCF. UDM (Unified Data Management): A front-end for user subscription data stored in UDRs. The UDM uses subscription data that may be stored in UDRs to perform application logic such as access authorization, registration management, and reachability of terminating events such as SMS.

[0004] As stated in TS 23.501 v.17.4.0, clause 5.13, edge computing allows operator and third-party services to be hosted close to the UE's access point to achieve efficient service delivery by reducing end-to-end latency and load on the transport network. The 5G core network selects a UPF close to the UE and performs traffic steering from the UPF to the local data network via the N6 interface.

[0005] Several enablers have been specified that support edge computing, either alone or in combination (TS 23.501 v.17.4.0 clause 5.13). Among the enablers are: User plane (re)selection: The 5G core network (re)selects a UPF for routing user traffic to the local data network as described in clause 6.3.3 of TS 23.501 v.17.4.0. Local routing and traffic steering: The 5G core network selects which traffic is routed to applications within the local data network. o This includes the use of a single PDU session with multiple PDU session anchors (UL CL / IPv6 multihoming) as described in TS 23.501 v.17.4.0, clause 5.6.4. Session and service continuity to enable UE and application mobility as described in TS 23.501 v.17.4.0, clause 5.6.9. An application function (AF) can influence UPF (re)selection and traffic routing via the PCF or NEF.

[0006] Edge Computing (EC) enables operator and third-party services to be hosted close to the UE's access point of connection to achieve efficient service delivery through reduced end-to-end latency and load on the transport network.

[0007] Figure 3A shows a 5GS architecture for a non-roaming scenario supporting edge computing with UL CL / BP, and Figure 3B shows a 5GS architecture for a non-roaming scenario supporting edge computing without UL CL / BP.

[0008] To support the Edge Application Server (EAS) discovery procedure, TS 23.548 introduces an Edge Application Server Discovery Function (EASDF) that performs DNS message handling according to instructions from the SMF, including (among other things): - Receive DNS message handling rules from the SMF. - Exchanging DNS messages from the UE. - Forwarding DNS messages to the central DNS (C-DNS) or local DNS (L-DNS) for DNS queries. - Add the Extended DNS (EDNS) Client Subnet (ECS) option (specified in RFC 7871) to DNS queries for FQDNs. - Communicate EASDF related information to the SMF. - Terminate DNS security when DNS over TLS (DoT), DNS over HTTPS (DoH), or DNS over DTLS is used.

[0009] The EASDF has user plane connectivity with the PSA UPF via N6 for sending DNS signaling exchanged with the UE. If a UE application wants to discover / access the EAS by using the mechanisms specified in TS 23.548, the DNS queries generated by the UE must be sent to the EASDF as the DNS resolver instructed by the SMF.

[0010] Currently, several challenges exist. More specifically, neither the Release 16 Edge Computing (EC) features specified in 3GPP TS 23.501 nor the Release 17 extensions specified in 3GPP TS 23.548 v17.4.0 provide functionality for accessing the Edge Hosting Environment (EHE) in a VPLMN when roaming. Therefore, this has been specified as a key issue to be resolved in the Release 18 study (Key Issue #1 in 3GPP TS 23.700-48 v2.0.0). There are two alternative scenarios to consider: a UE accessing the Edge Hosting Environment (EHE) in a VPLMN via a Local Breakout (LBO) PDU session; and a UE accessing the EHE in a VPLMN via a PDU session established as a Home Routing (HR).

[0011] A UE roaming scenario accessing the EHE in an HR PDU session, referred to as a home routing session breakout (HR-SBO) scenario, is depicted in FIG. 4, which shows a 5G network architecture for home routing session breakout in a visited PLMN. This architecture includes a home PLMN and a visited PLMN. NFs in the home PLMN may be referred to herein using the prefix "H-", while NFs in the visited PLMN may be referred to herein using the prefix "V-". In this architecture, the visited PLMN includes the NEF 300, the NRF 302, the V-PCF 324, the AMF 322 (denoted here as an AMF in the visited network, similar to the AMF 200 in FIG. 2), the V-SMF 328, the V-EASDF 316, the UPF uplink classifier branch point (UL CL / BP) 330-1, the UPF local protocol data unit session anchor (PSA) 330-2, and the AF 326. The UPF local PSA 330-2 is connected to the DN, which in this example includes the EAS 314. The home PLMN includes the H-UPF 306, which is connected to the H-EASDF 318, the H-PCF 312, the UDM 308, the H-SMF 310, the H-DNS 320, and the central DN 316.

[0012] At the time of filing this application, standardization work for 3GPP Release 18 has begun, and 3GPP Change Request S2-2211366 (Major Issue #1 of 3GPP TS 23.700-48 v2.0.0) to TS 23.548 related to the roaming HR-SBO scenario has been approved for incorporation into TS 23.548 during SA2 Meeting 154. This request proposes a procedure for the HR-SBO scenario as shown in Figure 5.

[0013] The following further explains the steps of FIG. 5 as currently approved to standard TS 23.548.

[0014] Step 1: During the registration procedure, the AMF receives an HR-SBO authorization indication per DNN / S-NSSAI from the UDM in step 14b of the procedure in clause 4.2.2.2.2 of TS 23.502 V. 17.4.0.

[0015] Step 2: During the PDU session establishment procedure for home routing roaming as per clause 4.3.2.2.2 of TS 23.502 V. 17.4.0, if the AMF322 receives an HR-SBO authorization indication for the requested DNN / S-NSSAI in step 1, the AMF322 selects a V-SMF328 that supports HR-SBO. Editor's note: It is for further consideration (FFS) whether the AMF 322 will send an indication to the V-SMF 328 that the requested session is allowed as an HR-SBO PDU session. If agreed, this indication can be used by the V-SMF 328 to determine whether to request an HR-SBO PDU session from the H-SMF 310. Editor's note: It is for further study (FFS) when V-SMF 328 selects V-EASDF 316. In other words, V-SMF 328 selects V-EASDF 316 either 1) before sending an Nsmf_PDUSession_Create request for the HR-SBO PDU session to H-SMF 310, or 2) after receiving an Nsmf_PDUSession_Create response from H-SMF 310.

[0016] The V-SMF 328 sends a request to establish a PDU session supporting HR-SBO 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 offload policy and the DNS server address of the HPLMN (if available in the HPLMN based on the SLA between the HPLMN and the VPLMN). Editor's note: It is FFS if the SM subscription data contains 1) an HR-SBO authorization instruction or 2) HR-SBO authorization information including a VPLMN-specific offload policy. If only an HR-SBO authorization instruction is added, the H-SMF 310 retrieves the VPLMN-specific offload policy from the H-PCF 312 if it is available in the H-PCF 312 based on the SLA between the HPLMN and the VPLMN. Editor's note: Detailed information on VPLMN-specific offload policies (e.g., FQDN ranges, IP ranges, AMBR for the local part of the DN, or charging policies) is FFS. NOTE 2: VPLMN-specific offloading policies may be pre-configured in the HPLMN based on a service level agreement between the VPLMN and the HPLMN.

[0017] The H-SMF 310 also constructs a protocol configuration option (PCO) with the V-EASDF address set in the DNS server address field, and sends the PCO to the V-SMF 328 .

[0018] Step 3: The V-SMF 328 configures the V-EASDF 316 with DNS handling rules using the optional VPLMN-specific offload policy and the DNS server address of the HPLMN, if received from the H-SMF 310 in step 2.

[0019] Editor's Note: How the EAS (re)discovery procedure for the HR-SBO roaming scenario will be implemented is for further study (FFS). As described below, embodiments address editor's notes stating issues for further consideration. To understand the solution presented herein, it is important to understand how the current state of the art addresses subscription data in UDM 308.

[0020] TS 23.502 V.17.4.0 lists the UE subscription data attributes, as reproduced in Table 1 below. TIFF2026501258000002.tif248170TIFF2026501258000003.tif255168TIFF2026501258000004.tif255170TIFF2026501258000005.tif255167 TIFF2026501258000006.tif255167TIFF2026501258000007.tif247170TIFF2026501258000008.tif127170TIFF2026501258000009.tif186170

[0021] 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 subkeys may be used to further identify the corresponding data, as specified in TS 23.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 optionally the network identifier (NID) are specified as subkeys. Summary of the Invention

[0022] Certain aspects of the present disclosure and its embodiments may provide solutions to the above-mentioned problems or other problems.

[0023] This disclosure proposes a solution for conveying offload information (policies) to the VPLMN in an HR-SBO scenario, where the offload policies are pre-configured in the H-SMF and indexed to enable the VPLMN-specific offload policy to be derived based on the offload ID received from the UDM, which points to the corresponding configuration in the H-SMF.

[0024] The H-SMF applies the offload ID as a label to the offload policy sent to the V-SMF, and based on the offload ID, specific offload information can be resent to the V-SMF only when needed, e.g., if the information has changed.

[0025] According to some embodiments, there is provided a method implemented by a first Session Management Function (SMF), e.g., a Visited SMF in the Visited PLMN, for conveying policy information between a first network (Visited PLMN) and a home network (Home PLMN) of a user equipment (UE) accessing an Edge Hosting Environment (EHE) in the first network (e.g., Visited PLMN). The method includes a first SMF (visited SMF) sending a request for packet data unit (PDU) session establishment for the UE to a second SMF (home SMF) in a home network, the request indicating that the first SMF is requesting authorization for a home routing session breakout (HR-SBO) for the PDU session; and receiving, by the first SMF (visited SMF), a message from the second SMF (home SMF) indicating a response including one or more offload identifiers (IDs), each ID of the one or more offload IDs identifying one or more first-network-specific offload policies for edge computing (EC) services to be applied in the first network.

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

[0027] For example, the request for PDU session establishment includes one or more previously provisioned offload IDs that identify one or more previously provisioned first-network-specific offload policies from the home network to the first network, which may include instructing the home network which offload policies are available in the first network. The one or more previously provisioned offload IDs may be tagged with a timestamp that indicates when the one or more previously provisioned first-network-specific offload policies were provisioned in the first network. For example, if the offload policy associated with the previously provisioned offload ID included in the request for the PDU session is an update, the message indicating the response further includes one or more previously provisioned offload IDs with the corresponding updated first-network-specific offload policies. If an updated or new offload policy is received, the first SMF replaces the one or more previously provisioned first-network-specific offload policies with the updated first-network-specific offload policies corresponding to the one or more previously provisioned offload IDs. The first SMF also stores any new receive policies along with the corresponding offload identifiers.

[0028] According to some examples, the one or more offload IDs in the message correspond to one or more subscription offload IDs obtained from the UE's subscription data and / or one or more generated offload IDs generated based on the one or more subscription offload IDs and one or more previously provisioned offload IDs included in the request for PDU session establishment. In one example, the first network-specific offload policy or the updated first network-specific policy includes one or more fully qualified domain names (FQDNs) and / or internet protocol (IP) address ranges for permitted edge computing services and / or unauthorized edge computing services.

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

[0030] Similarly, there is provided 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, the method being implemented in a second session management function (SMF) (H-SMF) in the home network. The method includes receiving, by a second SMF (H-SMF), from a first SMF (V SMF) in a first network (VPLMN), a request for PDU session establishment, indicating that the first SMF is requesting authorization for Home Routing Session Breakout (HR-SBO) of the PDU session; obtaining, from a third network function, first-network-specific traffic offload information including one or more subscribed offload identifiers (IDs) of policies of one or more Edge Computing (EC) services that are allowed for HR-SBO and / or one or more subscribed offload IDs of policies of one or more Edge Computing (EC) services that are not allowed for HR-SBO; and finally, sending, to the first SMF in the first network (visited PLMN), a message indicating a response including the one or more offload IDs, where the one or more offload IDs are based on the one or more subscribed offload IDs to be applied by the first network.

[0031] In one example, the policy (same as the first network-specific offload policy previously referenced) corresponds to at least one of a list of fully qualified domain names (FQDNs) and destination IP ranges. The one or more offload IDs may correspond directly to the one or more subscribed offload IDs or may be generated based on the one or more subscribed offload identifiers and an identifier of the first network. In one example, the method further includes a step of retrieving, by the second SMF (H-SMF), a policy for each of the one or more offload identifiers from an internal configuration of the second SMF or from a policy server in the home network, and if retrieved, the second SMF (H-SMF) includes the policy in a message to the first SMF (V-SMF), the message indicating a response to the request for PDU session establishment.

[0032] The request for PDU session establishment may also include one or more previously provisioned offload IDs that identify any previously provisioned offload policy or policies in the first SMF, which may be tagged with a timestamp indicating when the identified offload policy or policies were provisioned. If the second SMF determines that policies associated with one or more previously provisioned offload IDs need to be updated in the first SMF, the second SMF sends the updated policies to the first SMF in a response-indicating message so that the first SMF can update the policies for the offload IDs.

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

[0034] According to another embodiment, there is provided a network node or server comprising one or more processors and a memory containing instructions that, when executed by the one or more processors, configure the network node or server to perform a method of any one of the embodiments described herein.

[0035] According to another embodiment, a non-transitory computer-readable storage medium is provided that includes executable instructions that, when executed by a processor, cause the processor to perform any one of the methods of the embodiments described herein.

[0036] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure. [Brief explanation of the drawings]

[0037] [Figure 1] FIG. 1 illustrates an example of a wireless communication system in which embodiments of the present disclosure may be implemented. [Figure 2] FIG. 1 illustrates an example of a core network of a wireless communication system in which embodiments of the present disclosure may be implemented. [Figure 3A] FIG. 10 illustrates another example of a core network of a wireless communication system, showing a 5G system (5GS) that provides access to an EAS using an UL CL / BP for a non-roaming scenario. [Figure 3B] FIG. 10 illustrates another example of a core network of a wireless communication system, showing a 5G system (5GS) that provides access to EAS without UL CL / BP for a non-roaming scenario. [Figure 4] FIG. 1 illustrates an example of a 5G architecture for home routing session breakout in a visited PLMN. [Figure 5] A diagram showing the procedure of a PDU session supporting HR-SBO in a VPLMN. [Figure 6] A diagram illustrating a detailed procedure for establishing a PDU session according to an embodiment of the present disclosure. [Figure 6A] 10 is a flowchart of a method performed by a first session management function according to an embodiment of the present disclosure. [Figure 6B] 10 is a flowchart of a method performed by a second session management function according to an embodiment of the present disclosure. [Figure 7]FIG. 1 is a schematic block diagram of an exemplary embodiment of a network node. [Figure 8] FIG. 1 is a schematic block diagram of an exemplary embodiment of a network node. [Figure 9] FIG. 1 is a schematic block diagram of an exemplary embodiment of a network node. DETAILED DESCRIPTION OF THE INVENTION

[0038] In general, all terms used herein should be interpreted according to their ordinary meaning in the relevant technical field unless a different meaning is clearly provided and / or implied from the context in which it is used. All references to elements, devices, components, means, steps, etc. should be openly interpreted as referring to at least one instance of the element, device, component, means, step, etc., unless expressly stated otherwise. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or if it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Similarly, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the included embodiments will become apparent from the following description.

[0039] Although the embodiments are described using a 5G core network, it will be apparent to one skilled in the art that any core network that supports edge computing, including 4G, 6G and beyond, can implement these embodiments.

[0040] Some of the embodiments discussed herein will now be more fully described with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to only the embodiments described herein; rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0041] Wireless Node: As used herein, a "wireless node" is either a wireless access node or a wireless communication device.

[0042] Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to transmit and / or receive signals wirelessly. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a 3rd Generation Partnership Project (3GPP) fifth-generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP long-term evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a Home eNB, etc.), a relay node, a network node that implements part of the functionality 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 functionality of some other type of radio access node.

[0043] Core Network Node: As used herein, a "core network node" is any type of node or server in a core network. Some examples of core network nodes include nodes implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Publication Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), etc. A network function (NF) may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, e.g., a cloud infrastructure. One or more network functions may be implemented or hosted on the same node / server, or may be distributed across multiple nodes / servers.

[0044] Communications Device: As used herein, a "communications device" is any type of device that has access to an access network. Some examples of communications devices include, but are not limited to, a mobile phone, a smartphone, a sensor device, a meter, a vehicle, a home appliance, a medical device, a media player, a camera, or any type of consumer electronic device, such as, but not limited to, a television, a radio, a lighting device, a tablet computer, a laptop, or a personal computer (PC). A communications device may be a portable, handheld, computer-integrated, or vehicle-mounted mobile device that is capable of communicating voice and / or data via a wireless or wired connection.

[0045] Wireless Communication Device: One type of communication device is a wireless communication device, which can be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of wireless communication devices include, but are not limited to, user equipment devices (UEs) in 3GPP networks, machine-type communication (MTC) devices, and Internet of Things (IoT) devices. Such wireless communication devices can be or be incorporated into mobile phones, smartphones, sensor devices, meters, vehicles, home appliances, medical devices, media players, cameras, or any type of consumer electronics device, such as, but not limited to, a television, radio, lighting device, tablet computer, laptop, or PC. Wireless communication devices can be portable, handheld, computer-based, or vehicle-mounted mobile devices enabled to communicate voice and / or data over a wireless connection.

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

[0047] It should be noted that the description provided herein focuses on 3GPP cellular communication systems, and therefore 3GPP terminology or terminology similar to 3GPP terminology is often used, however, the concepts disclosed herein are not limited to 3GPP systems.

[0048] In the description herein, reference may be made to the term "cell", however, it is important to note that, particularly with regard to 5G NR concepts, a beam may be used in place of a cell, and therefore the concepts described herein are equally applicable to both cells and beams.

[0049] FIG. 1 illustrates 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 5GS, and control corresponding (macro) cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally collectively referred to herein as base stations 102 and individually referred to as base stations 102. Similarly, the (macro) cells 104-1 and 104-2 are generally collectively referred to herein as (macro) cells 104 and individually referred to as (macro) cells 104. The RAN may also include several 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 remote radio heads (RRHs), etc. Notably, although not shown, one or more of the small cells 108-1 to 108-4 may alternatively be provided by the base station 102. The low-power nodes 106-1 to 106-4 are generally collectively referred to herein as low-power nodes 106 and individually referred to as low-power nodes 106. Similarly, the small cells 108-1 to 108-4 are generally collectively referred to herein as small cells 108 and individually referred to as small cells 108. The cellular communication system 100 also includes a core network 110, referred to as 5GC in a 5G system (5GS). The base stations 102 (and optionally, the low-power nodes 106) are connected to the core network 110.

[0050] The base station 102 and the low power node 106 serve wireless communication devices 112-1 through 112-5 within corresponding cells 104 and 108. The wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication devices 112. In the following description, the wireless communication devices 112 are often UEs, although the disclosure is not limited thereto.

[0051] 2 illustrates a wireless communication system represented as a 5G network architecture consisting of core network functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 2 can be considered one particular implementation of the cellular communication system 100 of Figure 1. A network function (NF) may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, e.g., a cloud infrastructure.

[0052] From the access side, the 5G network architecture shown in Figure 2 includes multiple UEs 112 connected to either a RAN 102 or an access network (AN), and an AMF 200. Typically, the RAN 102 includes a base station, such as an eNB or gNB. From the core network side, the 5G NF shown in Figure 2 includes an NSSF 202, an AUSF 204, a UDM 206, an AMF 200, an SMF 208, a PCF 210, and an Application Function (AF) 212.

[0053] Reference point representations of 5G network architecture are used to develop detailed call flows in the standardization. The N1 reference point is defined to carry signaling between the UE 112 and the AMF 200. Reference points for connecting 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 configured using control signals generated by the SMF 208 and the UPF 214 can report its status to the SMF 208. N9 is a reference point for connecting between different UPFs 214, and N14 is a reference point for connecting between different AMFs 200. N15 and N7 are defined because the PCF 210 applies policies to the AMF 200 and the SMF 208, respectively. N12 is required for the AMF 200 to perform authentication of the UE 112. N8 and N10 are defined because subscription data of the UE 112 is required for the AMF 200 and the SMF 208.

[0054] The 5GC network aims to separate the UP and CP. The UP carries user traffic, and the CP carries signaling within the network. In Figure 2, the UPF 214 is located in the UP, and all other NFs, namely, the AMF 200, the SMF 208, the Policy Control Function (PCF) 210, the AF 212, the Network Slice Selection Function (NSSF) 202, the Authentication Server Function (AUSF) 204, and the UDM 206, are located in the CP. Separating the UP and CP ensures that each plane resource is scaled independently. Separating the UP and CP also allows the UPF to be distributed and deployed separately from the CP function. In this architecture, the UPF can be deployed very close to the UE to reduce the round-trip time (RTT) between the UE and the data network for some applications requiring low latency.

[0055] The core 5G network architecture is constructed from modularized functions. For example, the AMF 200 and 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 AUSF 204, can be separated as shown in Figure 2. The modularized functional design allows the 5GC network to flexibly support various services.

[0056] Each NF interacts directly with another NF. It is possible to use intermediate functions to route messages from one NF to another. In a CP, a set of interactions between two NFs is specified as a service, and therefore its reusability is possible. This service allows for modularity support. A UP supports interactions, such as forwarding operations, between different UPFs.

[0057] 3GPP TR 23.700-48 lists two main scenarios in section 5.1.2: 2.1) The HPLMN has knowledge of EAS deployment information in the VPLMN for a particular service. The HPLMN triggers EAS discovery and local traffic routing in the VPLMN. 2.2) The HPLMN has no knowledge of the EAS deployment information in the VPLMN. The VPLMN triggers EAS discovery and local traffic routing in the VPLMN.

[0058] The most challenging scenario from the perspective of transmitting traffic offload information, also known as VPLMN-specific offload policy, is scenario 2.1. The main problem with this scenario is that the HPLMN is aware of EDI (Edge Deployment Information as described in TS 23.548 and incorporated herein by reference), and therefore assumes that the HPLMN has a business relationship with an EC (Edge Computing) server provider.

[0059] In various embodiments disclosed herein, the UDM may be used to indicate to the H-SMF the appropriate reference for selecting the required VPLMN-specific offload policy.

[0060] The amount of information exchanged between the HPLMN and the VPLMN may be reduced.

[0061] According to the embodiments presented herein, the following offload information needs to be conveyed to the VPLMN for Home Routing Session Breakout (HR-SBO): In this case, the session breakout uses an uplink classifier (as in TS 23.501) or an IPv6 branch point: 1. Authorization from HPLMN for HR-SBO 2. Policies related to PDU sessions, such as AMBR 3. Information on which the VPLMN may perform UL CL / BP and local PSA selection. 4. Other possible service SLA related information.

[0062] Regarding point 3 above, the following alternatives are possible for the information conveyed to support session breakout: 1. All required information (including EDI as specified in TS 23.548) is communicated. This information is to support a full-fledged EAS rediscovery procedure as in TS 23.548. This means that for each PDU session, a large amount of information, such as EDI, is communicated, which is (usually) not PDU session-related information. Providing the HPLMN with EDI related to the VPLMN topology assumes that the SP has a service agreement 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 afterwards can the SP provide the HPLMN with EDI related to the VPLMN DNAI. The same sequence of communications is required when the VPLMN DNAI is changed. 2. The offloading policy information includes the EC FQDN and (optionally) IP range to be configured for the UL CL / BP. In this case, the V-SMF selects the UL CL or BP and 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.

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

[0064] In the proposed embodiment shown in Table 2, the various rows in the table tagged with Offload_ID_A, B, etc. correspond to the traffic offload policy of a particular EC service, so that the FQDN can be used to provision a V-EASDF in case of session breakout via DNS-based EAS discovery, while the list of IP ranges is the list of EAS IP ranges that are authorized to be used for a given service in the UL CL / BP. Note that this service-related offload information A, B, etc. is independent of the VPLMN, except that some EAS IP ranges are never configured for a particular VPLMN (assuming that a UL CL configuration update for a given IP address range occurs when the DNS response contains both the ECS and EAS IP addresses belonging to that IP address range).

[0065] In one example, each row in Table 2 corresponds to a country-specific IP address range, and the keys A1, A2, B1, B2, etc. identify both the service and the geographic region (e.g., MCC) associated with those IP ranges. This is shown in Table 3 below. Note that the offload IDs A1, A2, B1, B2, etc. may be derived based on the service's offload ID and VPLMN ID, respectively. TIFF2026501258000011.tif96170

[0066] The information structure as proposed in Tables 2 and 3 does not require the VPLMN DNAI, so this approach simplifies the information exchanged between all parties (the VPLMN DNAI in the EDI to the HPLMN requires that the Home MNO understands the VPLMN DNAI, that the HPLMN shares the VPLMN DNAI with the service provider (SP) with which it has an agreement, and that the SP provides EDI related to the VPLMN DNAI and modifies it if it changes). This approach also reduces the information that the H-SMF needs to provide to the V-SMF.

[0067] The above indicates that a VPLMN-specific offload policy may include traffic descriptors (FQDN and IP address ranges) that are allowed for HR-SBO.

[0068] VPLMN-specific offloading policies may have different configurations depending on which MNO a service provider (SP) has contracted with.

[0069] If agreed between the SP and the VPLMN, EC application information (e.g., EDI) is available within the VPLMN. In this case, the HPLMN may, at a minimum, provide only the HR-SBO authorization indication to the VPLMN. However, it is possible that the HPLMN provides other services for a given UE and PDU session for other non-EC applications. In that case, these applications should not be authorized for SBO to the VPLMN. Therefore, the VPLMN-specific offload policy may include traffic descriptors (e.g., destination IP range, port, FQDN) that are not authorized for HR-SBO.

[0070] Table 4 contains an example of how to extend the session management subscription data based on the existing UE subscription data (i.e., Table 5.2.3.3.1-1 of TS 23.502) as shown in Table 1. This data can be extended with the following information: TIFF2026501258000012.tif90170

[0071] Each offload identifier identifies a service consisting of a list of FQDNs and / or a list of IP address ranges as specified in Table 2 or Table 3 above. Thus, in some embodiments, it is sufficient that the offload identifier is sent by the H-SMF to the V-SMF, rather than the entire information. By sending the offload identifier, the amount of information exchanged between the HPLMN and the VPLMN can be reduced.

[0072] FIG. 6 illustrates a procedure for establishing a PDU session according to an embodiment of the present disclosure.

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

[0074] Step 2: The V-SMF 328 selects a UPF in the VPLMN (which may be based on the policy fetched from the V-PCR) and sends an Nsmf_PDUSession_Create request to the H-SMF 310. The V-SMF 328 sends a support and / or authorization request for the HR-SBO and also provides the V-EASDF 316 address to the H-SMF 310. The V-SMF 328 also sends the offload IDs of the offload information previously received from the H-SMF 310 (if any) and may be tagged with the timestamp of when they were received.

[0075] Step 3: The H-SMF 310 requests session management subscription data using Nudm_SDM_Get(SUPI, Session Management Subscription Data, Selected DNN, S-NSSAI of HPLMN, Serving PLMN ID, [NID]) and subscribes to be notified when this subscription data is modified using Nudm_SDM_Subscribe.

[0076] Step 4: The UDM 308 responds with session management subscription data, including VPLMN-specific traffic offload information, for example, as shown in Table 4 according to an embodiment of the present disclosure.

[0077] Step 5: The H-SMF 310 then checks the offload ID received in the VPLMN-related offload information from the UDM 308, and the H-SMF 310 may generate a further offload ID from the offload ID being received from the UDM 308 and the VPLMN ID indicated in the request from the V-SMF 328. A non-limiting example of how the H-SMF 310 may generate the offload ID includes using an algorithm to derive an Operational Region Identification Code (MCC) from the received VPLMN ID, and then generate the offload identifier from: an offload identifier (which describes the FQDN of the EC service) received from the subscription server (e.g., UDM 308); and MCC derived from VPLMN iD The generated offload identifier then identifies the IP address range in the traffic offload policy of the given EC service that belongs to the geographic region identified by the MCC. The generated offload identifier is consequently derived for each region of a particular country based on the generation algorithm described above. In this way, the same identifier can be provided for different VPLMNs in a particular country. These offload IDs can be used to identify EAS IP address ranges for EC services in a geographic area, such as the MCC of a VPLMN, as shown in Table 2.

[0078] The H-SMF 310 may compare the offload IDs from the subscription and further generated offload IDs with the offload IDs as received from the V-SMF 328. The H-SMF 310 may also check, based on the received timestamp, whether the configuration information (i.e., offload policy) has changed for some of the offload ID-related information received from the UDM 308 or the offload IDs generated by the H-SMF 310.

[0079] Step 6: The H-SMF 310 sends an Nsmf_PDUSession_Create response to the V-SMF 328, which includes the VPLMN-specific offload policy (including the associated offload IDs). The associated offload IDs may include: - an offload policy received from the UDM and / or generated by the H-SMF 310, with a corresponding offload policy (optional), not an offload ID received from the V-SMF 328 if no update to the corresponding policy is required, or - An offload ID received from the UDM 308 and / or generated by the H-SMF 310 with a corresponding offload policy (optional), and an offload ID received from the V-SMF if there has been an update to the corresponding policy in the meantime, and the associated updated policy information. Alternatively, the response includes all offload IDs and corresponding offload policy information that overrides any offload policy in the V-SMF 328 . Alternatively, when no update is needed to the policy of the offload ID provided by the V-SMF, the response may include the offload ID and the associated offload policy information (from subscription and / or creation), or may simply include the offload ID provided by the V-SMF 328 of the unchanged policy already available at the V-SMF 328 to indicate to the V-SMF 328 that the unchanged policy is still valid. It will be clear to those skilled in the art that any combination of adding, updating or deleting offload policies with associated offload IDs from the H-SMF 310 to the V-SMF 328 is supported.

[0080] Step 7: The V-SMF stores any offload policy (if received) and offload ID provided by the H-SMF 310 and sends a PDU session establishment response to the UE.

[0081] Although the procedures described herein are described between a home PLMN and a visited PLMN, and a visited SMF and a home SMF, the embodiment of FIG. 6 may also be implemented between an SMF in a non-public network (NPN) and an SMF in a PLMN.

[0082] 6A is a flow diagram illustrating a method for initiating a PDU session establishment request to a second SMF in a second network, the first SMF being exemplified as a Visited SMF (V-SMF) in a Visited PLMN, and the second SMF being exemplified as a Home SMF (H-SMF) in a HPLMN, but not limited thereto.

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

[0084] In step 620A, the first SMF receives an Nsmf_PDUSession_Create response from the second SMF, the response including one or more offload IDs each identifying a first network-specific offload policy for the home routing session breakout to be applied by the first SMF.

[0085] The response may further include a first network-specific offload policy identified by each of the one or more offload IDs, where the one or more offload IDs correspond to offload IDs from the subscription data or offload IDs generated from these offload IDs.

[0086] If the PDU session establishment request of 610A included one or more previously provisioned offload IDs and, optionally, a timestamp of when the corresponding policy was received or provisioned, the response includes at least one of the following: One or more previously provisioned offload IDs (as included in request step 610A) and corresponding updated offload policies; and One or more first network-specific policies and associated offload identifiers corresponding to the offload identifiers obtained or generated from the subscription data.

[0087] In another example, the first SMF may also receive a response that does not include any specific offload policies and associated offload IDs. If the V-SMF included existing or previously provisioned offload IDs in the request of step 610A, the V-SMF may interpret a response that does not include any updated offload policies for the associated offload IDs as maintaining any existing offload policies and associated offload IDs, i.e., as if the previous offload policies have not yet expired.

[0088] Alternatively, the response may include a previously provisioned offload ID as included in the request without corresponding offload policy information as an acknowledgement by the second SMF that the previously provisioned offload policy is still valid, which the first SMF interprets as meaning that the same policy corresponding to the previously provisioned offload ID should be used.

[0089] The first SMF stores and enforces any received offload policies that have an associated offload identifier.

[0090] The offloading policy information includes the EC FQDN and (optionally) IP ranges to be configured in the UL CL / BP for permitted and / or unauthorized edge computing (EC) services. In this case, the first SMF selects the UL CL or BP and L-PSA based on the UE location without considering the EAS deployment information. In addition, other information that may be conveyed in the response includes the EDI specified in TS 23.548. This information is intended to support a full-scale EAS rediscovery procedure as in TS 23.548. This means conveying a large amount of information, such as EDI, for each PDU session that is (usually) not PDU session-related information. Providing EDI related to the topology of the first network (e.g., VPLMN) 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 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 series of communications is required when the first network DNAI is changed. The first SMF updates and stores the offload IDs and their corresponding offload 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.

[0091] 6B is a flow chart illustrating a method for providing a first network-specific policy to a first SMF in a first network during a PDU session establishment procedure, the method being performed by a second SMF in a second network, where the first SMF is exemplified as a visited SMF in a visited PLMN and the second SMF is exemplified as a home SMF in a HPLMN, but is not limited thereto.

[0092] In step 610B, the method includes 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 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 proceeds by obtaining session management subscription data from a subscription server, such as a UDM. The subscription data includes first-network-specific traffic offload information, including the information in Table 4 above, namely: - an indication of whether the first network is authorized for HR-SBO, either or both of the following: o A list of one or more Edge Computing (EC) service FQDNs and / or one or more offload identifiers for destination IP ranges that are authorized for the HR-SBO, and o One or more offload identifiers for a list of FQDNs of one or more Edge Computing (EC) services and / or destination IP ranges that are not authorized for HR-SBO. The UDM only needs to indicate the offload identifier to the second SMF and does not need to provide the offload policy itself.

[0093] Optionally, in step 625B, the second SMF may generate further offload IDs from 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 an EAS IP address range for EC services in a certain geographical area, such as an MCC of the first network (e.g., VPLMN), as shown in Table 2. An offload policy indexed by the offload identifier (from the subscription or generated) is configured in the second SMF. Alternatively, the second SMF may retrieve an offload policy from a server, such as a storage or policy server, by using the offload identifier as an index to the required offload policy.

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

[0095] In one example, the method further includes receiving, in the request for PDU session establishment, one or more previously provisioned offload identifiers that identify one or more first network-specific offload policies that have been previously provisioned in a first SMF in the first network, each of the one or more previously provisioned offload identifiers optionally being tagged with a timestamp indicating when the identified first network-specific offload policy was provisioned.

[0096] In one example, after receiving one or more previously provisioned offload identifiers in the request for PDU session establishment and in response to receiving session management subscription data with one or more offload identifiers (step 620B), the second SMF may generate further offload identifiers from the offload identifiers and VPLMN IDs received in the session management subscription data. The second SMF then 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 further generated offload identifiers. In this example, the only criterion is a match 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 matched one or more offload identifiers. However, for one or more offload identifiers that did not match, the second SMF also retrieves the corresponding offload policies of the further generated offload identifiers included in the subscription data. The second SMF then includes in a response message to the first SMF the retrieved one or more first network-specific offload policies for each of the associated one or more offload identifiers, i.e., for both the matched and unmatched offload identifiers included in / further generated from the subscription data (if any).

[0097] In another example, after receiving one or more previously provisioned offload identifiers including a timestamp in a request for PDU session establishment, and after session management subscription data has been received together with the one or more offload identifiers (step 620B), and optionally further offload identifiers have been generated based on the session management subscription data and the first network identifier (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 from the one or more offload identifiers received in the session management subscription data and / or the one or more offload identifiers further generated by the second SMF as described above.

[0098] In this other example, if the offload identifiers are the same / match, the second SMF determines whether a timestamp provided with the one or more previously provisioned offload identifiers indicates that the corresponding previously provisioned first network-specific offload policies have expired or need to be updated, and in response to determining that the one or more previously provisioned first network-specific offload policies have expired or need to be updated, the second SMF proceeds by retrieving one or more updated first network-specific offload policies for the matching one or more offload identifiers (subscriptions / further generated offload identifiers). However, in response to determining that the one or more previously provisioned first network-specific offload policies have not expired or 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 because 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: retrieving one or more updated first network-specific offload policies for each of the associated one or more offload identifiers that match the one or more previously provisioned offload identifiers included in the request; and any extracted one or more first network-specific policies for one or more unmatched offload identifiers obtained from the subscription data and / or for offload identifiers further generated by the second SMF.

[0099] In yet another example, after receiving one or more previously provisioned offload identifiers including a timestamp in the request for PDU session establishment, and session management subscription data is received with the one or more offload identifiers (step 620B), and optionally, further offload identifiers are 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 (mismatch) 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 / mismatch, the second SMF determines whether the timestamps provided with the one or more previously provisioned offload identifiers indicate that the corresponding one or more previously provisioned first network-specific offload policies have expired or need to be updated. 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 in this yet another example retrieves one or more updated first network-specific offload policies for the expired policies and retrieves one or more first network-specific offload policies for one or more offload identifiers from the session management subscription data and / or one or more further generated offload identifiers.Further, in response to determining that one or more previously provisioned first network-specific offload policies have not expired, the second SMF retrieves only one or more first network-specific offload policies for 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 proceeds by including at least one of the following in its response to the first SMF: one or more first network-specific offload policies being retrieved for each of the one or more associated offload identifiers from the subscription data and / or for each of the offload identifiers further generated by the second SMF; Retrieving one or more updated first network-specific offload policies for each of the associated one or more previously provisioned offload identifiers designated as expired.

[0100] In another example, after receiving one or more previously provisioned offload identifiers, which may or may not include a timestamp, in the request for PDU session establishment, and session management subscription data is received together with the one or more offload identifiers (step 620B), and optionally, further offload identifiers are 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 as (i.e., match) or different 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 identifiers are different / mismatched, the second SMF retrieves (from a configuration, storage or server, e.g., a PCF) one or more first network-specific offload policies for one or more offload identifiers included in the session management subscription data and includes information in a PDU session establishment response message to the first SMF indicating the retrieved one or more first network-specific offload policies 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.

[0101] In some examples, the first network-specific offload policy includes one or more fully qualified domain names (FQDNs) and, optionally, ranges of internet protocol (IP) addresses for permitted and / or disallowed edge computing services.

[0102] Other information that may be stored by the second SMF, retrieved, provided to the first SMF, or included as part of any offload policy includes EDI, as specified in TS 23.548. This information is intended to support a full-fledged EAS rediscovery procedure as in TS 23.548. This means conveying a large amount of information, such as EDI, for each PDU session that is (usually) not PDU session-related information. Providing EDI related to the topology of a first network (e.g., a VPLMN) to a second network (e.g., an HPLMN) assumes that the SP has service agreements with both the first network and the second network (e.g., the VPLMN and the 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 sequence of communications is required when the first network / VPLMN DNAI is changed. The first SMF updates and stores the offload IDs and their corresponding offload 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.

[0103] As previously indicated, the first network and the second network are not limited to VPLMNs and HPLMNs, and the embodiments may also be applied between a PLMN and an NPN, and possibly between two NPNs.

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

[0105] The UDM provides subscription data when requested, or when modified if the consumer (SMF) is subscribed to be notified of any changes.

[0106] 7 is a schematic block diagram of a network node 700 according to some embodiments of the present disclosure. Optional features are represented by dotted boxes. The network node 700 may be, for example, a core network node implementing an NF (e.g., 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), or a network node implementing all or a portion of the functionality of an NF (e.g., all or a portion of the functionality of 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). As shown, network node 700 includes one or more processors 704 (e.g., a central processing unit (CPU), an application specific integrated circuit (ASIC), 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 circuits. The one or more processors 704 operate to provide one or more functions of network node 700 described herein (e.g., one or more functions of 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, for example, stored in memory 706 and executed by the one or more processors 704.

[0107] 8 is a schematic block diagram illustrating a virtualized embodiment of a network node 700 in accordance with some embodiments of the present disclosure. Again, optional features are represented by dotted boxes. As used herein, a "virtualized" network node is an implementation of a network node 700 in which at least a portion of the functionality of the network node 700 is implemented as virtual components (e.g., via virtual machines running on physical processing nodes in the network). As shown, in this example, the network node 700 includes one or more processing nodes 800 coupled to or included as part of a network 802. Each processing node 800 includes one or more processors 804 (e.g., CPUs, ASICs, FPGAs, etc.), memory 806, and a network interface 808. In this example, the functions 810 of network node 700 described herein (e.g., one or more functions of 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) are implemented in one or more processing nodes 800 or distributed in any desired manner across two or more processing nodes 800. In some particular embodiments, some or all of the functions 810 of network node 700 described herein are implemented as virtual components executed by one or more virtual machines implemented within a virtual environment hosted by processing node 800.

[0108] In some embodiments, a computer program is provided that includes instructions that, when executed by at least one processor, cause the at least one processor to perform functions of network node 700 or a node (e.g., processing node 800) that implements one or more of the functions 810 of network node 600 in a virtual environment according to any of the embodiments described herein. In some embodiments, a carrier is provided that comprises the above-mentioned computer program product. 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).

[0109] 9 is a schematic block diagram of a network node 700 in accordance with some other embodiments of the present disclosure. The network node 700 includes one or more modules 900, each of which is implemented in software. The modules 900 provide the functionality of the network node 700 described herein. This description is equally applicable to the processing nodes 800 of FIG. 8, where the modules 800 may be implemented in one of the processing nodes 800 or distributed across multiple processing nodes 800.

[0110] Any suitable step, method, feature, function, or benefit disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may comprise several of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), dedicated digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, and the like. The program code stored in memory includes program instructions for implementing one or more telecommunications and / or data communication protocols and instructions for performing one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause each functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0111] While the processes in the figures may indicate a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.). Embodiments: The following are exemplary, non-limiting claimed embodiments that may be used as the basis for future claims, although the entire contents of this application may be used as the basis for future claims. Group A: V-SMF Embodiment 1. A method for providing offload 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: sending, by a first SMF in the first network, a request for PDU session establishment to a second SMF in the second network, indicating that the first SMF supports home routing session breakout of the PDU session and / or requests authorization for home routing session breakout; receiving a message from the second SMF indicating a response including one or more offload IDs, each identifying a first network-specific offload policy for the home routing session breakout to be applied by the first SMF; A method comprising: Embodiment 2. The method of embodiment 1, wherein the message indicating the response further includes a first network-specific offload policy identified by each of the one or more offload IDs. Embodiment 3. The method of embodiment 1, wherein the request for PDU session establishment includes one or more previously provisioned offload IDs that identify one or more previously provisioned first network-specific offload policies, each of the one or more previously provisioned offload IDs optionally being tagged with a timestamp indicating when the identified previously provisioned first network-specific offload policy was provisioned. Embodiment 4. The message instructing a response is: - one or more previously provisioned offload IDs and corresponding updated offload policies; - one or more first network-specific policies and associated offload identifiers corresponding to offload identifiers obtained from the subscription data and / or one or more offload identifiers generated from the offload identifiers obtained from the subscription data; 4. The method of any one of embodiments 1 to 3, comprising at least one of: Embodiment 5. The method of any one of embodiments 1 to 4, further comprising storing the first network-specific policies (existing, received (new), and updated).

[0023] Embodiment 6. The method of embodiment 1, wherein the first network-specific offload policy includes one or more fully qualified domain names (FQDNs) and, optionally, a range of Internet Protocol (IP) addresses for permitted edge computing services. Embodiment 7. The method of embodiment 1, wherein the first network-specific offload policy includes one or more fully qualified domain names (FQDNs) and, optionally, a range of Internet Protocol (IP) addresses for unauthorized edge computing services. Embodiment 8. The method of embodiment 6 or 7, further comprising: configuring the UL CL / BP according to the first network-specific offload policy being received (or updated). Embodiment 9. The method of embodiment 1 or 2, wherein the first network is a VPLMN, the second network is a HPLMN, the first SMF is a visited SMF, and the second SMF is an H-SMF. Group B: H-SMF Embodiment 10. A method for providing offload 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: receiving a request for PDU session establishment from a first SMF in a first network, the request indicating that the first SMF supports Home Routing Session Breakout (HR-SBO) for the PDU session and / or requests authorization for HR-SBO; obtaining session management subscription data including first network-specific traffic offload information, the first network-specific traffic offload information comprising: An indication of whether the first network is authorized for HR-SBO; and A list of one or more Edge Computing (EC) service FQDNs and / or one or more offload identifiers for destination IP ranges that are authorized for the HR-SBO; and A list of one or more Edge Computing (EC) service FQDNs and / or one or more offload identifiers for destination IP ranges that are not allowed for HR-SBO. At least one of obtaining session management subscription data, including: sending a message to the first SMF indicating a response including one or more offload identifiers, each identifying a first network-specific offload policy for the home routing session breakout to be applied by the first SMF; A method comprising: Embodiment 11. The method of embodiment 10, further comprising: generating one or more offload identifiers based on one or more offload identifiers obtained in the session management subscription data and the first network identifier; and including the generated one or more identifiers in a message indicating a response to the first SMF. Embodiment 12. The method of embodiment 10 or 11, further comprising retrieving a first network-specific offload policy for each of one or more offload identifiers included in the subscription data management and / or for each of one or more offload identifiers being generated. Embodiment 13. The method of embodiment 11 or 12, wherein the step of retrieving the first network-specific offload policy includes obtaining the first network-specific offload policy from an internal configuration or storage or policy server of the second SMF. Embodiment 14. The method of embodiment 11 or 12, wherein the message indicating the response further includes a retrieved first network-specific offload policy for each of the one or more offload identifiers included in the subscription data management and / or for each of the one or more offload identifiers being generated. Embodiment 15. The method of embodiment 10, wherein the request for PDU session establishment includes one or more previously provisioned offload identifiers that identify one or more first network-specific offload policies that have been previously provisioned in the first SMF, and each of the one or more previously provisioned offload identifiers is optionally tagged with a timestamp indicating when the identified first network-specific offload policy was provisioned. Embodiment 16. Determining whether one or more previously provisioned offload identifiers received from a first SMF are the same as or different from one or more offload identifiers from session management subscription data and / or one or more generated offload identifiers; If they are the same, retrieving one or more first network-specific offload policies for the one or more matching offload identifiers; If there is no match, retrieving one or more first network-specific offload policies for the one or more offload identifiers from the subscription data and / or for the one or more offload identifiers being generated; and including in the response indicating message the retrieved one or more first network-specific offload policies and associated one or more offload identifiers corresponding to the one or more matched offload identifiers obtained from the subscription data and / or from the generation and the one or more non-matched offload identifiers. 16. The method of any one of embodiments 11, 12 and 15, further comprising: Embodiment 17. Determining whether one or more previously provisioned offload identifiers received from a first SMF are the same (match) or different from one or more offload identifiers from session management subscription data and / or one or more generated offload identifiers; If they are the same / match, determining whether a timestamp provided with the one or more previously provisioned offload identifiers indicates that the corresponding previously provisioned first network-specific offload policy has expired or needs to be updated; retrieving one or more updated first network-specific offload policies for the one or more matching offload identifiers in response to determining that the one or more previously provisioned first network-specific offload policies have expired or need to be updated; refraining from retrieving the one or more first network-specific offload policies for the matched one or more offload identifiers in response to determining that the one or more previously provisioned first network-specific offload policies have not expired or need to be updated; including in the response indicating message one or more retrieved updated first network-specific offload policies for each of one or more associated offload identifiers that match one or more previously provisioned offload identifiers included in the request; and 16. The method of any one of embodiments 11, 12 and 15, further comprising: Embodiment 18. The method of embodiment 17, wherein the message instructing the response further includes any retrieved one or more first network-specific policies for the one or more non-matching offload identifiers obtained and / or generated from the subscription data. Embodiment 19. Determining whether one or more previously provisioned offload identifiers received from a first SMF are the same (match) or different from one or more offload identifiers from session management subscription data and / or one or more generated offload identifiers; If different / inconsistent, retrieving one or more first network-specific offload policies for one or more offload identifiers obtained in the session management subscription data; including in the response-indicating message one or more first network-specific offload policies retrieved for each of the one or more associated offload identifiers from the subscription data and / or from the generation; 16. The method of any one of embodiments 11, 12 and 15, further comprising:

[0033] Embodiment 20. The method of any one of embodiments 14 to 19, wherein the first network-specific offload policy includes one or more fully qualified domain names (FQDNs) and, optionally, ranges of Internet Protocol (IP) addresses for permitted edge computing services.

[0033] Embodiment 21. The method of any one of embodiments 14 to 19, wherein the first network-specific offload policy includes one or more fully qualified domain names (FQDNs) and, optionally, a range of Internet Protocol (IP) addresses for unauthorized edge computing services. Embodiment 22. A network node adapted to perform the method according to any one of embodiments 1 to 21. Embodiment 23. A non-transitory computer-readable storage medium comprising executable instructions that, when executed by a processor, cause the processor to perform the method of any one of embodiments 1 to 21.

[0112] The following describes additional 3GPP documents containing additional embodiments based on those described in this disclosure, the subject matter of which may be used to derive future patent claims, but is not limiting. 3GPP TSG-SA WG2 Meeting #154AH S2- 2xxxxx Electronic Meeting, Date (Revised version of S2-2xxxxx) Source: Ericsson Title: Discussion of the HR-SBO Scenario Editor's Note Document purpose: Agreement Agenda Item: 8.2 Work Item / Release: FS_enh_EC / Rel-18 Summary of contribution: This contribution discusses the editor's note on the HR-SBO scenario and proposes a way forward. 1. Introduction CR S2211366 (Major Issue #1) of TS 23.548 related to the Roaming HR-SBO scenario was approved during SA2 154th with the following Editor's Note: Editor's note: The user plane topology in a VPLMN supporting HR-SBO is FFS. Editor's note: It is up to the AMF whether to send an indication to the V-SMF that the requested session is allowed as an HR-SBO PDU session. If agreed, this indication can be used by the V-SMF to determine whether to request an HR-SBO PDU session from the H-SMF. Editor's note: It is FFS when the V-SMF selects the V-EASDF. In other words, the V-SMF selects the V-EASDF either 1) before sending the Nsmf_PDUSession_Create request for the HR-SBO PDU session to the H-SMF, or 2) after receiving the Nsmf_PDUSession_Create response from the H-SMF. Editor's note: It is FFS if the SM subscription data contains 1) an HR-SBO authorization indication or 2) HR-SBO authorization information including a VPLMN-specific offload policy. If only an HR-SBO authorization indication is added, the H-SMF retrieves the VPLMN-specific offload policy from the H-PCF if it is available in the H-PCF based on the SLA between the HPLMN and the VPLMN. Editor's note: Detailed information on VPLMN-specific offload policies (e.g., FQDN ranges, IP ranges, AMBR for the local part of the DN, or charging policies) is FFS. Editor's note: How the EAS (re)discovery procedure for the HR-SBO roaming scenario is performed is FFS. Below, these issues are discussed and ways forward are suggested. 2 Discussion 2.1 Permitted HR-SBO Instructions for V-SMF Once the V-SMF is selected, the AMF contacts the V-SMF to set up a PDU session towards the H-SMF. To handle HR-SBO, certain V-SMF functions that are not typical of a V-SMF are required (e.g., selecting a V-EASDF, requesting an HR-SBO PDU session towards the H-SMF, etc.). For the V-SMF to know that this functionality is required, the AMF should send an indication to the V-SMF that the requested session is allowed as an HR-SBO PDU session. Proposal 1: The AMF should send an indication to the V-SMF that the requested session is allowed as an HR-SBO PDU session. 2.2 Selection of V-EASDF Since the H-SMF may need the V-EASDF IP (to send in the PCO message to the UE), this means that the V-SMF should select the V-EASDF IP address and send it to the H-SMF in the Nsmf_PDUSession_Create request for the HR-SBO PDU session. Otherwise, another signaling message is needed to convey the V-EASDF information. Even if, for some reason, the H-SMF does not ultimately authorize the HR-SBO, there is no unnecessary signaling or wasted resources in the VPLMN. Proposal 2: The V-SMF should select a V-EASDF before sending a Nsmf_PDUSession_Create request for the HR-SBO PDU session. 2.3 Composition of VPLMN-specific offloading policies VPLMN-specific offloading policies may have different configurations depending on which MNO a service provider (SP) has contracted with. If agreed between the SP and the VPLMN, EC application information (e.g., EDI) is available in the VPLMN. In this case, the HPLMN may provide only the HR-SBO authorization indication to the VPLMN, as a minimum. However, it is possible that the HPLMN provides other services for a given UE and PDU session for other non-EC applications. In that case, these applications should not be authorized for SBO in the VPLMN. Proposal 3: VPLMN-specific offload policies should be able to include traffic descriptors (e.g., destination IP ranges, ports, FQDNs) that are not allowed for HR-SBO. If there is an agreement between the SP and the HPLMN, the HPLMN must provide the VPLMN with the offloading policy required for HR-SBO. The following alternatives are possible for the information conveyed to support session breakout: - All required information (including EDI as specified in TS 23.548) is conveyed. This information is intended to support a full-fledged EAS rediscovery procedure as in TS 23.548. This means conveying a large amount of information, such as EDI, for each PDU session, which is not necessarily PDU session-related information. Providing EDI related to the VPLMN topology to the HPLMN assumes that the SP has a service agreement 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 afterwards can the SP provide the EDI related to the VPLMN DNAI to the HPLMN. The same sequence of communications is required when the VPLMN DNAI is changed. - The offloading policy information includes the EC FQDN configured in the V-EASDF and the IP range configured in the UL CL / BP. In this case, the V-SMF selects the UL CL or BP and 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. In this case, the information can be structured as follows: Offload_ID_A: FQDN_1,..., FQDN_K: IP range_1,..., IP range_n... Offload_ID_B: FQDN_K+1,..., FQDN_M: IP range_n+1,..., IP range_p... ... Table 1: Allowed EC Service FQDNs and IP Address Ranges Here, the various rows in the table tagged with Offload_ID_A, B, etc. correspond to the traffic offload policies of a particular EC service, so that the FQDN can be used to provision the V-EASDF in case of dynamic PSA insertion via DNS-based EAS discovery, while the list of IP ranges is the list of EAS IP ranges that should be configured for a given service in the UL CL / BP. Note that this service-related offload information A, B, etc. is independent of the VPLMN, except that some EAS IP address ranges represent service provider deployments in different countries and PLMNs, and are therefore never configured for a particular VPLMN (assuming that a UL CL configuration update for a given IP address range occurs when the DNS response contains both the ECS and the IP addresses of the EASs belonging to that IP address range). Another example is to divide each row of Table 2 into country-specific IP address ranges, and then keys A1, A2, B1, B2, etc. identify both the service and geographic region (e.g., MCC) associated with those IP ranges. This is shown in Table 2 below. Note that the offload IDs A1, A2, B1, B2, etc. may be derived based on the service's offload ID and VPLMN ID, respectively. This information structure therefore does not require the VPLMN DNAI, and so this approach simplifies the information exchanged between all parties (the VPLMN DNAI in the EDI to the HPLMN requires that the Home MNO understands the VPLMN DNAI, which it then shares with any service provider (SP) with which it has an agreement, and that the SP provides the EDI related to the VPLMN DNAI and modifies the EDI if the VPLMN DNAI changes). This approach also reduces the information that the H-SMF needs to provide to the V-SMF. Proposal 4: VPLMN-specific offloading policies should be able to include traffic descriptors (FQDN and IP address ranges) that are allowed for HR-SBO. NOTE: Traffic offload policies for allowed and disallowed traffic should be mutually exclusive, i.e., either a list of allowed traffic descriptors or a list of disallowed traffic descriptors should be sent, but not both. Proposal 5: If the VPLMN-specific offloading policy includes allowed EC application information as in Proposal 4 above, the V-SMF selects the UL CL and L-PSA based on the UE location without considering the EAS deployment information. 2.4 HR-SBO related information in SM subscription data in HPLMN As described in Section 2.3 above, the VPLMN-specific offload policy may include application information that is allowed or not allowed for the HR-SBO, including the FQDN and associated IP address ranges, as shown in Table 1 above. Such information is not typical PCC information and therefore cannot be received from the H-PCF. Instead, this information should be pre-configured in the H-SMF and updated if the associated SLA changes. Additionally, SM subscription data in the UDM may be used to inform the H-SMF about which traffic offload information should be conveyed to a particular V-SMF. The table below contains an example of how the session management subscription data can be extended with this information to the existing UE subscription data (i.e., Table 5.2.3.3.1-1 of TS 23.502). Each offload identifier identifies a service consisting of a list of FQDNs and a list of IP address ranges as specified above in Table 1. This list may be pre-configured in the H-SMF and updated as needed. 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 already received a traffic offload policy for a particular offload identifier, this can be indicated to the H-SMF in any subsequent request for another HR-PDU session from the same V-SMF, so that it is sufficient for the offload identifier to be sent by the H-SMF rather than the entire information being retransmitted. In this way, the amount of information exchanged between the HPLMN and the VPLMN can be reduced. This is shown in Figure 6: Detailed procedure for HR-PDU session establishment using UDM and offload identifier, as described below. 1. The UE sends a PDU session establishment request to the V-SMF selected by the AMF. 2. The V-SMF selects a UPF in the VPLMN (which may be based on the policy fetched from the V-PCR) and sends an Nsmf_PDUSession_Create request to the H-SMF. The V-SMF sends a support and / or authorization request for HR-SBO and also provides the V-EASDF address to the H-SMF. The V-SMF also sends the offload IDs of the offload information previously received from the H-SMF (if any) and tagged with the timestamp of when they were received. 3. The SMF requests the session management subscription data using Nudm_SDM_Get(SUPI, Session Management Subscription Data, Selected DNN, S-NSSAI of HPLMN, Serving PLMN ID, [NID]) and subscribes to be notified when this subscription data is modified using Nudm_SDM_Subscribe. 4. The UDM responds with session management subscription data, including VPLMN-specific traffic offload information, for example, as shown in Table 4. 5. The H-SMF checks the offload IDs received in the VPLMN-related offload information, and may generate further offload IDs from the offload IDs received from the UDM and the VPLMN ID. These offload IDs may be used to identify the EAS IP address range of EC services in a geographical area, for example, of the MCC of the VPLMN, as shown in Table 2. The H-SMF then compares the offload IDs with the offload IDs received from the V-SMF. The H-SMF also checks whether the configuration information has changed for some of the offload IDs received from the UDM-related information based on the received timestamps. 6. The H-SMF sends an Nsmf_PDUSession_Create response to the H-SMF, in which case the H-SMF sends the VPLMN-specific offload policies (including the associated offload IDs) corresponding to the offload IDs received from the UDM, unless an update has been made in the meantime, and the offload IDs have been received from the V-SMF. 7. The V-SMF sends a PDU session establishment response to the UE. Proposal 6: (If available) IP ranges and FQDNs in service-specific offload policies can be configured in the H-SMF, and which VPLMN-specific policy is used can be included in the SM subscription data as an offload identifier in the UDM. 3. Proposal It is proposed that the above proposals be taken into consideration in the standardization work on HR-SBO cases. Abbreviation: In this disclosure, at least some of the following abbreviations may be used: In the event of inconsistencies between abbreviations, the abbreviation as used above shall prevail: If listed multiple times below, the first listing shall prevail over any subsequent listings. 3GPP 3rd Generation Partnership Project 5G (fifth generation) 5GC 5th generation core 5GS 5th generation system AF application features AMF access and mobility management capabilities AN Access Network ASIC Application Specific Integrated Circuit AUSF authentication server function CPU Central Processing Unit DCI Downlink Control Information DN Data Network DSP Digital Signal Processor EAS Edge Application Server E-commerce Edge Computing · EDI EAS deployment information EDNS Extensions for DNS EHE edge hosting environment eNB Enhanced or Evolved Node B EPC Evolved Packet Core E-UTRA Enhanced Universal Terrestrial Radio Access FPGA Field Programmable Gate Array FQDN (Fully Qualified Domain Name) · gNB New wireless base station HPLMN Home Public Land Mobile Network HR-SBO Home Routing Session Breakout IP Internet Protocol LBO Local Breakout LTE Long Term Evolution MTC Machine Type Communication NEF network publishing function NF network function NPN (non-public network) · NR new radio NRF Network Function Repository Function NSSF network slice selection function OTT (Over-the-Top) PC personal computer PCF policy control function PDU Packet Data Session Unit RAM Random Access Memory RAN Radio Access Network ROM Read-Only Memory RP receiving point RRH Remote Radio Head RTT Round Trip Time SM session management SMF session management function UDM Integrated Data Management UE User Equipment UPF user plane function VPLMN Visited Public Land Mobile Network

Claims

1. 1. 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 first session management function (SMF) in the first network, the method comprising: sending, by the first SMF in the first network, a request for establishment of a Packet Data Unit (PDU) session for the UE to a second SMF in the home network, indicating that the first SMF is requesting authorization for a Home Routing Session Breakout (HR-SBO) of a PDU session; receiving a message from the second SMF indicating a response including one or more offload identifiers (IDs), each ID of the one or more offload IDs identifying one or more first-network-specific offload policies for edge computing (EC) services to be applied in the first network; A method comprising:

2. 2. The method of 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. 2. The method of claim 1, wherein the request for establishing the PDU session includes one or more previously provisioned offload IDs that identify one or more previously provisioned first network-specific offload policies in the first network from the home network.

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

5. 5. The method of claim 1, wherein the message indicating the response further includes one or more previously provisioned offload IDs along with a corresponding updated first network-specific offload policy.

6. 6. The method of claim 5, further comprising replacing one or more previously provisioned first network-specific offload policies with the updated first network-specific offload policies corresponding to the one or more previously provisioned offload IDs.

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

8. The method of claim 2 , further comprising storing the one or more first network-specific offload policies being received identified by the one or more offload IDs.

9. The first network-specific offload policy includes: one or more fully qualified domain names (FQDNs), and - Internet Protocol (IP) address ranges The method of claim 1 , comprising at least one of:

10. The first network-specific offload policy includes: one or more fully qualified domain names (FQDNs), and - Internet Protocol (IP) address ranges The method of claim 1 , comprising at least one of:

11. 11. The method of claim 1, further comprising: configuring a user plane function having an uplink classifier branch point (UL CL / BP) according to the first network-specific offload policy and / or the updated offload policy.

12. 12. The method of claim 1, wherein the first network is a visited public land mobile network (VPLMN), the first SMF is a visited SMF (V-SMF), and the second SMF is a home SMF (H-SMF).

13. 1. 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 a request for establishment of a Home Routing Session Breakout (HR-SBO) PDU session from a first SMF in the first network, the request indicating that the first SMF requests authorization for a Home Routing Session Breakout (HR-SBO) PDU session; From the third network function, One or more subscribed offload identifiers (IDs) of one or more edge computing (EC) service policies that are authorized for the HR-SBO; and One or more subscribed offload IDs of one or more Edge Computing (EC) service policies that are not authorized for HR-SBO. obtaining first network-specific traffic offload information, including: sending a message to the first SMF indicating a response including one or more offload IDs, the one or more offload IDs being based on the one or more subscribed offload IDs to be applied by the first network; A method comprising:

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

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

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

17. 17. The method of claim 13, further comprising retrieving the policy for each of the one or more offload identifiers from an internal configuration of the second SMF or from a policy server in the home network.

18. The method of claim 13 , wherein the message indicating the response further includes a retrieved offload policy for each of the one or more offload identifiers.

19. 14. The method of claim 13, wherein the request for establishing the PDU session includes one or more previously provisioned offload IDs that identify one or more offload policies previously provisioned in the first SMF.

20. 20. The method of claim 19, wherein each of the one or more previously provisioned offload IDs is tagged with a timestamp indicating when the identified offload policy was provisioned.

21. 21. The method of claim 19 or 20, further comprising: determining whether the policy associated with the one or more previously provisioned offload IDs needs to be updated in the first SMF; and, in response to determining that the policy of the one or more previously provisioned offload IDs needs to be updated, including the updated policy in the message indicating a response to the first SMF.

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

23. 22. A network node comprising one or more processors and a memory containing instructions that, when executed by the one or more processors, configure the network node to perform the method of any one of claims 1 to 21.

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

Images