Satellite edge computing

Abstract

Embodiments of the solution(s) disclosed herein provide an EDN deployment architecture in a satellite in which an Edge Enabler Server (EES) and EAS are deployed together with a UPF and a gNB. Embodiments of the present disclosure add enhancements to the Edge Enablement server EES profile to include satellite information (e.g., Satellite ID, elevation, etc.) and used by an Edge Configuration Server (ECS) deployed on the ground to identify an EES in satellite that can serve the UE for the longest time based on the monitored location / movement prediction. Embodiments to support exposure of satellite ID to ECS / AF from a telecommunication system are also provided.

Description

SA TELLITE EDGE COMPUTINGRELATED APPLICATIONSThis application claims the benefit of provisional patent application serial number PCT / CN 2024 / 077331 filed on 2024-02-18, and PCT / CN 2024 / 077507 filed on 2024-02-19 the disclosure of which are hereby incorporated herein by reference in its entirety.Technical Field

[0001] The present disclosure relates to a cellular communications system and, more specifically, to satellite-edge computing for a satellite-based deployment of a cellular communications system.Background

[0002] The 3rdGeneration Partnership Project (3GPP) Service and Systems Aspects (SA) working group 1 (SAI) has further studied new use cases in Release (Rel)-19 within 3GPP Technical Report (TR) 22.865 (see, e.g., V19.2.0) to support new capabilities such as Store and Forward Satellite operation (which is relevant for Internet of Things (loT) services) and User Equipment (UE)-satellite-UE communication, which have been captured as additional requirements in 3GPP Technical Specification (TS) 22.261 (see, e.g., V19.5.0). These capabilities implicitly require a regenerative payload (non-transparent) approach. Note, however, that Rel-17 and Rel-18 assumed transparent mode satellite access. Figure 1A illustrates the transparent payload architecture, and Figure IB illustrates the regenerative payload architecture.

[0003] In the regenerative payload architecture, the satellite carries either an entire base station (i.e., an entire gNodeB (gNB) in the case of New Radio (NR)) or parts of it, such as the radio unit which makes it possible to decode and process packets on the satellite. The regenerative architecture provides more flexibility, better performance, and global coverage due to the ability to support inter-satellite links.

[0004] Furthermore, in 3GPP TS 23.501 (see, e.g., V18.4.0) clause 5.43, the edge computing via the User Plane Function (UPF) deployed in satellite has been defined which enables broader use case scenario for Edge application deployment.

[0005] Furthermore, As stated in 3rdGeneration Partnership Project (3GPP) Technical Specification (TS) 23.558 (see, e.g., V18.4.0), in edge computing, the EdgeConfiguration Server (ECS), Edge Enabler Server (EES), and Edge Application Server (EAS), which are not deployed in the Mobile Network Operator (MNO) trusted domain, act as authorized Application Programming Interface (API) invoker to consume services from the Core Network (i.e., the 5thGeneration (5G) Core (5GC) or Evolved Packet Core (EPC)) northbound API entities such as Service Capabilities Exposure Function (SCEF), Network Exposure Function (NEF), SCEF+NEF, which act as API Exposing Function as specified in 3GPP TS 23.222 (see, e.g., V18.3.0). APIs such as User Equipment (UE) Location event Exposure, etc. have been utilized.

[0006] Figure 1C is a reproduction of Figure 6.2-3 from 3GPP TS 23.558, which illustrates a service-based representation for utilization of the Core Network (5GC, EPC) northbound APIs via Common API Framework (CAPIF).

[0007] Systems and methods are disclosed that relate to satellite edge computing. In one embodiment, a method performed by an Edge Configuration Server (ECS) for service continuity (or initial service provisioning for the ECS) for Edge Data Networks (EDNs) comprising at least one satellite EDN, the method comprises the step of monitoring the location of a user equipment (UE) and / or moving prediction of the UE, then obtaining by for example querying an external server for a list of satellite identifier (ID), of satellites in accordance with the location and / or the UE moving prediction. The method further comprises the step of identifying an Edge Enabler Server, EES, deployed in a satellite with a satellite ID matching with one of satellite ID in the obtained list of satellite IDs to serve the UE with a longest service time and sending to the UE a message comprising information of the identified EES and the corresponding satellite ID of the satellite on which the EES is deployed. The message may be sent to the UE in response to receiving a request message from the UE comprising satellite capability information, else the message is a notification message.

[0008] According to an aspect, the method further comprises the ECS subscribing to a core network (e.g., 5G core, 6G core) of an associated cellular communications system (e.g., 5G system or 6G system) to get notified of location change of the UE.

[0009] According to another aspect, the method further comprises the step of receiving from the EES, an EES registration request comprising an EES profile of the EES, and the EES profile comprises the satellite ID of the satellite on which the EES isdeployed. The EES registration request may occur prior to the identifying of the EES step or of the monitoring step.

[0010] For example, the step of identifying the Edge Enabler Server, EES, deployed in a satellite with a satellite ID matching with one of satellite ID in the obtained list of satellite IDs to serve the UE with a longest service time consists of identifying an EES on a satellite having a satellite ID to serve the UE with a longest service time and that matches one of the satellite IDs in the obtained list of satellite IDs.

[0011] Corresponding embodiments of a network node are also disclosed.

[0012] Embodiments of a method performed by an Edge Enabling Client (EEC) at a UE, for service provisioning are also disclosed. In one embodiment, the method comprises the step of sending a service provisioning request to an ECS, wherein the service providing request comprises satellite capability information that comprises satellite frequency bands and / or minimum elevation angle and receiving a service provisioning response from the ECS.

[0013] For example, the service provisioning response comprises EES information and corresponding satellite ID of a satellite on which the EES is deployed.

[0014] For example the service provisioning response comprises an EES information that comprises a list of Edge Data Network, EDN, configuration information for one or more EDNs. In one embodiment, the EDN configuration for at least one of the one or more EDNs comprises a satellite selection recommendation (e.g., information that indicates a recommended satellite when using the EDN and / or one or more satellite frequency bands to be used by the UE when using the EDN).

[0015] Corresponding embodiments of a network node are also disclosed.

[0016] Embodiments of a method performed by an EES of a satellite EDN are also disclosed. In one embodiment, the method comprises sending an EES registration request to an ECS, wherein the EES registration request comprises an EES profile of the EES, and the EES profile of the EES comprises satellite related information for a satellite on which the EES is deployed.

[0017] In one embodiment, the satellite related information comprised in the EES profile of the EES comprises a satellite ID of the satellite on which the EES is deployed.

[0018] In one embodiment, the satellite related information comprises any one or more of the following: elevation of the satellite on which the EES is deployed, satellitetype (e.g., GEO, MEO, or LEO) of the satellite on which the EES is deployed, and satellite ephemeris information for the satellite on which the EES is deployed.

[0019] In one embodiment, the EES profile of the EES further comprises a dynamic EES service area indication for the EES that indicates that a service area of the EES is dynamic.

[0020] Furthermore, Systems and methods for satellite identifier (ID) exposure in a cellular communications system that utilizes satellite backhaul are disclosed. In one embodiment, a method performed by a network node of a cellular communications system comprises obtaining a satellite ID of a serving satellite of a Protocol Data Unit (PDU) session of a User Equipment (UE) having a satellite backhaul, and providing the satellite ID to an application function, either directly or via an exposure function. In this manner, the application function is enabled to get insight about the satellite ID of the satellite through which access is provided so that, for example, application-level logic can be built based on related satellite information.

[0021] In one embodiment, the network node is an Access and Mobility Management Function (AMF). Further, obtaining the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises obtaining the satellite ID at the AMF (e.g., during a process for creating the PDU session having the satellite backhaul), and providing the satellite ID to the application function comprises providing the satellite ID directly to the application function as part of an AMF event notification (e.g., a UE mobility notification).

[0022] In one embodiment, the network node is an AMF. Further, obtaining the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises obtaining the satellite ID at the AMF (e.g., during a process for creating the PDU session having the satellite backhaul), and providing the satellite ID to the application function comprises providing the satellite ID to the application function via an exposure function as part of an AMF event notification (e.g., a UE mobility notification).

[0023] In one embodiment, the network node is a Policy and Control Function (PCF). Further, obtaining the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises receiving the satellite ID from an AMF (e.g., as part of a notification of a satellite backhaul category change), and providing the satellite ID to the application function comprises providing the satellite ID to the applicationfunction (e.g., either directly or via an exposure function) as part of a UE satellite backhaul category change notification.

[0024] In one embodiment, the network node is a Session Management Function (SMF). Further, obtaining the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises receiving the satellite ID from an AMF (e.g., as part of a request to create a PDU session context for the PDU session), and providing (Fig. 4, step 8) the satellite ID to the application function comprises providing the satellite ID directly to the application function as part of an SMF event notification.

[0025] In one embodiment, the network node is an SMF. Further, obtaining the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises receiving the satellite ID from an AMF (e.g., as part of a request to create a PDU session context for the PDU session), and providing the satellite ID to the application function comprises providing the satellite ID to the application function via an exposure function as part of an SMF event notification.

[0026] In one embodiment, the network node is a Policy and Control Function (PCF). Further, obtaining the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises receiving the satellite ID from an SMF (e.g., as part of a notification of a satellite backhaul category change), and providing the satellite ID to the application function comprises providing the satellite ID to the application function (e.g., either directly or via an exposure function) as part of a UE satellite backhaul category change notification.

[0027] Corresponding embodiments of a network node implementing the embodiments herein are also disclosed.Brief Description of the Drawings

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

[0029] Figure 1A illustrates the transparent payload architecture;

[0030] Figure IB illustrates the regenerative payload architecture;

[0031] Figure 1C is a reproduction of Figure 6.2-3 from 3GPP TS 23.558, which illustrates a service-based representation for utilization of the Core Network (5GC, EPC) northbound APIs via Common API Framework (CAPIF);

[0032] Figure 2 illustrates a satellite EDN deployment, in accordance with an embodiment of the present disclosure;

[0033] Figure 3 illustrates an EES registration procedure using the enhanced EES profile, in accordance with an embodiment of the present disclosure;

[0034] Figure 4 illustrates an example for service continuity (a.k.a. ACR) triggered by ECS when UE moves between satellite EDN and ground EDN coverage, in accordance with an embodiment of the present disclosure;

[0035] Figure 5 illustrates service provisioning, in accordance with an embodiment of the present disclosure;

[0036] Figure 6 illustrates a procedure for satellite ID exposure via an AMF event exposure in accordance with one example embodiment of the present disclosure;

[0037] Figure 7 is a reproduction of Figure 4.16.11-1 of 3GPP TS 23.502;

[0038] Figure 8 illustrates a procedure for satellite ID exposure via SMF event exposure in accordance with another example embodiment of the present disclosure;

[0039] Figure 9 is a schematic block diagram of a network node according to some embodiments of the present disclosure;

[0040] Figure 10 is a schematic block diagram that illustrates a virtualized embodiment of the network node according to some embodiments of the present disclosure; and

[0041] Figure 11 is a schematic block diagram of the network node according to some other embodiments of the present disclosure.Detailed Description

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

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

[0044] 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 wirelessly transmit and / or receive signals. 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 Third 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, or the like), 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. Note that a radio access node may be deployed on the ground, on a ship, in the air, or in space (e.g., on a satellite).

[0045] Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some other examples of a core network node in a 5thGeneration System (5GS) include a node 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 Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like. Some examples of a core network node in an Evolved Packet System (EPS) include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like.

[0046] Network Node: As used herein, a "network node" can be a radio access node, a core network node, or any other node of a network such as, e.g., edge computing related network node (e.g., a network node that implements an Edge Configuration Server (ECS), an Edge Enabler Server (EES), an Edge Application Server (EAS) or the like.

[0047] User Equipment (UE): One type of communication device is a UE, which may be any type of wireless communication device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a UE include but are not limited to: a UE in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such UEs may be, or may be integrated into, amobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The UE may be a portable, hand-held, computer-comprised, or vehiclemounted mobile device, enabled to communicate voice and / or data via a wireless connection.

[0048] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0049] Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

[0050] There currently exist certain challenge(s). 3GPP document S6-234090 entitled "Pseudo-CR on new KI on Enabling re-discovery and re-allocation of EASs onboard satellites" describes a key issue related to satellite Edge Data Network (EDN) which has the following open issues:Deployment of Edge computing on board GEO satellites might impact the latency of application control and data information exchange. To assess the impacts of using Edge on board GEO satellites it would be beneficial to study the following aspects with the aim to reduce latency and data exchange over satellite feeder link:1) Investigate different deployment options for EDGEAPP when EASs are deployed on board GEO satellites?2) When / how could EAS discovery by the EEC in EDGEAPP be optimized?

[0051] In addition, the following problems exist:1. With the satellite backhaul introduction, the current location based edge discovery procedure might not be sufficient, since in certain cases when a UE moves between an EDN in a satellite and an EDN on the ground, those EDNs could have the same coverage. For example, when UE on a ship gets close to a port area, even though the EDN in the satellite still has good coverage, due to cost / bandwidth considerations, the UE may decide to switch to the ground EDN, or a drone in the sky. A more intelligent way of detecting such backhaul change and performing EAS discovery and service continuity is needed.2. The current version of 3GPP TS 23.501 only handles a LIPF deployed in Geo- Stationary Earth Orbiting (GEO) satellites, For a Non-Geostationary Orbiting (NGSO) Low-Earth Orbiting (LEO) / Medium Earth Orbiting (MEO) satellite which constantly moving (like Starlink and other commercial satellites), there are more challenges for Edge Application Server (EAS) discovery and service continuity even if the UE on ground does not move.

[0052] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of the solution(s) disclosed herein provide an EDN deployment architecture in a satellite in which an Edge Enabler Server (EES) and EAS are deployed together with a LIPF and a gNB.Embodiments of the present disclosure add enhancements to the EES profile defined in 3GPP TS 23.558 (see, e.g., V18.5.0 and V19.0.0) to include satellite information (e.g., Satellite ID, elevation, etc.) which is used for EES registration. An Edge Configuration Server (ECS) is deployed on the ground to coordinate the Application Context Relocation (ACR) procedure and EAS discovery with assistance information from the core network (i.e., the 5thGeneration Core (5GC) in the case of a 5G System (5GS)) with respect to backhaul change.

[0053] Embodiments of the present disclosure may include any one or more of the following aspects:1. Enhancement to EES profile for EES to include satellite information when registering to ECS.2. A deployment architecture with EES / EAS in satellite and ECS on ground for ACR detection.3. Enhance ECS to subscribe to Policy Control Function (PCF) event exposure to get the event notification about "Satellite backhaul category change" for detection of satel lite / non-satell ite backhaul change and perform EES discovery accordingly.4. System and method for addressing dynamic EDN service area.5. A method in ECS to assist satellite (and frequency band) selection in the UE, for carrying application traffic towards EDN in the selected satellite.

[0054] Certain embodiments may provide one or more of the following technical advantage(s):• Embodiments of the proposed solution(s) may enhance the current edge architecture to provide seamless handover for UE to switch between EDN in satellite and EDN on ground.• Embodiments of the proposed solution(s) may not only fulfill the current need of Edge application deployed in GEO satellite, but may also be used on future Edge app deployed in LEO / MEO satellites, where service area of EDN in satellite is dynamic.

[0055] Embodiments of the present disclosure will now be described in future detail under the following sub-sections. Note, however, that embodiments / aspects described in the different sub-sections may be used separately or together in any desired combination.I. Enhanced EES Profile TS 23.558 Table 8.2.6-1 for EES Profile

[0056] Table 1 below is an enhanced version of Table 8.2.6-1 of 3GPP TS 23.558 that illustrates one example embodiment of an enhanced EES profile in accordance with an embodiment of the present disclosure. Note that additions to Table 8.2.6-1 of 3GPP TS 23.558 are highlighted in Table 1 below via the use of bold, italicized, and underlined text. This is to address item 1 and item 4 in list above.Table 1: Enhanced EES Profile (Enhanced Version of Table 8.2.6-1 of 3GPP TS23.558)Note that the use of NORAD ID is only an example implementation choice of satellite ID. II. Deployment Architecture and Related Procedures

[0057] This is to address the items 2 and 3 of the list provided above.

[0058] In this regard, Figure 2 illustrates a satellite EDN deployment in accordance with an embodiment of the present disclosure. As illustrated, the system of Figure 2includes an EDN deployed in one or more satellites (i.e., a "satellite EDN"). The satellite EDN includes one or more Edge Application Servers (EAS(s)) and an Edge Enabler Server (EES). In this deployment option, an Edge Configuration Server (ECS) is deployed on the ground. A UE served by the satellite can be on the ground / sea or in the air (e.g. drone). A User Plane Function (UPF) to access the satellite EDN is deployed together with the EAS(s) and the EES in the one or more satellites. The Radio Access Network (RAN) node (e.g. gNodeB (gNB)) can either be deployed on the ground / sea (e.g. in a ship) and connected to the satellite UPF or be deployed on a regenerative satellite (see Annex A and key issue #1 in 3GPP TR 23.700-29). The 5GS control plane functions (e.g. Access and Mobility Management Function (AMF), Session Management Function (SMF)) are deployed on the ground, which is not depicted in Figure 2 for simplicity. EASs and their registered EES are deployed on the one or more satellites which constitute the satellite EDN, and these satellites' coverage areas correspond to an EDN service area of the satellite EDN. A UPF can be deployed on ground to access the ECS, the Edge Enabler Client (EEC) (in UE but not shown in Figure 2) can reach the ECS by EDGE-4 (on ground or via space).

[0059] NOTE 1: It is recommended to deploy a single EES per EDN to reduce complexity in satellite.

[0060] NOTE 2: The UPF can be deployed in one satellite and gNB can be deployed in another regenerative satellite, where they are connected with an Inter-Satellite Link.

[0061] During initial service discovery, the EEC (in UE) contacts the ECS via EDGE-4 to find an appropriate EES. Then an appropriate EAS instance is selected during EAS discovery via EDGE-1 interaction. Finally, the Application Client (AC) (in UE) communicates with the selected EAS.

[0062] During service continuity, the UE will be connected to a different satellite, consequently the EDN serving the UE will be changed.

[0063] NOTE 3: The local Protocol Data Unit (PDU) Session Anchor (PSA) UPF will be changed during service continuity, too.

[0064] NOTE 4: The interaction with ECS over EDGE-6 is also needed based on existing EDGEAPP procedures.A. EES Registration Procedure using Enhanced EES Profile

[0065] Figure 3 illustrates an EES registration procedure using the enhanced EES profile of Section I, in accordance with an embodiment of the present disclosure. This procedure is similar to that described in 3GPP TS 23.558 V19.0.0, but where the enhanced EES profile is used, e.g., for an EES of a satellite EDN (e.g., the EES of the satellite EDN of Figure 2). The steps of the EES registration procedure are as follows:• Step 1: The EES sends an EES registration request to the ECS. The request from the EES includes an EES profile of the EES. In this example, the EES is a satellite EES (i.e., an EES of a satellite EDN such as, e.g., that shown in Figure 2), and the EES profile of the EES includes satellite information such as, e.g. Satellite ID (e.g., NORAD ID), Elevation, Satellite Type (e.g. GEO / MEO / LEO), and / or Satellite Ephemeris Information for NGSO satellite. The EES profile may include any one or more of the other information elements shown in Table 1 above. The request may include a proposed expiration time for the registration.• Step 2: Upon receiving the request from the EES, the ECS (optionally verifies the security credentials of the EES) and stores the EES registration information (i.e., some or all of the information included in the EES profile) obtained in step 1. If the EES profile includes bundle ID, the ECS stores the information and associates the EES with other EESs providing the same EAS bundle information.• Step 3: The ECS sends an EES registration response indicating success or failure of the registration operation. The ECS may provide an updated expiration time to indicate to the EES when the registration will automatically expire. To maintain the registration, the EES shall send a registration update request prior to the expiration time. If a registration update request is not received prior to the expiration time, the ECS shall treat the EES as implicitly de-registered.B. Service Continuity between ED Ns in Space and ED Ns on Ground

[0066] An ECS (e.g., the ECS of Figure 2) may be used to maintain both EDNs deployed in space (e.g., the satellite EDN of Figure 2) and EDNs deployed on ground, and both EDN on ground and EDN in space can service a UE (e.g., the UE of Figure 2). In a normal situation, the UE uses gNB, UPF, and EDN service on the ground. When there is any issue in gNB and / or UPF deployed on ground, the UE can start using gNB(optional) and LIPF deployed in space. Consequently, the EDN serving the LIE needs to be relocated to a satellite EDN.

[0067] In such a situation, the ECS needs to determine the correct EDN for the LIE since both the ground EDN and the satellite EDN can service the UE. When gNB and UPF deployed on satellite is selected, it is expected that the ECS can select an EES also deployed on the same satellite and provision the corresponding EDN information to EEC in service provisioning procedure.

[0068] To enable appropriate service provisioning of the resulting satellite EDN, Data Network Access Identifier (DNAI) change can still be used in service continuity scenarios (e.g. see clause 8.8.2.4 of 3GPP TS 23.558). This requires a dedicated satellite DNAI being configured in SMF and / or UPF to access the satellite EDN.

[0069] For the subsequent Target EAS (T-EAS) discovery procedure, since the EES deployed on satellite only maintains EASs deployed on satellite, the Rel-18 EAS discovery procedure is re-used to discover proper T-EAS in satellite EDN.

[0070] NOTE 1: DNAI is not applicable for initial service provisioning and EAS discovery, since EDGE-4 traffic goes to the ECS in the ground cloud.

[0071] For UE location based EES determination in service continuity scenarios (e.g. see clause 8.8.2.2 of 3GPP TS 23.558), the ECS can subscribe to the PCF event "Satellite backhaul category change" at service provisioning. If satellite backhaul is used, the ECS needs to identify EES deployed on satellite and also provision the satellite EDN information to the EEC. Correspondingly, for EES deployed on satellite, during EES registration procedure, the EES needs to register satellite information including optionally a satellite ID.

[0072] NOTE 2: Satellite ID is used by ECS to identify proper EES deployed on the same satellite on which the PSA UPF is deployed, when there are several satellite EDNs available (deployed on different satellites) to serve UE application.

[0073] For the subsequent T-EAS discovery procedure, since the EES deployed on satellite only maintains EASs deployed on satellite, the Rel-18 EAS discovery procedure is re-used to discover proper T-EAS in satellite EDN.

[0074] NOTE 3: For initial service provisioning and EAS discovery, the above procedure is also applicable when the ground gNB and / or UPF cannot be used for the UE.

[0075] When UE moves between a service area only covered by satellite EDN and a service area only covered by ground EDN, the above service continuity procedure still applies. If satellite is not used, UE location information is sufficient to assist proper ground EDN selection as in Rel-18 procedure; otherwise, UE location and optionally satellite ID associated with PDU session is sufficient to select proper satellite EDN. If the target service area can be covered by both ground EDN and satellite EDN, based on satellite backhaul information (which is NON SATELLITE as described in 3GPP TS 29.571, clause 5.4.3.39), in the normal situation, the ECS needs to prioritize the ground EDNs (for better service experience to UE application) in service provisioning.

[0076] NOTE 4: When the ECS detects, using PCF event notification about "Satellite backhaul category change", that the UE is not using satellite backhaul, the ECS identifies a proper EES on the ground during the service continuity procedure from satellite EDN to ground EDN.

[0077] Figure 4 illustrates an example for service continuity (a.k.a. ACR) triggered by ECS when UE moves between satellite EDN and ground EDN coverage.

[0078] Pre-conditions:1. The EEC has subscribed ECS service provisioning as described in clause 8.3.3.2.3 of 3GPP TS 23.558.2. When EEC performs service provisioning subscription, ECS subscribed to 5GC to get PCF event "Satellite backhaul category change" and was notified with satellite backhaul usage information.

[0079] The steps of the procedure of Figure 4 are as follows:

[0080] Phase I: ACR Detection

[0081] Step 1: The ECS detects the UE connectivity backhaul change based on PCF event "Satellite backhaul category change", with the value "NON_SATELLITE" to indicate to the ECS that no satellite is being used, or other values (e.g. GEO) to indicate the ECS that satellite backhaul is used.

[0082] Phase II: ACR Decision

[0083] Step 2: The ECS makes the decision to perform the ACR, for satellite backhaul change from satellite backhaul to non-satellite. The ECS identifies a proper EES(s) in ground EDN based on UE location obtained from the 3GPP core network. For satellite backhaul change from non-satellite to satellite backhaul, the ECS retrieves the relevant registered T-EES based on the registered satellite information. Satellite ID used by thePDll session may be used by the ECS to find a suitable EES with a matching satellite ID (e.g., a suitable EES with an enhanced EES profile including satellite information such as, in this example, satellite ID, as described in Section I above).

[0084] Phase III: ACR Execution

[0085] Step 3: The ECS performs Service Provisioning notify to the EEC (as specified in clause 8.3.3.2.2 of 3GPP TS 23.558) for all active applications that require ACR. The Service Provisioning notification provides T-EES(s) that are relevant to supplied applications, the new location of the UE, and satellite backhaul being used by the UE.

[0086] The rest steps (i.e., steps 4 to 11) are same as 3GPP TS 23.558, clause 8.8.2.2. In this regard, the details of steps 4-11 can be found in the following excerpt from 3GPP TS 23.558 V19.0.0, Clause S.8.2.2:***** START EXCERPT FROM 3GPP TS 23.558, CLAUSE 8.8.2.2 *****Phase I: ACR Detection1. The EEC detects the UE location update as a result of a UE mobility event and is provided with the UE's new location as described in clause 8.8.1.1. The EEC can also detect an expected or predicted UE location in the future as described in clause 8.8.1.1.NOTE 2: If the EEC is triggered by an external entity such as by a notification from the ECS, a list of new EESs (to be used as T-EESs) is provided by that notification and step 3 below is skipped.Phase II: ACR Decision2. Either the AC or the EEC makes the decision to perform the ACR. If the EEC has received information of ongoing ACR, then it should not initiate an ACR with the same ACR identity uniquely identified by ACID, EEC ID (or UE ID), S-EAS endpoint and T-EAS endpoint again per clause 8.8.3.5.3.NOTE 3: Which applications require ACR can be decided based on the application profile, e.g. requirement of service continuity of the application.If the change in UE's location does not trigger a need to change the serving EAS, steps 3 onwards are skipped. The EEC remains connected to the serving EES(s) and the AC remains connected to its corresponding serving EAS.Phase III: ACR Execution3. The EEC performs Service Provisioning (as specified in clause 8.3) for all active applications that require ACR. Since the location of the UE has changed, the Service Provisioning procedure results in a list of T- EESs that are relevant to the supplied applications and the new location of the UE. When in step 1 the ACR for service continuity planning is triggered, then the Connectivity information and UE Location in the Service Provisioning procedure (as specified in clause 8.3) contains the expected Connectivity information and expected UE Location.If Service Provisioning results in no T-EES, and if ACR to CAS is supported, then the procedure for ACR with CAS applies as specified in clause 8.8.2A.2.4. The EEC performs EAS discovery (as specified in clause 8.5) for the desired T-EASs by querying the T- EESs that were established in step 3 (or provided in the notification from the ECS - if it was the trigger). If EEC registration configuration for the EESs established in step 2 indicates that EEC registration is required, the EEC performs EEC registration with the EESs (as specified in clause 8.4.2.2.2) before sending the EAS discovery request. Step 5 is skipped if EAS discovery procedure results in only one discovered T-EAS.When in step 1 the ACR for service continuity planning is triggered, and the "General context holding time duration" is included in the replied EAS discovery response, the EEC can make ACR request before it reaches respective T-EAS service area within the time period indicated by the IE.5. The AC and EEC select the T-EAS to be used for the application traffic.NOTE 4: Several EEC registrations with different EESs may result from T-EAS discovery process during a single ACR operation.6. The EEC performs ACR launching procedure (as described in clause 8.8.3. ) to the S-EES with predicted / expected UE location or Expected AC Geographical Service Area, the ACR action indicating ACR initiation and the corresponding ACR initiation data (without the need to notify the EAS). When the S-EES receives the predicted / expected UE location or Expected AC Geographical Service Area from the EEC, then the S-EES will determine to monitor the UE mobility. The S-EES may apply the AF traffic influence with the N6 routing information of the T-EAS in the 3GPP Core Network (if applicable), as described in clause 8.8.3.4. If the EEC has not subscribed to receive ACR information notifications for ACR complete events from the S-EES, the EEC subscribes for the notifications as described in clause 8.8.3.5.2.NOTE 5: It is expected that the AC will inform EAS about UE location monitoring is not needed7. If the T-EES is different than the S-EES and the EEC Context at the S-EES is not stale, the S-EES initiates EEC Context Push relocation with the T-EES as described in clause 8.9.2.3. Otherwise, if the T-EES is the same as the S-EES, EEC Context Push relocation is skipped.8. The AC is triggered by the EEC to start ACT. The AC decides to initiate the transfer of application context from the S-EAS to the T-EAS. There may be different ways of transferring context and they are all outside the scope of this specification.When in step 1 the ACR for service continuity planning has been triggered, the AC connects to the T-EAS when the UE moves to the predicted location. Otherwise, the rest of this step is skipped.After the ACT is completed, the AC remains connected to the T-EAS and disconnects from the S-EAS; the EEC is informed of the completion.NOTE 6: Whether and how the AC initiates the ACT is out of scope of the present documentWhen in step 1 the ACR has been triggered for service continuity planning, if the UE does not move to the expected / predicted location the EEC does not connect to T-EES, the AC does not connect to the T-EAS.NOTE 7: The S-EAS or T-EAS can further decide to terminate the ACR, and the T-EAS can discard the application context based on information received from EEL and / or other methods (e.g. monitoring the location of the UE). It is up to the implementation of the S-EAS and T-EAS whether and how to make such a decision.NOTE 8: It is out of scope of this specification how the AC informs the S-EAS and T-EAS that ACT was part of service continuity planning. When in step 1 the ACR for service continuity planning is triggered, the S-EAS and the T-EAS can wait for the UE to move to the predicted location before they perform the Post ACR Clean up steps 9 and 10 if it is the EAS monitoring whether the UE moves to the predicted / expected location. When the S-EAS and the T-EAS do not wait for the UE (e.g., if the UE does not move to the predicted location), the S-EAS and the T-EAS can perform the Post ACR Clean up with failure messages.NOTE 9: If the S-EAS and T-EAS are main EASs forming proxy bundle, other EASs of the bundle may transfer the application contexts in this step. How to execute ACT is out of scope of this document.Phase IV : Post- ACR Clean up9. The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.10. The T-EAS sends the ACR status update message to the T-EES as specified in clause 8.8.3.8. If the status indicates a successful ACT, and that the EEC Context relocation procedure was attempted but failed, then the T-EES indicates the failure to the T-EAS with the ACR status update response.NOTE 10: If the EDGE-3 subscription initialization result indicates failure, then the EAS can perform the required EDGE-3 subscriptions at the T-EES.NOTE 11 : Steps 9 and 10 can occur in any order.11. If the status in step 9 indicates a successful ACT, for non-planning case the S-EES sends the ACR information notification (ACR complete) message immediately to the EEC to confirm that the ACR has completed as specified in clause 8.8.3.5.3. For the service continuity planning case, if it is EES monitors the UE mobility, then only when S-EES detects the UE has moved to the predicted / expected UE location or Expected AC Geographical Service Area and the status in step 9 indicates a successful ACT, then the S-EES sends ACR information notification (ACR complete) message to the EEC indicating that UE has moved to the predicted location when the ACR type is service continuity planning. If the EEC Context relocation procedure was attempted, then the notification includes EEC context relocation status IE, indicating the result of the EEC context relocation procedure. If the EEC context relocation status indicates that the EEC context relocation was not successful, then the EEC may perform the required EDGE-1 operations such as create subscriptions at the T-EES.***** END EXCERPT FROM 3GPP TS 23.558, CLAUSE 8.8.2.2 *****C Service Continuity between ED Ns in Space

[0087] When UE moves between service areas only covered by satellite EDNs, the above service continuity procedure still applies and ECS is able to identify proper EES deployed on satellite based on UE location information, satellite backhaul information, and EES registered satellite information.D. Further Consideration for Dynamic EDN Service Area and Satellite Selection Influence

[0088] The aforementioned procedures with consideration of UE location and EDN service area are under the assumption of a GEO satellite with static EDN service area. In the case of LEO / MEO satellite, the satellite moves relative to Earth. For an LEO / MEO satellite, the EES, during registration, provides an indication of dynamic service area for providing satellite availability information instead of any concrete EES service area information (which constantly changes) (see, e.g., "Dynamic EES service area indication" in the example embodiment of the enhanced EES Profile shown above in Table 1). For EES deployed on LEO / MEO satellite with dynamic service area, the ECS can use satellite ID associated with the PDU session to identify EES with a matching satellite ID for service continuity between EDNs in space, and together with satellite backhaul information to address service continuity between satellite EDN and ground EDN.

[0089] NOTE 1: This assumes that the UE and 5G network take the lead to influence edge server selection and the ECS can know satellite ID from 5G network.

[0090] For edge server influencing satellite selection, an external server responsible for providing satellite availability information for each satellite based on real-time satellite orbit information (e.g. eccentricity, inclination, true anomaly) may exist (e.g. see 3GPP TS 23.501, Annex Q). During service provisioning, as illustrated in Figure 5, the EEC can provide needed satellite capability information (e.g. satellite frequency bands, minimum elevation angle) to the ECS in a serving provisioning request (see, e.g., step 1 of Figure 5 and Table 2 below). The ECS will be responsible to monitor LIE location and LIE moving prediction and query the external server(s) to get a list of satellites (each identified by satellite ID) that can service the list of waypoints of the UE, and then determine a suitable EES with a matching satellite ID to serve the UE with longest service time in service provisioning (see, e.g., step 2 of Figure 5). Once the ECS identifies the suitable EES, it responds / notifies the EEC with the EES information (see, e.g., step 3 of Figure 5, the Service Provisioning Response shown in Table 3 below, which contains a list of EDN configuration information, and the example EDN Configuration Information shown in Table 4 below). In addition, the corresponding ECS selected satellite frequency band and satellite ID is sent to the EEC for steering satellite selection for UE's traffic (i.e. EEC-EES traffic over EDGE-1 and AC-EAS traffic) towards selected EDN.

[0091] NOTE 2: For EDGE-4 traffic between the EEC and ECS, it can also be routed via the newly selected satellite.III. Enhanced TS 23.558 Service Provisioning Information Tables

[0092] To address the item 5 of the list above (i.e., A method in ECS to assist satellite (and frequency band) selection in the UE, for carrying application traffic towards EDN in the selected satellite), please find details above in Section 11(C). Examples of the related messages and information elements are shown in Tables 2, 3, and 4 below which are enhanced versions of Tables 8.3.3.3.2-1, 8.3.3.3.3-1, and 8.3.3.3.3-2 of 3GPP TS 23.558.Table 2: Enhanced Table 8.3.3.3.2-1 (Service provisioning request)Table 3: Enhanced version of Table 8.3.3.3.3-1 (Service provisioning response)Table 4: Enhanced version of Table 8.3.3.3.3-2 (EDN configuration information)

[0093] NOTE: The same impact applies for Service provisioning subscription request and notification.

[0094] Below table summarizes the information being considered in EAS discovery, and applicability for different satellite types, and corresponding limitations.Satellite ID exposure from a Core network:Another aspect addressed in this document is that the ECS or other AF in Edge network obtains the satellite identifier (ID) information for a Protocol Data Unit (PDU) session from the telecommunication system (e.g., 3GPP 5G Core).Systems and methods are disclosed herein for exposing a satellite ID (e.g., a satellite ID (e.g., NORAD ID) of a satellite in which a satellite EDN (e.g., EES and EAS(s) of a satellite EDN associated to (e.g., used by) the PDU session is deployed. In this regard, two options are described. One option is to expose the satellite ID via an AMF UE mobility event. Another option is to expose the satellite ID via an SMF Event for the PDU session.The satellite ID is available in multiple nodes in core network (e.g., 5GC or EPC or 6G core) of the mobile network. As such, in the present disclosure, embodiments relatedto two possible options to expose the satellite ID to AF are disclosed. More specifically, in one option, the existing UE mobility Information Element (IE) is reused with addition of satellite ID as a new attribute via AMF / NEF. In another option, the existing SMF event is reused with the addition of satellite ID as a new attribute via SMF / NEF.In another embodiment, the satellite ID can also be exposed via PCF for a UE and PCF for a PDU session, respectively, either together with satellite backhaul change or as a standalone event report.Certain embodiments herein for Satellite ID exposure have one or more of the following technical advantages such as enabling the Application Function (AF) to get insight about the satellite ID of the satellite through which access is provided to the UE so that application-level logic can be built based on satellite information such as edge computing, etc. Note that satellite ID is a single satellite within a constellation of satellites and is therefore different from satellite constellation.Now, a more detailed description of each of the options, denoted herein as "Option 1" (expose the satellite ID via an AMF UE mobility event) and "Option 2" (expose the satellite ID via an SMF Event for the PDU session) are described within the context of 5G with impact on 5G standard citations. However, it will be apparent to a skilled person that similar functionalities apply to 6G systems expected to have equivalent network functions as 5G.Option 1: AMF Event ExposureIf a UE is accessing a gNB with satellite backhaul and, based on configuration, the AMF may determine the GEO Satellite ID of the satellite serving the UE, then the Satellite ID can be exposed as part of a UE mobility event notification.In this regard, Figure 6 illustrates a procedure for satellite ID exposure via an AMF event exposure in accordance with one example embodiment of the present disclosure. In this example, the serving gNB of the UE is switched from a ground gNB (a gNB deployed on the ground) to a satellite gNB (a gNB deployed on a satellite). The steps of the procedure of Figure 6 are as follows.For the procedure of Figure 6, the ECS (AF) has subscribed to satellite backhaul category change notifications via PCF / NEF.Step 1: The UE sends a request to the AMF to create a PDU session with a satellite backhaul.Step 2: The AMF obtains a satellite ID of a serving satellite for the requested PDU session for the UE (e.g., based on a location of the UE and ephemeris data of the satellite). This satellite ID is also referred to herein as the serving satellite ID.Step 3: The AMF notifies the PCF of a satellite backhaul category change for the UE. In other words, the AMF notifies the PCT that the UE or PDU session is using a satellite backhaul. As discussed below, in one variant of this embodiment, the notification includes the serving satellite ID.The AMF creates the PDU session and notifies the SMF of the created PDU session.Step 4: The PCF notifies the ECS of the satellite backhaul change.There are two ways to expose satellite ID from AMF to AF. These two ways are referred to below as "Variant 1" and "Variant 2" of Option 1.• Variant 1: In this variant, the AMF exposes the serving satellite ID to the PCF for the UE in step 3. Then, the PCF for the UE further exposes the serving satellite ID in the satellite backhaul category change to the AF (the ECS in the illustrated example) (or via NEF to the AF) in step 4.• Variant 2: In this variant, the serving satellite ID is exposed from the AMF directly to the AF (i.e., the ECS in the illustrated example) in UE location change monitoring event. In this regard, Figure 2 illustrates two alternatives, namely, a first alternative ("Alternative 1") in which the AMF interacts directly with the AF (i.e., the ECS in the illustrated example), and a second alternative ("Alternative 2") in which the AMF interacts with the AF (i.e., the ECS in the illustrated example) via the NEF. More specifically: o Alternative 1: The ECS sends a request for a UE mobility report to the AMF (step 5), and the AMF responds with UE mobility information including the serving satellite ID (step 6). o Alternative 2: The ECS sends a request for a mobility monitoring event to the NEF which in turn sends a request for UE mobility information to the AMF (steps 7 and 8). The AMF responds to the NEF with UE mobility information including the serving satellite ID (step 9), and the NEF then sends location information including the serving satellite ID to the ECS (step 10).Step 11: The AF extracts the serving satellite ID from the received information and may performs one or more actions based on the serving satellite ID. In this example, the AFis the ECS, and the one or more actions include performing Application Context Relocation (ACR) procedure or a session continuity related procedure, based on the satellite ID.NOTE: In Variant 2 above, the PCF for the UE is skipped. The AF subscribes to UDM for UE location change, and the UDM further subscribes to AMF for UE location change. The AF / NEF can also subscribe to AMF (as shown in step 5 or 8) directly after knowing which AMF is serving the UE by querying UDM.NOTE: ECS is used as AF example in Figure 2.The following is a proposed modification to 3GPP TS 23.501 clause 5.3.4.4 UE mobility event notification, illustrated herein in bold, underlined, and italicized text)-.5.3.4.4 UE mobility event notification5G System supports the functionality of tracking and reporting UE mobility events.The AMF provides the UE mobility related event reporting to NF that has been authorized to subscribe to the UE mobility event reporting service. Any NF service consumer such as SMF, NEF, TSCTSF or NWDAF that wants to be reported on the UE location is able to subscribe to the UE mobility event notification service to the AMF with the following parameters:Event reporting type that specifies what to be reported on UE mobility (e.g. UE location, UE mobility on Area of Interest).Event filters indicating the:Area Of Interest that specifies a location area within 3GPP system. The Area Of Interest is represented by a list of Tracking Areas, list of cells or list of (R)AN node identifiers. In the case of EADN, the event consumer (e.g. SMF) provides the "LADN DNN" or "LADN DNN and S-NSSAI" to refer the LADN service area as the Area Of Interest. In the case of PRA, the event consumer (e.g. SMF or PCF) may provide an identifier for Area Of Interest to refer predefined area as the Area Of Interest. In the case of Partial Network Slice Support and Support for Network Slices with Network Slice Area of Service not matching deployed Tracking Areas as described in clauses 5.15.17 and 5.15.18, the event consumer (e.g. SMF) provides the S-NSSAI to refer the slice restriction area (area restriction applies for the S-NSSAI) as the Area Of Interest.The Area Of Interest may include a "RAN timing synchronization status change event" indicator, indicating that the presence in Area of Interest can be determined based on the most recent N2 connection.- The Area Of Interest may include an "Adjust Aol based on RA” indicator, indicating that the Area of Interest may be adjusted depending on UE's RA.The Area Of Interest may include the "Notify the consumer considering UE identity" indicator, containing a list of UE identities or Internal Group ID, and informing the AMF to notify the NF consumer about Area of Interest events only if an event is for the UE belonging to the provided list UEs. The indicator may be included when the request is targeted to Any UE.The Area Of Interest may include the "Notify the consumer considering DNN / S-NSSAI" indicator, containing one or more DNN(s) / S-NSSAI(s) and informing the AMF to notify the NF consumer about Area of Interest events only if an event is for the UE having a PDU sessions established for the specified DNN(s) / S-NSSAI(s).S-NSSAI and optionally the NSI ID(s).Event Reporting Information: event reporting mode, number of reports, maximum duration of reporting, event reporting condition (e.g. when the target UE moved into a specified Area Of Interest, immediate reporting flag).Notification Endpoint of NF service consumer to be notified.The target of event reporting that indicates a (list of) specific UE(s), a group of UE(s) or any UE (i.e. all UEs served by the AMF). Further details on the information provided by the NF service consumer are provided in clause 4.15 of TS 23.502 [3],If an NF service consumer subscribes to the UE mobility event notification service provided by AMF for reporting of UE presence in Area Of Interest, the AMF tracks UE's location considering UE's CM state and using NG -RAN procedures (if RRCJNACTIVE state applies to NG-RAN) in order to determine the UE presence in the Area Of Interest, as described in clause 4.15.4.2 of TS 23.502 [3]. Upon detecting the change of the UE presence in the Area Of Interest, the AMF notifies the UE presence in the Area Of Interest and the new UE location to the subscribed NF service consumer.If the Area Of Interest in the subscription to the UE mobility event notification includes "RAN timing synchronization status change event" indicator as described in Table 5.2.2.3.1-1 of TS 23.502 [3], and the registration request from the UE includes a UE 5GMM Core Network Capability with an indication for "support for network reconnection due to RAN timing synchronization status change " as described in clause 5.4.4.a, the AMF reports the UE presence in Area of Interest based on the most recent N2 connection as described in Annex D of TS 23.502 [3],If the Area Of Interest in the subscription to the UE mobility event notification includes "Adjust Aol based on RA" indicator as described in Table 5.2.2.3.1-1 in TS 23.502 [3], the AMF reports the UE presence in Area of Interest based on the most recent N2 connection as described in Annex D in TS 23.502 [3].When the AMF is changed, the subscription of mobility event for a UE or group of UEs is transferred from the old AMF. Subscriptions targeted to Any UE shall not be moved to another AMF due to UE mobility. The new AMF may decide not to notify the SMF with the current status related to the subscription of mobility event if the new AMF determines that, based on MM Context of the UE, the event is reported by the old AMF.In the network deployment where a UE may leave or enter the Area Of Interest without any notification to the 5GC in CM-CONNECTED state (i.e. in the case that RRCJNACTIVE state applies to the NG-RAN), the AMF may initiate the NG-RAN location reporting as described in clause 5.4.7 or N2 Notification as described in clause 4.8.3 of TS 23.502 [3] to track the UE presence in the Area Of Interest.In the network deployment where a UE access sNB with satellite backhaul, if the AMF is aware of the Geo satellite ID which is serving the UE, then the AMF needs to include the satellite ID as part of the location notification.The AMF may provide UE mobility event reporting to PCF, using Policy Control Request Triggers defined in TS 23.503

[0045] ,The following is a proposed modification to 3GPP TS 23.502 clause 4.16.11.1 for UE policy association establishment represented in Figure 7 are illustrated in bold, underlined, and italicized text.4.16.11.1 GeneralThe UE Policy Association Establishment procedure, which may be performed for a UE registered in the same AMF or different AMFs for 3GPP access and non-3GPP access, concerns the following scenarios:1. UE initial registration with the network.2. The AMF relocation with PCF change in handover procedure and registration procedure.3. UE registration with 5GS when the UE moves from EPS to 5GS and there is no existing UE Policy Association between AMF and PCF for this UE.In Non-roaming case, the H-PCF may interact with the CHF in HPLMN to make a decision about UE Policies based on spending limits.[REPRODUCED HEREIN AS FIGURE 7]Figure 4.16.11-1 : UE Policy Association Establishment(The following is a description of the steps according to Figure 7)This procedure concerns both roaming and non-roaming scenarios.In the non-roaming case the V-PCF is not involved and the role of the H-PCF is performed by the PCF. For the roaming scenarios, the V-PCF interacts with the AMF and the H-PCF interacts with the V-PCF:1. The AMF establishes UE Policy Association with the (V-)PCF when a UE Policy Container is received from the UE. If a UE Policy Container is not received from the UE, the AMF may establish UE Policy Association with the (V-)PCF based on AMF local configuration.NOTE 1: In roaming scenario, the AMF local configuration can indicate whether UE Policy delivery is needed based on the roaming agreement with home PLMN of the UE.2. The AMF sends a Npcf_UEPolicyControl Create Request with the following information: SUPI, may include Access Type and RAT, PEI, ULI, UE time zone, Serving Network (PLMN ID, or PLMN ID and NID, see clause 5.34 of TS 23.501 [2]), the Internal-Group-ID-list and UE Policy Container (the list of stored PSIs, operating system identifier, Indication of UE support for ANDSP, indication of UE capability of reporting URSP rule enforcement to network). In roaming scenario, based on operator policies, the AMF may provide to the V-PCF the PCF ID of the selected H-PCF. The V-PCF contacts the H-PCF. In roaming case, steps 3 and 4 are executed, otherwise step 5 follows.If the AMF, based on configuration, is aware that the UE is accessing over a gNB using satellite backhaul, the AMF includes the Satellite Backhaul Category and satellite ID as described in clause 5.43 of TS 23.501 [2],3. The V-PCF forwards the information received from AMF in step 2 to the H-PCF. When a UE Policy Container is received at initial registration, the H-PCF may store the PEI, the OSId, indication of UE capability of reporting URSP rule enforcement to network or the indication of UE support for ANDSP in the UDR using Nudr_DM_Create including DataSet "Policy Data" and Data Subset "UE context policy control data".The V-PCF may retrieve the Application guidance on URSP Rule for inbound roamers of the PLMN of the SUPI, if not available, using Nudr_DM_Query or Nudr_DM_Subscribe including the Data Set "Application Data" and Data Subset "Service Specific Information" and DataKey set to "PLMN ID(s) of inbound roamers".The V-PCF may retrieve the Application guidance on URSP Rule for inbound roamers of the PLMN of the SUPI, if not available, using Nudr_DM_Query or Nudr_DM_Subscribe including the Data Set "Application.4. The H-PCF sends a Npcf_UEPolicyControl Create Response to the V-PCF. The H-PCF may provide the Policy Control Request Trigger parameters in the Npcf_UEPolicyControl Create Response. Before sending the response, the H-PCF may determine that the decision about UE policy control depends on the status of the policy counters available at the CHF and if such reporting is not established for the subscriber, the H-PCF initiates an Initial Spending Limit Report Retrieval as defined in clause 4.16.8.2. If policy counter status reporting is already established for the subscriber and the H-PCF determines that the status of additional policy counters are required, the H-PCF initiates an Intermediate Spending Limit Report Retrieval as defined in clause 4.16.8.3.The (H-)PCF in roaming and the PCF in non-roaming may register to the BSF as the PCF serving this UE, if not already registered at the AM Policy Association establishment. This is performed by using the Nbsf_Management_Register operation, providing as inputs the UE SUPI / GPSI and the PCF identity.5. The (V-) PCF sends a Npcf_UEPolicyControl Create Response to the AMF. The (V-)PCF relays the Policy Control Request Trigger parameters in the Npcf_UEPolicyControl Create Response.The (V-)PCF also subscribes to notification of N1 message delivery of policy information to the UE using Namf_Communication_NlN2MessageSubscribe service which is not shown in this figure.6. The (H-)PCF gets policy subscription related information and the latest list of PSIs from the UDR using Nudr_DM_Query service operation (SUPI, Policy Data, UE context policy control data, Policy Set Entry) if either or both are not available and makes a policy decision. The (H-)PCF may get the PEI, the OSId, indication of UE capability of reporting URSP rule enforcement to network or the indication of UE support for ANDSP in the UDR using Nudr_DM_Query including DataSet "Policy Data" and Data Subset "UE context policy control data" if the AMF relocates and the PCF changes. In the roaming scenario, the H-PCF may provide the indication of UE support for ANDSP to the V -PCF, if the indication was not present in the Npcf_UEPolicyControl Create request from V -PCF and the H-PCF gets this information from the H-UDR. The (H-)PCF may get the 5G VN group data and 5G VN group membership for each Internal-Group-ID received from the AMF using Nudr_DM_Query (Internal -Group-Id, Subscription Data, 5G VN Group Configuration). The (H-)PCF may store the 5G VN group data and 5G VN group membership for later use for other SUPIs that belong to the same Internal-Group-ID. The (H-)PCF may request notifications from the UDR on changes in the subscription information by invoking Nudr_DM_Subscribe (Policy Data, SUPI, DNN, S-NSSAI, Notification Target Address (+ Notification Correlation Id), Event Reporting Information (continuous reporting), UE context policy control data) service. The (H-)PCF may request notifications from the UDR on changes in the 5G VN group data or 5G VN group membership associated to each of the Internal-Group-Id provided to the PCF by invoking Nudr_DM_Subscribe (Subscription Data, 5G VN Group Configuration, Internal Group ID, Notification Target Address (+ Notification Correlation Id), Event Reporting Information (continuous reporting)) service. The (H-)PCF creates the UE policy container including UE policy information as defined in clause 6.6 of TS 23.503

[0020] and in the case of roaming H-PCF provides the UE policy container in the Npcf_UEPolicyControl UpdateNotify Request. In the non-roaming case, the PCF may subscribe to Analytics from NWDAF as defined in clause 6.1.1.3 of TS 23.503

[0020] .7. The V-PCF sends a response to H-PCF using Npcf_UEPolicyControl UpdateNotify Response.NOTE 2: Step 6 (and step 7) can be omitted. Then the (H-)PCF creates the UE policy container including UE polices in step 2 (in the case of non-roaming) or step 3 (in the case of roaming). This means that the potential interactions with UDR as in step 6 will have to be executed in step 2 (non-roaming) or step 3 (roaming).8. The (V-)PCF triggers UE Configuration Update Procedure in clause 4.2.4.3 to sends the UE policy container including UE policy information to the UE. The (V -)PCF checks the size limit as described in clause 6.1.2.2.2 of TS 23.503

[0020] ,9. If the V-PCF received notification of the reception of the UE Policy container then the V-PCF forwards the notification response of the UE to the H-PCF using Npcf_UEPolicyControl_Update Request.If the V-PCF is notified by the V-UDR about the Service Specific Information applicable to inbound roamers from the HPLMN of the UE as specified in clause 4.15.6.10, the V-PCF provides the Service Parameters to the H-PCF.10. The H-PCF sends a response to the V-PCF. If the V-PCF received a UE Policy Container step 8 will follow.The following is a proposed modification to TS 23.503 clause 6.1.2.5 for PCRT relevant to AMF as illustrated in bold, underlined, and italicized text6.1 .2.5 Policy Control Request Triggers relevant for AMFThe Policy Control Request Triggers relevant for AMF are listed in the tables below and define the conditions when the AMF shall interact again with PCF after the AM Policy Association Establishment or UE Policy Association Establishment.The PCF provides Policy Control Request Triggers to the AMF indicating a specific UE (i.e. SUPI or PEI) in the Policy Association establishment and modification procedures defined in the TS 23.502 [3], The Policy Control Request Triggers are transferred from the old AMF to the new AMF when the AMF changes.The Policy Control Request Triggers are not applicable any longer at termination of the AM Policy Association or termination of UE Policy Association.Table 6.1.2.5-1 : Policy Control Request Triggers relevant for AMF and 3GPP access type[omitted part]The NWDAF info change trigger shall trigger the AMF to interact with the PCF when the list of NWDAF Instance IDs used for the UE or associated Analytics IDs used for the UE at the AMF are changed in the AMF. If the Satellite backhaul category change and! or satellite ID trigger is armed, the AMF shall report the satellite backhaul category or the change between satellite backhaul and non-satellite backhaul to the PCF. If satellite servingthe UE is ehanged, the AMF shall report the satellite ID to the PCF. The PCF may take this into account to update UE Policy as defined in clause 6.1.2.2.The AMF indicates a PCRT corresponding to wrong non-3GPP access when the UE has connected to a non-3GPP access that is not supporting the configured NSS AL The AMF also indicates whether it is for untrusted or trusted non-3GPP access. This triggers the PCF to update the relevant policies on the UE e.g. WLANSP or Non-3GPP access network selection information.If the LBO Information change is armed, the AMF shall report the LBO Information (i.e. DNN(s) and / or S- NSSAI(s) that are allowed in VPLMN for LBO roaming in SMF Selection Data) to the PCF when there is change in the LBO Information.If the Access Type change trigger is met, the AMF reports the changed, the added or the removed Access Type to the PCF.Option 2: SMF Event ExposureIn Option 2, a UE is accessing a gNB with satellite backhaul and, based on configuration, the AMF may determine the GEO Satellite ID of the satellite serving the UE and send the Satellite ID to the SMF. If GEO satellite ID changes, e.g. due to UE handover to an gNB using different GEO satellite as part of backhaul, the AMF may update the latest GEO Satellite ID to the SMF. Thus, in Option 2, the SMF is enhanced to support satellite ID exposure via SMF events.In this regard, Figure 8 illustrates a procedure for satellite ID exposure via SMF event exposure in accordance with another example embodiment of the present disclosure. The steps of the procedure of Figure 8 are as follows:For the procedure of Figure 6, the ECS (or AF) has subscribed to satellite backhaul category change notifications via PCF / NEF.Step 1: The UE sends a request to the AMF to create a PDU session with a satellite backhaul.Step 2: The AMF obtains a satellite ID of a serving satellite for the requested PDU session for the UE (e.g., based on a location of the UE and ephemeris data of the satellite). This satellite ID is also referred to herein as the serving satellite ID.Step 3: The AMF sends a request to the SMF to create, for the requested PDU session, a PDU session context with the serving satellite ID.Step 4: The SMF performs UPF selection and session establishment.Step 5: The SMF notifies the PCF of a satellite backhaul category change that indicates a satellite backhaul.Step 6: The PCF notifies the AF (i.e., the ECS in the illustrated example) of the UE satellite backhaul category change to a satellite backhaul.There are two ways to expose satellite ID from SMF to AF. These two ways are referred to below as "Variant 1" and "Variant 2" of Option 2.• Variant 1: In this variant, the SMF exposes the serving satellite ID to the PCF for the PDU session in step 5, and then the PCF for the PDU session further exposes the satellite ID in the satellite backhaul category change notification sent to the AF (or via NEF to the AF) in step 6.• Variant 2: In this variant, the serving satellite ID is exposed from the SMF directly to the AF (i.e., the ECS in the illustrated example) in a PDU session status change event. In this regard, Figure 4 illustrates two alternatives, namely, a first alternative ("Alternative 1") in which the SMF interacts directly with the AF (i.e., the ECS in the illustrated example), and a second alternative C'Alternative 2") in which the SMF interacts with the AF (i.e., the ECS in the illustrated example) via the NEF. More specifically: o Alternative 1: The ECS sends a request for a SMF event to the SMF (step 7), and the SMF responds with an SMF event notification including the serving satellite ID (step 8). o Alternative 2: The ECS sends a request for PDN connection related information to the NEF which in turn sends a request for an SMF event to the SMF (steps 9 and 10). The SMF responds to the NEF with an SMF event notification including the serving satellite ID (step 11), and the NEF then sends PDN connection information including the serving satellite ID to the ECS (step 12).Thus, the satellite ID is exposed to the AF in step 8 or step 12 (if NEF is used)Step 13: The AF extracts the serving satellite ID from the received information and may performs one or more actions based on the serving satellite ID. In this example, the AF is the ECS, and the one or more actions include performing Application Context Relocation (ACR) procedure or a session continuity related procedure, based on the satellite ID.NOTE: in case Variant 2 of Option 2, the PCF for the PDU session is skipped. The AF subscribes to UDM for PDU session status change, and the UDM further subscribes to SMF for PDU session status change event. The AF / NEF can also subscribe to SMF (asshown in step 7 or 10) directly after knowing which SMF is serving the LIE'S PDll session by querying UDM.The following is a proposed modification to 3GPP TS 23.502 clause 5.2.8.3.1 for SMF event exposure as illustrated in bold, underlined, and italicized text} -.5.2.8.3.1 GeneralService description: This service provides events related to PDU Sessions towards consumer NF. The service operations exposed by this service allow other NFs to subscribe and get notified of events happening on PDU Sessions. The following are the key functionalities of this NF service.Allow consumer NFs to Subscribe and unsubscribe for an Event ID on PDU Session(s);- Allow the NWDAF to collect data for network data analytics from SMF as specified in TS 23.288

[0050] and from UPF as specified in clause 4.15.4.5;Notifying events on the PDU Session to the subscribed NFs; andAllow consumer NFs to acknowledge or respond to an event notification.The following events can be subscribed by a NF consumer (Event ID is defined in clause 4.15.1):UE IP address / Prefix allocation / change: The event notification may contain a new UE IP address / Prefix or an indication of which UE IP address / Prefix has been released.PDU Session Establishment and / or PDU Session Release.The event notification may contain following information:- PDU Session Type.- DNN.- UE IP address / Prefix.UP path change: a notification corresponding to this event is sent when the UE IP address / Prefix and / or DNAI and / or the N6 traffic routing information has changed.The event notification may contain following information:- the type of notification ("EARLY" or "LATE”). for both the source and target UP path between the UE and the DN, the corresponding information is provided when it has changed:- DNAI.- UE IP address / Prefix.N6 traffic routing information.- Candidate DNAI(s) for the PDU Session.Change of common E AS .NOTE 1: UP path change notification, DNAI and N6 traffic routing information are further described in clause 5.6.7 of TS 23.501 [2],QoS Monitoring: the event notification may contain the QoS Monitoring report for the QoS parameter(s) to be measured defined in clause 5.45 of TS 23.501 [2], Implicit subscription of the PCF on behalf of the NEF / AF as part of setting PCC rule(s) may trigger SMF to send this event notification.Change of Access Type; The event notification contains the new Access Type for the PDU Session. For MA PDU Session the Change of Access Type may include two Access Type information that the user is currently using.Change of RAT Type; the event notification contains the new RAT Type for the PDU Session.PLMN change; The event notification contains the new PLMN Identifier for the PDU Session.Change of satellite backhaul category and / or satellite ID; The event notification contains the new satellite backhaul category and / or satellite ID for the PDU session.Downlink data delivery status. The event notification contains the status of downlink data buffering in the core network including:First downlink packet per source of the downlink IP traffic in extended buffering and Estimated maximum wait time.First downlink packet per source of the downlink IP traffic discarded.First downlink packet per source of the downlink IP traffic transmitted after previous buffering and / or discarding of corresponding packet(s).QFI allocation: The event notification is sent when a new QoS flow is established within a PDU session and contains:If the Target of Event Reporting is a PDU session, both the allocated QFI and either one of the following (Application Identifier or IP Packet Filter Set or Ethernet Packet Filter Set). The 5QI corresponding to the QoS flow and the DNN, S-NSSAI corresponding to the PDU session are also sent.If the Target of Event Reporting is a SUPI, both the allocated QFI and either one of the following (Application Identifier or IP Packet Filter Set or Ethernet Packet Filter Set) for each PDU session ID established for this SUPI. The 5QI corresponding to the QoS flow and the DNN, S-NSSAI corresponding to each PDU session are also sent.If the Target of Event Reporting is an Internal-Group-Id or any UE, multiple instances of the tuple (allocated QFI and either one of the following (Application Identifier or IP Packet Filter Set or Ethernet Packet Filter Set). PDU session ID, SUPI). The 5QI corresponding to the QoS flow and the DNN, S- NSSAI corresponding to each PDU session are also sent.Total number of Session Management transactions:The total number of Session Management transaction is used to collect the number of SM transactions of a SUPI or Internal Group ID, for example Dispersion Analytics as specified in TS 23.288

[0050] , The transaction count is incremented when the NAS transactions from PDU Session Establishment, PDU Session Authentication, PDU Session Modification and PDU Session Release procedures is concluded. Only the periodic reporting mode applies.Information on PDU Session for WLAN (i.e. Access Type is Non-3GPP and RAT Type is TRUSTED_WLAN).NOTE 2: When the consumer NF is the NWDAF, the event QFI allocation is used to collect data for Observed Service Experience analytics, UE communication analytics, QoS Sustainability analytics and end-to- end data volume transfer time analytics as specified in TS 23.288

[0050] .User plane status information: The event notification contains:- PDU Session ID.- User Plane Inactivity Timer (as specified in TS 29.244

[0069] ).PDU Session status (activated, deactivated).NOTE 3: When the consumer NF is the NWDAF, the event user plane status information is used to collect data for UE Communication analytics as specified in TS 23.288

[0050] ,Session Management Congestion Control Experience for PDU Session: The event notification contains the data related to Session Management Congestion Control experience per PDU Session as described in TS 23.288

[0050] .UE session behaviour trends (see clause 4.15.4.3);UE communications trends (see clause 4.15.4.3);UP with redundant transmission: the event notification indicates if redundant transmission (see clause 5.33.2.2 of TS 23.501 [2]) has been activated or not for the PDU session;User Data Usage Measures (see clause 4.15.4.5): SMF conveys the subscription to UPF on behalf of the consumer. Consumer receives the events directly from UPF; andUser Data Usage Trends (see clause 4.15.4.5): SMF conveys the subscription to UPF on behalf of the consumer. Consumer receives the events directly from UPF.When the consumer NF is the NWDAF, the event Information on PDU Session for WLAN is used to collect data for WLAN performance analytics as specified in TS 23.288

[0050] .When the consumer NF is the NWDAF, the event Session Management Congestion Control Experience for PDU Session is used to collect data for Session Management Congestion Control Experience analytics as specified in TS 23.288

[0050] ,[rest omitted]The following is a proposed modification to to 3GPP TS 23.503 clause 6.1.3.5 for PCRT relevant to SMF as illustrated in bold, underlined, and italicized text}-.6.1 .3.5 Policy Control Request Triggers relevant for SMFThe Policy Control Request Triggers relevant for SMF define the conditions when the SMF shall interact again with PCF after a PDU Session establishment as defined in the Session Management Policy Establishment and Session Management Policy Modification procedure as defined in TS 23.502 [3].The PCR triggers are not applicable any longer at termination of the SM Policy Association.The access independent Policy Control Request Triggers relevant for SMF are listed in table 6.1.3.5-1.The differences with table 6.2 and table A.4.3-2 in TS 23.203 [4] are shown, either "none" means that the parameter applies in 5GS or "removed" meaning that the parameter does not apply in 5GS, this is due to the lack of support in the 5GS for this feature or "modified" meaning that the parameter applies with some modifications defined in the parameter.Table 6.1.3.5-1 : Access independent Policy Control Request Triggers relevant for SMF [Table truncated][omitted part]The QoS constraints change trigger shall trigger a SMF interaction with the PCF if QoS constraints are received by the SMF during the lifetime of the PDU Session. The SMF reports that the QoS constraints change trigger was met and the new QoS constraints.When the Satellite backhaul category change and / or satellite ID change trigger is armed, the SMF reports to the PCF that the Satellite backhaul category change was met and the new satellite backhaul category (or that satellite backhaul is no longer used) when it becomes aware that there is a change of the backhaul which is used for the PDU Session between satellite backhaul categories, or between satellite backhaul and a non-satellite backhaul. The SMF determines whether or not a satellite backhaul is used and whether there is a change of backhaul based on signalling from the AMF as specified in TS 23.501 [2], If satellite serving the UE is changed, the SMF shall report the satellite ID to the PCF.NOTE 12: As specified in clause 5.43.4 of TS 23.501 [2], satellite backhaul category refers to the type of the satellite used in the backhaul. Only a single backhaul category can be indicated.The NWDAF info change trigger shall trigger the SMF to interact with the PCF when the list of NWDAF Instance IDs used for the PDU Session or associated Analytics IDs used for the PDU Session are changed in the SMF.[omitted part]The following is a proposed modification to to 3GPP TS 23.503 clause 6.1.3.18 Event reporting from the PCF as illustrated in bold, underlined, and italicized text .6.1 .3.18 Event reporting from the PCFThe AF may subscribe / unsubscribe to notifications of events from the PCF for the PDU Session to which the AF session is bound. The AF can either subscribe / unsubscribe directly at the PCF or indirectly via an NEF or a TSCTSF.The PCF for the UE may subscribe / unsubscribe to notifications of events from the PCF for the PDU Session of a UE. Other NFs may subscribe / unsubscribe to notifications of events from the PCF for a PDU Session or for a UEThe events that can be subscribed by the AF and by other NFs are listed in Table 6.1.3.18-1.Table 6.1.3.18-1 : Events relevant for reporting from the PCF [table truncated]If an AF requests the PCF to report the PLMN identifier where the UE is currently located, then the PCF shall provide the PLMN identifier or the SNPN identifier to the AF if available. Otherwise, the PCF shall provision the corresponding PCC rules, and the Policy Control Request Trigger to report PLMN change to the SMF. The PCF shall, upon receiving the PLMN identifier or the SNPN identifier from the SMF forward this information to the AF, including the PLMN Id and if available the NID. If the H-PCF requests to report the PLMN identifier where the UE is currently located, the V-PCF provisions the PCRT on "PLMN change" to the AMF as described in clause 6.1.2.5 and then forwards the PLMN ID received from the AMF to the H-PCF.[omitted part]If an AF requests the PCF to report Start of application traffic detection and Stop of application traffic detection via bulk subscription, the AF shall provide the application identifier together with the S-NSSAI and DNN. The PCF provides a PCC rule for the application identifier together with the corresponding Policy Control Request Trigger to the SMF for every PDU Session to this S-NSSAI and DNN. When the PCF receives start of application traffic detection event or stop of application traffic detection event for the PCC rule in a PDU Session, the PCF forwards the event to the AF together with the UE identifier and optionally the IP address of the PDU Session corresponding to this PCC rule. When the AF removes bulk subscription for this application identifier, then the PCF removes the Policy Control Request Trigger from the SMF for every PDU Session to this S-NSSAN and DNN, if it is not used for other purpose.NOTE 7: The restriction of the bulk subscription to a specific combination of S-NSSAI and DNN avoids excessive signalling load.If an AF requests the PCF to report on the change between different satellite backhaul categories (as specified in clause 5.43.4 of TS 23.501 [2]) or the change between satellite backhaul and non-satellite backhaul and / or the change between satellites, the PCF shall provide the corresponding Policy Control Request Trigger to the SMF to enable the report of satellite backhaul category change and / or satellite ID change (see clause 6.1.3.5) to the PCF. The PCF shall, upon reception of information about the change between satellite backhaul categories or change between satellite backhaul and non-satellite backhaul and / or the change between satellites, notify the AF on the satellite backhaul category change and / or satellite ID change event was met and forward the current satellite backhaul category and / or satellite ID information received from the SMF to the AF, or indicate that a satellite backhaul is no longer used.If 5G DDNMF requests the PCF to report on the Change of PDUID, the PCF shall notify whenever a new PDUID is allocated. Further details on how the 5G DDNMF retrieves and subscribes to notifications on Change of PDUID are defined in TS 23.304

[0034] ,[omitted part]Further Description

[0095] Figure 9 is a schematic block diagram of a network node 600 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 600 may be, for example, a base station (e.g., gNB), a network node implementing a UPF, an AMF, a PCF, a SMF, a network node implementing an EDN or part of an EDN (e.g., EAS or EES), a network node implementing an ECS, or the like. As discussed above, in some embodiments, the network node 600 may be deployed in a satellite (e.g., be part of or carried by a satellite). As illustrated, the network node 600 includes a control system 602 that includes one or more processors 604 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 606, and optionally (e.g., in some embodiments) a network interface 608. The one or more processors 604 are also referred to herein as processing circuitry. In addition, the network node 600 may include one or more radio units 610 that each includes one or more transmitters 612 and one or more receivers 614 coupled to one or more antennas 616. The radio units 610 may be referred to or be part ofradio interface circuitry. In some embodiments, the radio unit(s) 610 is external to the control system 602 and connected to the control system 602 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 610 and potentially the antenna(s) 616 are integrated together with the control system 602. The one or more processors 604 operate to provide one or more functions of the network node 600 as described herein (e.g., one or more functions of a gNB, UPF, satellite-EDN, EAS, EES, ECS, or the like, as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 606 and executed by the one or more processors 604.

[0096] Figure 10 is a schematic block diagram that illustrates a virtualized embodiment of the network node 600 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a "virtualized" network node is an implementation of the network node 600 in which at least a portion of the functionality of the network node 600 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 600 may include the control system 602 and / or the one or more radio units 610, as described above. The control system 602 may be connected to the radio unit(s) 610 via, for example, an optical cable or the like. The network node 600 includes one or more processing nodes 700 coupled to or included as part of a network(s) 702. If present, the control system 602 or the radio unit(s) are connected to the processing node(s) 700 via the network 702. Each processing node 700 includes one or more processors 704 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 706, and a network interface 708.

[0097] In this example, functions 710 of the network node 600 described herein (e.g., one or more functions of a gNB, UPF, an AMF, a PCF, a SMF, a satellite-EDN, EAS, EES, ECS, or the like, as described herein ) are implemented at the one or more processing nodes 700 or distributed across the one or more processing nodes 700 and the control system 602 and / or the radio unit(s) 610 in any desired manner. In some particular embodiments, some or all of the functions 710 of the network node 600 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environ ment(s) hosted by the processing node(s) 700. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 700 and the control system602 is used in order to carry out at least some of the desired functions 710. Notably, in some embodiments, the control system 602 may not be included, in which case the radio unit(s) 610 communicate directly with the processing node(s) 700 via an appropriate network interface(s).

[0098] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 600 or a node (e.g., a processing node 700) implementing one or more of the functions 710 of the network node 600 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0099] Figure 11 is a schematic block diagram of the network node 600 according to some other embodiments of the present disclosure. The network node 600 includes one or more modules 800, each of which is implemented in software. The module(s) 800 provides the functionality of the network node 600 described herein. This discussion is equally applicable to the processing node 700 of Figure 10 where the modules 800 may be implemented at one of the processing nodes 700 or distributed across multiple processing nodes 700 and / or distributed across the processing node(s) 700 and the control system 602.

[0100] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more ofthe techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0101] While processes in the figures may show 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 the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0102] Some example embodiments of the present disclosure are as follows: Embodiment 1. A method performed by an Edge Configuration Server, ECS, for service continuity or initial service provisioning for the ECS) for Edge Data Networks, EDNs, comprising at least one satellite EDN, the method comprising any one or more of the following: detecting (Fig. 4, step 1) a User Equipment, UE, connectivity change for a UE, the UE connectivity change being a connectivity change from a first EDN to a second EDN, the second EDN being a satellite EDN; identifying (Fig. 4, step 2) a target Edge Enabler Server, EES, of a satellite EDN for an Application Context Relocation, ACR, (e.g., an ACR related to the UE connectivity change) based on satellite information registered for the target EES (and, optionally, one or more other parameters such as, e.g., UE connectivity information such as, e.g., backhaul category, satellite ID, etc.); initiating (Fig. 4, step 3) the ACR to an Edge Enabler Client, EEC, with the target EES.Embodiment 2. The method of embodiment 1, wherein the satellite related information registered for the target EES comprises a satellite ID of a satellite on which the EES is deployed.Embodiment 3. The method of embodiment 1 or 2, wherein the satellite related information registered for the target EES comprises any one or more of the following: elevation of the satellite on which the EES is deployed, satellite type (e.g., GEO, MEO, or LEO) of the satellite on which the EES is deployed, and satellite ephemeris information for the satellite on which the EES is deployed.Embodiment 4. The method of any of embodiments 1 to 3, wherein the ECS is subscribed to a core network of the associated cellular communications system to get notified of UE connectivity changes for the UE.Embodiment 5. The method of any of embodiments 1 to 4, further comprising receiving (Fig. 3, step 1), from the target EES, an EES registration request comprising an EES profile of the target EES, and the EES profile of the target EES comprises the satellite related information for the satellite on which the EES is deployed.Embodiment 6. The method of embodiment 5, further comprising storing (Fig. 3, step 2) at least some of the information, including the satellite information, comprised in the EES profile of the target EES.Embodiment 7. The method of embodiment 5 or 6, wherein receiving the EES registration request occurs prior to detecting the UE connectivity change, identifying the target EES, and initiating the ACR to the target EES.Embodiment 8. A network node adapted to perform the method of any of embodiment 1 to 7.Embodiment 9. A method performed by an Edge Enabling Client, EEC, at a User Equipment, UE, for service provisioning, the method comprising any one or more of the following: sending (Fig. 5, step 1) a service provisioning request to an Edge Configuration Server, ECS, wherein the service providing request comprises satellite capability information; receiving (Fig. 5, step 3) a service provisioning response from the ECS.Embodiment 10. The method of embodiment 9, wherein the service provisioning response comprises a list of Edge Data Network, EDN, configuration information for one or more EDNs.Embodiment 11. The method of embodiment 10, wherein the EDN configuration for at least one of the one or more EDNs comprises a satellite selection recommendation (e.g., information that indicates a recommended satellite when using the EDN and / or one or more satellite frequency bands to be used by the UE when using the EDN).Embodiment 12. A network node adapted to perform the method of any of embodiments 9 to 11.Embodiment 13. A method performed by an Edge Enabler Server, EES, of a satellite Edge Data Networks, EDN, the method comprising: sending (Fig. 3, step 1) an EES registration request to an Edge Configuration Server, ECS, wherein the EES registration request comprises an EES profile of the EES, and the EES profile of the EES comprises satellite related information for a satellite on which the EES is deployed.Embodiment 14. The method of embodiment 13, wherein the satellite related information comprised in the EES profile of the EES comprises a satellite ID of the satellite on which the EES is deployed.Embodiment 15. The method of embodiment 13 or 14, wherein the satellite related information comprises any one or more of the following: elevation of the satellite on which the EES is deployed, satellite type (e.g., GEO, MEO, or LEO) of the satellite on which the EES is deployed, and satellite ephemeris information for the satellite on which the EES is deployed.Embodiment 16. The method of any of embodiments 13 to 15, wherein the EES profile of the EES further comprises an dynamic EES service area indication for the EES that indicates that a service area of the EES is dynamic.Embodiment 17. A network node adapted to perform the method of any of embodiments 13 to 16.Embodiment 18. A method performed by a network node of a cellular communications system, the method comprising: obtaining (Fig. 6, step 2; Fig. 6, step 3; Fig. 8, step 3; Fig. 8, step 5) a satellite ID of a serving satellite of a Protocol Data Unit, PDU, session of a User Equipment, UE, having a satellite backhaul; and providing (Fig. 6, step 6 or 9; Fig. 6, step 4; Fig. 8, step 8 or 11; Fig. 8, step 6) the satellite ID to an application function (e.g., either directly or via an exposure function).Embodiment 19. The method of embodiment 18, wherein the network node is an Access and Mobility Management Function, AMF, and: obtaining (Fig. 6, step 2) the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises obtaining (Fig. 6, step 2) the satellite ID at the AMF (e.g., during a process for creating the PDU session having the satellite backhaul); and providing (Fig. 6, step 6) the satellite ID to the application function comprises providing the satellite ID directly to the application function as part of an AMF event notification (e.g., a UE mobility notification).Embodiment 20. The method of embodiment 18, wherein the network node is an Access and Mobility Management Function, AMF, and: obtaining (Fig. 6, step 2) the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises obtaining (Fig. 6, step 2) the satellite ID at the AMF (e.g., during a process for creating the PDU session having the satellite backhaul); and providing (Fig. 6, step 9) the satellite ID to the application function comprises providing the satellite ID to the application function via an exposure function as part of an AMF event notification (e.g., a UE mobility notification).Embodiment 21. The method of embodiment 18, wherein the network node is a Policy and Control Function, PCF, and: obtaining (Fig. 6, step 3) the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises receiving (Fig. 6, step 3) thesatellite ID from an Access and Mobility Management Function, AMF, (e.g., as part of a notification of a satellite backhaul category change); and providing (Fig. 6, step 4) the satellite ID to the application function comprises providing (Fig. 6, step 4) the satellite ID to the application function (e.g., either directly or via an exposure function) as part of a UE satellite backhaul category change notification.Embodiment 22. The method of embodiment 18, wherein the network node is a Session Management Function, SMF, and: obtaining (Fig. 8, step 3) the satellite ID of the serving satellite of the PDll session of the UE having a satellite backhaul comprises receiving (Fig. 8, step 3) the satellite ID from an Access and Mobility Management Function, AMF, (e.g., as part of a request to create a PDU session context for the PDU session); and providing (Fig. 8, step 8) the satellite ID to the application function comprises providing the satellite ID directly to the application function as part of an SMF event notification.Embodiment 23. The method of embodiment 18, wherein the network node is a Session Management Function, SMF, and: obtaining (Fig. 8, step 3) the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises receiving (Fig. 8, step 3) the satellite ID from an Access and Mobility Management Function, AMF, (e.g., as part of a request to create a PDU session context for the PDU session); and providing (Fig. 8, step 11) the satellite ID to the application function comprises providing the satellite ID to the application function via an exposure function as part of an SMF event notification.Embodiment 24. The method of embodiment 18, wherein the network node is a Policy and Control Function, PCF, and: obtaining (Fig. 8, step 5) the satellite ID of the serving satellite of the PDU session of the UE having a satellite backhaul comprises receiving (Fig. 8, step 5) the satellite ID from Session Management Function, SMF, (e.g., as part of a notification of a satellite backhaul category change); andproviding (Fig. 8, step 6) the satellite ID to the application function comprises providing (Fig. 8, step 6) the satellite ID to the application function (e.g., either directly or via an exposure function) as part of a UE satellite backhaul category change notification.

Claims

Claims:

1. A method performed by an Edge Configuration Server, ECS, in an edge data network (EDN), the method comprising any one or more of the following:- monitoring location of a user equipment (UE) and / or moving prediction of the UE;- obtaining a list of satellite identifiers (IDs) of satellites in accordance with the location and / or the UE moving prediction;- identifying an Edge Enabler Server, EES, deployed in a satellite with a satellite ID matching with one of satellite ID in the obtained list of satellite IDs to serve the UE with a longest service time;- sending to the UE a message, the message comprising information of the identified EES and the corresponding satellite ID.

2. The method of claim 1, wherein the step of obtaining the list of satellite ids further comprises querying an external server to obtain the list of satellite IDs in accordance with the location and / or the UE moving prediction.

3. The method of any one of claims 1 to 2, wherein the method further comprises subscribing to a core network of an associated cellular communications system to get notified of location change of the UE.

4. The method of any one of claims 1 to 3, further comprising receiving, from the EES, an EES registration request comprising an EES profile of the EES, and the EES profile comprises the satellite ID of the satellite on which the EES is deployed.

5. The method of claim 4, wherein the step of identifying an Edge Enabler Server, EES, deployed in a satellite with a satellite ID matching with one of satellite IDs in the obtained list of satellite IDs to serve the UE with a longest service time comprises identifying the EES with the EES profile comprising a satellite ID to serve the UE with a longest service time and that matches a satellite ID in the obtained list of satellite IDs.

6. The method of claim 4 or 5, wherein receiving the EES registration request occurs prior to identifying the EES.

7. The method of any one of claims 1 to 6, wherein the method further comprises receiving a request message comprising satellite capability information of the UE and the step of sending the message comprising information of the identified EES and the corresponding satellite ID is executed in response to the request message.

8. A network node adapted to perform the method of any of claims 1 to 7.

9. A method performed by an Edge Enabling Client, EEC, at a User Equipment, UE, for service provisioning, the method comprising: sending a service provisioning request to an Edge Configuration Server, ECS, wherein the service provisioning request comprises satellite capability information comprising at least one of satellite frequency bands and minimum elevation angle; receiving a service provisioning response from the ECS.

10. The method of claim 9, wherein the service provisioning response comprises EES information and corresponding satellite ID of a satellite on which the EES is deployed.

11. The method of claim 9, wherein the service provisioning response comprises a list of Edge Data Network, EDN, configuration information for one or more EDNs.

12. The method of claim 11, wherein the EDN configuration for at least one of the one or more EDNs comprises a satellite selection recommendation.

13. A network node adapted to perform the method of any of claims 9 to 12.

14. A method performed by an Edge Enabler Server, EES, of a satellite Edge Data Network, EDN, the method comprising: sending an EES registration request to an Edge Configuration Server, ECS, wherein the EES registration request comprises an EES profile of the EES, and the EES profile of the EES comprises satellite related information for a satellite on which the EES is deployed wherein the satellite related information comprise the satellite identifier (ID) of the satellite on which the EES is deployed.

15. The method of claim 14, wherein the satellite related information comprises any one or more of the following: elevation of the satellite on which the EES is deployed, satellite type (e.g., GEO, MEO, or LEO) of the satellite on which the EES is deployed, and satellite ephemeris information for the satellite on which the EES is deployed.

16. The method of any of claims 14 to 15, wherein the EES profile of the EES further comprises a dynamic EES service area indication for the EES that indicates that a service area of the EES is dynamic.

17. A network node adapted to perform the method of any of claims 14 to 16.

Images