EAS node and method thereof

Abstract

According to the present invention, an application function (AF) (5) transmits, to a core network (3), a first message pertaining to an event pertaining to a configuration of a user plane path for a PDU Session. Before a first prescribed time ends after the transmission of the first message, if the AF (5) receives, from the core network (3), a second message based on the occurrence of the event, the AF (5) transmits, to the core network (3), a positive response to the second message. Otherwise, the AF (5) transmits, to the core network (3), a third message that indicates a failure in processing the AF (5) corresponding to the event. This enables the application function, a UE, or both to cope with a latency occurring in procedures in the core network for changing the user plane path with respect to, for example, run-time cooperation between the core network and the application function.

Description

[Technical Field]

[0001] The present disclosure relates to wireless communication networks, and more particularly to user plane path control. [Background technology]

[0002] A 5G system (5GS) connects a wireless terminal (user equipment (UE)) to a data network (DN). In the 5G architecture, connectivity services between a UE and a DN are supported by one or more Protocol Data Unit (PDU) Sessions (see, for example, Non-Patent Documents 1 and 2). A PDU Session is an association, session, or connection between a UE and a DN. A PDU Session is used to provide a PDU connectivity service (i.e., exchange of PDUs between a UE and a DN). A PDU Session is established between a UE and a User Plane Function (UPF) (i.e., a PDU Session anchor) to which the UE and the DN are connected. From the perspective of data transfer, a PDU Session consists of a tunnel (N9 tunnel) within a 5G core network (5GC), a tunnel (N3 tunnel) between the 5GC and an access network (AN), and one or more radio bearers.

[0003] Non-Patent Document 1 (e.g., Chapter 5.6.7) and Non-Patent Document 2 (e.g., Chapter 4.3.6) disclose Application Function (AF) influence on traffic routing. AF influence on traffic routing is a control plane solution that enables an AF to provide input to the 5G Core Network (5GC) on how certain traffic should be routed. More specifically, an AF sends a request (hereinafter also referred to as an AF request) to the 5GC to influence the routing decision made by the Session Management Function (SMF) regarding the traffic of a Protocol Data Unit (PDU) session (i.e., one or more QoS Flows). The AF request triggers the SMF to change or select the user plane (UP) path of the PDU session. The change or selection of the UP path includes the change or selection of the DN Access Identifier (DNAI). That is, the AF request influences the User Plane Function (UPF) selection by the SMF, enabling user traffic to be routed to the local access for the DN identified by the DNAI. The UPF selection or UP path change by the SMF includes rearranging (or reselecting) the PDU Session Anchor (PSA) UPF, adding a PSA UPF, and inserting a UL Classifier (ULCL) UPF or Branching Point (BP) UPF into the UP path.

[0004] The Application Function (AF) influence on traffic routing allows the AF to control whether traffic routing is enabled or disabled based on notification of whether a configuration change affecting traffic routing for a specific UE has occurred (UP path management events). The AF sends an AF request to the SMF via the Network Exposure Function (NEF) by calling the Nnef_EventExposure_Subscribe service operation to receive event notification when a routing configuration change occurs for traffic related to a specific UE. Traffic related to a specific UE is specified by a UE identity, or a UE identity and a traffic identity. The UE identity includes, for example, a Subscription Permanent Identifier (SUPI), a Generic Public Subscription Identifier (GPSI), an Internal Group Identifier, or an External Group Identifier. The traffic identity includes, for example, a Data Network Name (DNN). More specifically, the AF request may include a request for subscription to notifications about UP path management events. The AF subscription may be for one or both of early notification and late notification. In the case of an early notification subscription, the SMF sends the notification to the AF directly or via the NEF before the (new) UP path is configured. In the case of a late notification subscription, the SMF sends the notification to the AF directly or via the NEF after the new UP path is configured.

[0005] The Third Generation Partnership Project (3GPP) SA6 working group has begun standardization work on an architecture for enabling edge applications (see, for example, Non-Patent Document 3). This 3GPP architecture is called the EDGEAPP architecture. The EDGEAPP architecture provides a specification of an enabling layer to facilitate communication between application clients (ACs) running on a UE and applications deployed at the edge. According to the EDGEAPP architecture, edge applications provided by Edge Application Servers (EASs) are provided to the ACs of a UE by an Edge Configuration Server (ECS) and an Edge Enabler Server (EES) via the Edge Enabler Client (EEC) of the UE.

[0006] The EDGEAPP architecture supports various Application Context Relocation (ACR) procedures for service continuity. Application context is a set of data related to an AC that resides in an EAS. Application context relocation involves transferring application context from a source EAS (or EDN) to a target EAS (or EDN). The ACR procedure can be triggered by a UE mobility event or a non-UE mobility event. UE mobility events include, for example, intra-EDN mobility, inter-EDN mobility, and Local Area Data Network (LADN)-related mobility. Non-UE mobility events include, for example, EAS or EDN overload conditions and EAS maintenance (e.g., graceful shutdown of the EAS).

[0007] The AF sends an AF request to the Policy Control Function (PCF) directly or via the Network Exposure Function (NEF). The AF request can influence the routing decision by the SMF for the traffic of the PDU Session. The AF request can also include a request for subscription to notifications about UP path management events. The AF subscription may be for either early notification or late notification, or both. In the case of an early notification subscription, the SMF sends a notification to the AF directly or via the NEF before the (new) UP path is configured. In the case of a late notification subscription, the SMF sends a notification to the AF directly or via the NEF after the new UP path is configured.

[0008] 3GPP TS 2.0 (e.g., Chapters 5.6.7.1 and 5.6.7.2) and 3GPP TS 2.0 (e.g., Chapter 4.3.6.3) specify runtime coordination between the 5G Core Network (5GC) and the AF. This contributes to avoiding or minimizing service interruptions during PSA rearrangement (or addition) for Session and Service Continuity (SSC) mode 3 PDU Sessions or PDU Sessions with UL CL or BP. Specifically, an AF request for subscription to notifications of UP path management events (e.g., DNAI change) can optionally include an indication of "AF acknowledgment to be expected." This indication implies that the AF intends to provide a response to the notification of the UP path management event to the 5GC. According to this indication, the SMF waits for a response from the AF in the case of early notification before establishing a new UP path. According to this indication, the SMF waits for a response from the AF before activating the new UP path in case of late notification.

[0009] The AF can confirm the UP path management event indicated in the notification (e.g., DNAI change) by sending a positive response to the notification to the SMF. Alternatively, the AF can reject the UP path management event indicated in the notification (e.g., DNAI change) by sending a negative response to the notification to the SMF. The AF can determine whether application relocation is necessary according to the DNAI change notification. The AF sends a positive response after the application relocation is complete. Alternatively, the AF sends a negative response if the AF determines that the application relocation cannot be completed on time (e.g., due to temporary congestion).

[0010] In the case of early notification, based on the indication of "AF acknowledgment to be expected", the SMF does not set up a UP path to the new DNAI until it receives a positive AF response. In the case of late notification, based on the indication of "AF acknowledgment to be expected", the SMF does not activate a UP path to the new DNAI until it receives a positive AF response. Before the UP path to the new DNAI is activated, application traffic data (if present) continues to be routed to the old DNAI. After the UP path to the new DNAI is activated, the data is routed to the new DNAI. If at any time the SMF receives a negative response, the SMF may continue to use the original DNAI and cancel the relocation or addition of the associated PSA. The SMF may perform DNAI reselection afterwards, if necessary. [Prior art documents] [Non-patent literature]

[0011] [Non-Patent Document 1] 3GPP TS 23.501 V17.0.0 (2021-03) “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System (5GS); Stage 2 (Release 17)”, March 2021 [Non-patent document 2] 3GPP TS 23.502 V17.0.0 (2021-03) “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 17)”, March 2021 [Non-patent document 3] 3GPP TS 23.558 V2.0.0 (2021-03) "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture for enabling Edge Applications; (Release 17)", March 2021 Summary of the Invention [Problem to be solved by the invention]

[0012] As mentioned above, the EDGEAPP architecture supports various ACR procedures for service continuity. Additionally, as mentioned above, runtime coordination between the 5GC and the AF is specified in the 3GPP specifications. As mentioned above, the AF can reject a UP path management event (e.g., DNAI change) indicated in a notification by sending a negative response to the notification to the SMF. For example, the AF sends a negative response if it determines that the application relocation cannot be completed on time (e.g., due to temporary congestion). From these 3GPP specifications, it may be understood that the AF sends a negative response to the 3GPP core network (e.g., SMF) if a delay in the processing or procedures related to application context relocation in the AF or EDN occurs or is expected. This allows the AF to reject a UP path management event (e.g., DNAI change).

[0013] However, even if the process or procedure related to application context relocation in the AF or EDN can be completed successfully, the procedure in the 3GPP core network that establishes (or changes) the UP path for the PDU session (e.g., UPF relocation or addition) may be delayed for some reason. For example, if the relocation of the application context from the Source EAS to the Target EAS is completed but the UP path to access the Target EAS is not established or activated in a timely manner, the AC and Target EAS operating in the UE may not be able to properly continue application layer communication. The current 3GPP specifications may not adequately address this issue. Specifically, it is unclear how the AF should behave when the procedure in the 3GPP core network that establishes (or changes) the UP path for the PDU session (e.g., UPF relocation or addition) is delayed for some reason. It is also unclear how the AF detects that a delay has occurred in the procedure in the 3GPP core network.

[0014] One of the objectives to be achieved by the embodiments disclosed in this specification is to provide an apparatus, a method, and a program that enables an application function or a UE, or both, to address delays that occur in procedures in a core network for setting up (or changing) a user plane path in terms of runtime coordination between the core network and the application function. It should be noted that this objective is only one of multiple objectives to be achieved by multiple embodiments disclosed in this specification. Other objectives or problems and novel features will become apparent from the description of this specification or the accompanying drawings. [Means for solving the problem]

[0015] In a first aspect, an AF node includes a memory and at least one processor coupled to the memory. The at least one processor is configured to transmit a first message to a core network regarding an event related to the establishment of a user plane path for a PDU session. The at least one processor is configured to, if the AF node receives a second message based on the occurrence of the event from the core network before a first predetermined period of time expires after transmission of the first message, transmit a positive response to the second message to the core network. Further, if the AF node does not receive the second message from the core network before the first predetermined period of time expires, transmit a third message to the core network indicating a failure of the AF node's processing corresponding to the event.

[0016] In a second aspect, a method performed by an AF node includes the following steps: (a) sending a first message to a core network regarding an event related to the establishment of a user plane path for a PDU Session; (b) if the AF node receives a second message from the core network based on the occurrence of the event before a first predetermined period of time expires after transmitting the first message, transmitting a positive response to the second message to the core network; and (c) if the AF node does not receive the second message from the core network before the first predetermined period expires, sending a third message to the core network indicating a failure of the AF node's processing of the event.

[0017] In a third aspect, a UE includes a memory and at least one processor coupled to the memory. The at least one processor is configured to provide an Edge Enabler Client (EEC) function. The at least one processor is configured to receive, from a Source Edge Enabler Server (S-EES), an indication indicating a failure of an Application Context Relocation (ACR) procedure, including a transfer of an application context from the Source Edge Application Server (S-EAS) to a Target EAS (T-EAS). In response to receiving the indication, the at least one processor is further configured to, if a profile of the S-EAS is invalidated, enable the profile of the S-EAS. The failure of the ACR procedure is due to a delay in establishing a user plane path for a PDU session.

[0018] In a fourth aspect, a method performed by a UE includes the following steps: (a) providing EEC functions; (b) receiving an indication from the S-EES indicating a failure of the ACR procedure, including the transfer of the application context from the S-EAS to the T-EAS; and (c) upon receiving the indication, if the profile of the S-EAS is disabled, enabling the profile of the S-EAS. Here, the failure of the ACR procedure is due to a delay in setting up a user plane path for the PDU Session.

[0019] In a fifth aspect, a program includes a group of instructions (software code) that, when loaded into a computer, causes the computer to perform the method according to the second or fourth aspect described above. [Effects of the Invention]

[0020] According to the above-described aspects, it is possible to provide an apparatus, a method, and a program that enable an application function or a UE, or both, to deal with delays that occur in procedures in the core network for setting up (or changing) a user plane path in terms of runtime coordination between the core network and the application function. [Brief explanation of the drawings]

[0021] [Figure 1] 1 is a diagram illustrating an example of the configuration of a wireless communication network according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a deployment model of EDNs according to an embodiment. [Figure 3] FIG. 2 is a diagram illustrating an example of a deployment model of EDNs according to an embodiment. [Figure 4] FIG. 2 is a diagram illustrating an example of a deployment model of EDNs according to an embodiment. [Figure 5] FIG. 1 is a diagram illustrating an example of a 3GPP EDGEAPP architecture according to an embodiment. [Figure 6] 6 is a flowchart showing an example of an AF operation according to the embodiment. [Figure 7] FIG. 10 is a sequence diagram showing an example of the operation of AF and related NFs according to the embodiment. [Figure 8] FIG. 10 is a sequence diagram showing an example of the operation of AF and related NFs according to the embodiment. [Figure 9] FIG. 10 is a sequence diagram showing an example of the operation of AF and related NFs according to the embodiment. [Figure 10] FIG. 10 is a sequence diagram showing an example of the operation of AF and related NFs according to the embodiment. [Figure 11] FIG. 10 is a sequence diagram showing an example of the operation of AF and related NFs according to the embodiment. [Figure 12] FIG. 10 is a sequence diagram showing an example of the operation of AF and related NFs according to the embodiment. [Figure 13] FIG. 10 is a sequence diagram showing an example of the operation of AF and related NFs according to the embodiment. [Figure 14] FIG. 10 is a sequence diagram showing an example of the operation of the EEC and EES according to the embodiment. [Figure 15] FIG. 10 is a sequence diagram showing an example of the operation of the EEC, EES, and EAS according to the embodiment. [Figure 16] FIG. 2 is a block diagram illustrating an example of the configuration of a UE according to the embodiment. [Figure 17] FIG. 2 is a block diagram showing an example of the configuration of an AF, an EES, and an EAS according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0022] Hereinafter, specific embodiments will be described in detail with reference to the drawings. In each drawing, the same or corresponding elements are designated by the same reference numerals, and for clarity of explanation, duplicate explanations will be omitted as necessary.

[0023] The multiple embodiments described below can be implemented independently or in appropriate combination. These multiple embodiments have different novel features. Therefore, these multiple embodiments contribute to solving different purposes or problems and to achieving different effects.

[0024] Although the following embodiments will be described mainly with respect to a 3GPP system (e.g., a 5G system (5GS)), these embodiments may also be applied to other wireless communication systems.

[0025] As used herein, depending on the context, "if" may be interpreted to mean "when," "at or around the time," "after," "upon," "in response to determining," "in accordance with a determination," or "in response to detecting."

[0026] First Embodiment FIG. 1 shows an example of the configuration of a wireless communication network (i.e., 5GS) according to this embodiment. Each of the elements shown in FIG. 1 is a network function and provides an interface defined by 3GPP. Each element (network function) shown in FIG. 1 can be implemented, for example, as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an application platform.

[0027] The wireless communication network shown in Fig. 1 may be provided by a Mobile Network Operator (MNO) or may be a Non-Public Network (NPN) provided by a party other than an MNO. If the wireless communication network shown in Fig. 1 is an NPN, it may be an independent network referred to as a Stand-alone Non-Public Network (SNPN), or an NPN linked to an MNO network referred to as a Public network integrated NPN.

[0028] A wireless terminal (i.e., UE) 1 uses a 3GPP (e.g., 5G) connectivity service to communicate with a data network (DN). More specifically, the UE 1 is connected to a (radio) access network (e.g., 5G Access Network (5GAN)) 2 and communicates with the DN via one or more User Plane Functions (UPFs) 33 (e.g., UPF 33A and UPF 33B) in a 3GPP core network (e.g., 5G core network (5GC)) 3. The 3GPP core network 3 may be, for example, but is not limited to, a 5GC. The 3GPP core network 3 may also include a network other than 5G (e.g., a future 6G or non-3GPP) network.

[0029] UE1 can communicate with multiple DNs simultaneously. As an example, FIG. 1 shows three DNs, namely, DN41, DN42, and DN43. UE1 may simultaneously communicate with one or more of DN41, DN42, and DN43. Note that at least two of DN41, DN42, and DN43 may be the same DN. For example, DN41, DN42, and DN43 may be the same DN and be distinguished from each other by different DN Access Identifiers (DNAIs). At least one of DN41 and DN42 may be a Local Area Data Network (LADN). For example, DN41 and DN42 may be different LADNs. If DN41 corresponds to an LADN, UE1 is allowed to access DN41 via a PDU Session for DN41 only when UE1 is within the LADN service area of ​​DN41. The LADN service area is a set of one or more Tracking Areas (TAs) belonging to the UE's current registration area. DN41 and DN42 may be the same LADN but distinguished by different DNAIs. Alternatively, DN41 and DN42 may be the same LADN but distinguished by different DNAIs.

[0030] In the architecture of 5G and later 3GPP systems, connectivity services between UE1 and a DN are supported by one or more Protocol Data Unit (PDU) Sessions. A PDU Session is an association, session, or connection between UE1 and a DN. A PDU Session is used to provide PDU connectivity services (i.e., exchange of PDUs between UE1 and a DN). UE1 establishes one or more PDU Sessions between UE1 and a UPF33 (i.e., PDU Session Anchor (PSA)) to which the DN is connected. In terms of data transfer, one PDU Session consists of a tunnel within the 3GPP core network 3 (N9 tunnel), a tunnel between the 3GPP core network 3 and AN2 (N3 tunnel), and one or more radio bearers between UE1 and AN2.

[0031] Although not shown in FIG. 1 , UE 1 may establish multiple PDU Sessions with each of multiple (PSA) UPFs 33 to simultaneously access multiple DNs or (sub)networks (or entities) (e.g., DN41 and DN43) indicated by multiple DNAIs. One PDU Session may be split to access (sub)networks (or entities) (e.g., DN41 and DN43) indicated by multiple DNAIs of one DN. Specifically, if DN41 and DN43 are the same DN but distinguished by different DNAIs, one PDU Session may be split in UPF 33A. In this case, UPF 33A provides UL CL functionality or BP functionality, and also provides PSA functionality for traffic associated with DN (DNAI) 41. UPF 33A may forward some of the uplink traffic of the PDU session to DN(DNAI) 41 and may forward the remaining uplink traffic of the PDU session to UPF 33B, and may merge all of the downlink traffic of the PDU session onto the N3 tunnel between UPF 33A and AN2.

[0032] The Access and Mobility management Function (AMF) 31 is one of the network function nodes in the control plane of the 3GPP core network 3. The AMF 31 provides the termination of the RAN Control Plane (CP) interface (i.e., N2 interface). The AMF 31 terminates a single signaling connection (i.e., N1 NAS signaling connection) with UE1 and provides registration management, connection management, and mobility management. The AMF 31 provides NF services to NF consumers (e.g., other AMFs and SMF 32) over a service-based interface (i.e., Namf interface). The NF services provided by the AMF 31 include a communication service (Namf_Communication). This communication service enables the NF consumer (e.g., SMF 32) to communicate with UE1 or AN2 via the AMF 31.

[0033] The Session Management Function (SMF) 32 is one of the network function nodes in the control plane of the 3GPP core network 3. The SMF 32 manages PDU Sessions. The SMF 32 sends and receives SM signaling messages (NAS-SM messages, N1 SM messages) to and from the Non-Access-Stratum (NAS) Session Management (SM) layer of the UE 1 via the communication service provided by the AMF 31. The SMF 32 provides Network Function (NF) services to NF consumers (e.g., the AMF 31, other SMFs, and the NEF 36) over a service-based interface (i.e., the Nsmf interface). The NF services provided by the SMF 32 include a PDU Session Management service (Nsmf_PDUSession), which enables NF consumers (e.g., the AMF 31) to handle PDU Sessions. The NF services provided by the SMF 32 further include an event notification service (Nsmf_EventExposure), whose service operations are exposed to enable NF consumers (e.g., NEF 36, AF 5) to get notified of events occurring in PDU Sessions.

[0034] The User Plane Function (UPF) 33 is one of the network function nodes in the user plane of the 3GPP core network 3. The UPF 33 processes and forwards user data. The functionality of the UPF 33 is controlled by the SMF 32. The UPF 33 may include multiple UPFs (e.g., UPF 33A and UPF 33B shown in FIG. 1) interconnected via an N9 interface. As already described, the UP path for one PDU Session of UE 1 may include one or more PSA UPFs, one or more Intermediate UPFs (I-UPFs), and one or more UL CL UPFs (or BP UPFs).

[0035] The Policy Control Function (PCF) 34 is one of the network function nodes in the control plane of the 3GPP core network 3. The PCF 34 supports interactions with access and mobility policy enforcement in the AMF 31 via a service-based interface (i.e., the Npcf interface). The PCF 34 provides access and mobility management-related policies to the AMF 31. In addition, the PCF 34 provides session-related policies to the SMF 32. The session-related policies include PDU session-related policy information and Policy and Charging Control (PCC) rule information. The PCC rule information includes control information related to AF influence on traffic routing (i.e., AF-influenced Traffic Steering Enforcement Control information).

[0036] The Unified Data Management (UDM) 35 is one of the network function nodes in the control plane of the 3GPP core network 3. The UDM 35 provides access to a database (i.e., User Data Repository (UDR)) in which subscriber data (subscription information) is stored. The UDM 35 provides NF services to NF consumers (e.g., AMF 31, SMF 32) over a service-based interface (i.e., Nudm interface). The NF services provided by the UDM 35 include a subscriber data management service. This NF service enables NF consumers (e.g., AMF 31, PCF 34) to retrieve subscriber data and provides updated subscriber data to the NF consumers. The UDM 35 may sometimes be referred to as a UDR from the perspective of subscriber data management. Similarly, a UDR may sometimes be referred to as a UDM 35.

[0037] The Network Exposure Function (NEF) 36 is one of the network function nodes in the control plane of the 3GPP core network 3. The NEF 36 has a role similar to the Service Capability Exposure Function (SCEF) of the Evolved Packet System (EPS). Specifically, the NEF 36 supports the exposure of services and capabilities from the 3GPP system to applications and network functions inside and outside the operator network. The NEF 36 provides NF services to NF consumers (e.g., AF5) over the service-based interface (i.e., Nnef interface). NF services provided by the NEF 36 include an event notification service (Nnef_EventExposure). The service operations exposed by this NF service enable NF consumers (e.g., AF5) to get notified of events occurring within the 3GPP system. Furthermore, the NF services provided by the NEF 36 include a service (Nnef_TrafficInfluence) for Application Function influence on traffic routing. The service operations exposed by this NF service enable NF consumers (e.g., AFs 5) to make requests to influence the traffic routing of PDU Session(s) of a specific UE.

[0038] The Application Function (AF) 5 interacts with the 3GPP core network 3. For example, the AF 5 interacts with the 3GPP core network 3 to support application function influence on traffic routing. Depending on the deployment of the AF 5 and the MNO's policies, the AF 5 may interact directly with network functions within the 3GPP core network 3. Otherwise, the AF 5 interacts with network functions within the 3GPP core network 3 via the NEF 36. The AF 5 may include one or more computers. For example, the AF 5 may include one or more servers (e.g., content distribution servers, online game servers) that communicate with the UE 1 at the application layer, and a controller (i.e., an AF in the 3GPP definition) that cooperates with these one or more servers and interacts with the 3GPP core network 3 (e.g., the NEF 36 and the SMF 32). The AF 5 may include multiple distributed servers. For example, AF5 may include multiple edge computing servers located at (or connected to) DN41 and DN42 in addition to a central server located at (or connected to) DN43. In the example of Figure 1, AF5 may communicate with an application running on a processor of UE1 via at least one of DN41, DN42, and DN43.

[0039] For convenience of explanation, the configuration example in Fig. 1 shows only representative NFs. The wireless communication network according to this embodiment may include other NFs not shown in Fig. 1, such as a Network Slice Selection Function (NSSF) and a Network Data Analytics Function (NWDAF).

[0040] 2, 3 and 4 show several examples of deployment models of Edge Data Networks (EDNs). A Public Land Mobile Network (PLMN) 8 includes an AN 2 and a 3GPP core network 3.

[0041] In the example of FIG. 2, a non-dedicated DN is used. That is, one DN (DNN-A) that is shared with other services (e.g., Internet access) is used to connect to Edge Application Servers (EASs). The one DN identified by DNN-A shown in FIG. 2 corresponds to DN41, DN42, and DN43 in FIG. 1. In other words, in the example of FIG. 2, DN41, DN42, and DN43 are the same DN but are distinguished by different DNAIs (e.g., DNAI A1-a, DNAI A1-b, DNAI A2, DNAI B). One EDN is identified by a Data Network Name (DNN) and one or more DNAIs. For example, DN41 may include EDN A1 (201) and be identified by DNN-A and DNAI A1-a and DNAI A1-b. DN42 may include EDN A2 (202) and be identified by DNN-A and DNAI A2. DN43 corresponds to a Centralized DN and may be identified by DNN-A and DNAI B. Each EAS and Edge Enabler Server (EES) may have a topological or geographical service area within which UE1 can access the EAS or EES via local breakout, regardless of its location within the PLMN area.

[0042] A topological service area is defined relative to the UE's point of attachment to the network. A topological service area may be defined by a set of Cell IDs, a set of Tracking Area Identities (TAIs), or a PLMN ID. A geographical service area may be an area defined by geographical coordinates, a circle whose center is denoted by geographical coordinates, or a polygon whose corners are denoted by geographical coordinates. A geographical service area may also be represented in other ways, such as by well-known buildings, parks, arenas, civic addresses, or ZIP codes.

[0043] The deployment shown in FIG. 3 uses an edge-dedicated DN to support edge computing services. The edge-dedicated DN is configured with a unique DNN. The edge-dedicated DN identified by DNN-A in FIG. 3 corresponds to DN41 and DN42 in FIG. 1. In other words, in the example of FIG. 3, DN41 and DN42 are the same DN but are distinguished by different DNAIs (e.g., DNAI A1-a, DNAI A1-b, DNAI A2, DNAI B). One EDN is identified by the edge-dedicated DN DNN-A and one or more DNAIs. For example, DN41 may include EDN A1 (201) and be identified by DNN-A and DNAI A1-a and DNAI A1-b. DN42 may include EDN A2 (202) and be identified by DNN-A and DNAI A2. The Centralized DN identified by DNN-B shown in FIG. 3 corresponds to DN43 in FIG.

[0044] In the example of FIG. 4, EDN A1 (201) and EDN A2 (202) are edge-dedicated data networks deployed as LADNs. As shown in FIG. 4, DN41 in FIG. 1 may be an LADN identified by DNN-A1, and DN42 in FIG. 1 may be another LADN identified by DNN-A2. One LADN, DN41, may include EDN A1 (201), and the other LADN, DN42, may include EDN A2 (202). The service area of ​​EDN A1 (201) is the same as the LADN service area of ​​DN41. The service area of ​​EDN A2 (202) is the same as the LADN service area of ​​DN42. The service area of ​​the EES in EDN A1 (201) is equal to or a subset of the EDN service area (i.e., the LADN service area of ​​DN41). The service area of ​​each EAS in EDN A1 (201) is equal to or a subset of the service area of ​​the corresponding EES. Similarly, the service area of ​​the EES in EDN A2 (202) is equal to or a subset of the EDN service area (i.e., the LADN service area of ​​DN42). The service area of ​​each EAS in EDN A2 (202) is equal to or a subset of the service area of ​​the corresponding EES.

[0045] Figure 5 shows an example of a 3GPP EDGEAPP architecture according to this embodiment. Each of the elements shown in Figure 5 is a functional entity that provides functions and interfaces defined by 3GPP. Each element (functional entity) shown in Figure 5 can be implemented, for example, as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an application platform.

[0046] In the example of Figure 5, UE1 includes an Edge Enabler Client (EEC) 11 and one or more Application Clients (ACs) 12. In other words, the EEC 11 and one or more ACs 12 are located in and operate on the UE1. Although not explicitly shown in Figure 5, the UE1 communicates with a 3GPP core network 3 (i.e., (5GC)) via an AN2. In this way, the UE1 provides the EEC 11 and AC(s) 12 with connectivity to a data network via the AN2 and the core network 3.

[0047] The EEC 11 provides supporting functions required by the AC(s) 12. Specifically, the EEC 11 provides the provisioning of configuration information to enable the exchange of application data traffic with an Edge Application Server (EAS). Furthermore, the EEC 11 provides functionality for the discovery of one or more EASs available within the EDN 7. The EEC 11 uses the EAS endpoint information obtained through EAS discovery for routing outgoing application data traffic to the EAS. Furthermore, the EEC 11 provides functionality for registration (i.e., registration, update, and de-registration) of the EES 71 and EAS(s) 72.

[0048] Each AC 12 is an application running on a UE 1. To utilize edge computing services, each AC 12 connects to one or more EASs and exchanges application data traffic with these EASs.

[0049] An EDN 7 includes one or more EESs 71 and one or more EASs 72. As already explained, the EDN 7 may be an LADN. The EESs 71 and EASs 72 may be included in the AF 5 shown in FIG. 1.

[0050] Each EES 71 provides supporting functions required by the EAS(s) 72 and the EEC 11. Specifically, each EES 71 provides configuration information provisioning to the EEC 11, enabling the exchange of application data traffic with the EAS(s) 72. Each EES 71 provides registration, update, and deregistration functions for the EEC 11 and the EAS(s) 72. Each EES 71 also provides application context transfer between EASs. This function is required for application context relocation (or edge application mobility) for service continuity. Application context is a set of data related to an AC that resides in an EAS. Application context relocation involves transferring application context related to a user (i.e., an AC) from a source EAS (or EDN) to a target EAS (or EDN). Application context relocation can be triggered by a UE mobility event or a non-UE mobility event. UE mobility events include, for example, intra-EDN mobility, inter-EDN mobility, and LADN-related mobility. Non-UE mobility events include, for example, EAS or EDN overload conditions and EAS maintenance (e.g., graceful shutdown of the EAS).

[0051] Additionally, each EES 71 supports an Application Programming Interface (API) invoker and API exposing function. Each EES 71 provides an ACR management event notification function to the EAS(s) 72. The ACR management event notification function notifies the EAS(s) of events related to Application Context Relocation (ACR) of one or more UEs. Event types (event IDs) include user plane path change detection (i.e., "User plane path change"), user plane path change detection and T-EAS identification (i.e., "ACR monitoring"), user plane path change and T-EAS identification and traffic change appropriate for the T-EAS (i.e., "ACR facilitation"), and whether a UE has moved into or out of a specific location or area (i.e., "Presence-In-Area of ​​Interest (AOI)-Report"). The EAS(s) 72 subscribe to these events provided by the EES 71 in advance to receive the desired notifications. Here, the "specific location or area" may be a Tracking Area Identity (TAI) list or Cell IDs, or a TAI list associated with a specific LADN. Each EES 71 may interact with the 3GPP core network 3 directly (e.g., via the PCF 34) or indirectly (e.g., via the NEF 36 or Service Capability Exposure Function (SCEF)) to access the services and capabilities of network functions within the 3GPP core network 3. Each EES 71 may support external exposure of the services and capabilities of 3GPP network functions to the EAS(s) 72.Each EES 71 may support an application function influence on traffic routing and interact with the 5GC 3.

[0052] Each EAS 72 is located in the EDN 7 and executes application server functions. The application server functions may be available only at the edge. In other words, the application server functions may be available only as an EAS. However, the application server functions may be available both at the edge and in the cloud. In other words, the application server functions may be available as an EAS and also as an application server in the cloud. The cloud here refers to a central cloud (e.g., DN 43 in FIGS. 1 to 4) located farther from the UE 1 than the EDN 7 (e.g., DN 41 or 42 in FIGS. 1 to 4). Therefore, an application server in the cloud refers to a server located in a centralized location (e.g., a centralized data center). Each EAS 72 may consume or utilize 3GPP core network capabilities. Each EAS 72 may directly invoke 3GPP core network function APIs. Alternatively, each EAS 72 may consume or utilize 3GPP core network capabilities via the EES 71, or via the NEF 36 or SCEF. Each EAS 72 may support Application Function influence on traffic routing and interact with the 5GC 3.

[0053] The Edge Configuration Server (ECS) 6 provides supporting functions required by the EEC 11 to connect to the EES(s) 71. Specifically, the ECS 6 provides provisioning of edge configuration information to the EEC 11. The edge configuration information includes information for the EEC 11 to connect to the EES(s) 71 (e.g., service area information applicable to the LADN) and information for establishing a connection with the EES(s) 71 (e.g., Uniform Resource Identifier (URI)). The ECS 6 provides functions for registration, update, and de-registration of the EES(s) 71. Additionally, the ECS 6 supports API invoker and API exposing function functions. The ECS 6 may interact directly (e.g., via the PCF 34) or indirectly (e.g., via the NEF 36 or SCEF) with the 3GPP core network 3 to access the services and capabilities of network functions within the 3GPP core network 3. The ECS 6 may be located within the domain of the MNO providing the 3GPP core network 3, or may be located in a third-party domain of a service provider (e.g., an Edge Computing Service Provider (ECSP)). The ECS 6 may be located in a central cloud (e.g., DN 43 in Figures 1 to 4). The ECS 6 may be included in the AF 5 shown in Figure 1.

[0054] For convenience of explanation, only representative elements are shown in the configuration example of Fig. 5. For example, the ECS 6 may be connected to multiple EDNs.

[0055] The operation of the AF 5 according to this embodiment is described below. The AF 5 transmits a first message to the 3GPP core network 3 regarding an event related to the establishment of a UP path for a PDU session of UE 1. The event related to the establishment of a UP path for the PDU session may be, for example, enforcement of UP path (re)establishment, enforcement of a change in the UP path establishment, or enforcement of a change in the UP path establishment. If the AF 5 receives a second message based on the occurrence of the event from the 3GPP core network 3 before a first predetermined period of time expires after transmitting the first message, the AF 5 transmits a positive response (AF response) to the second message to the 3GPP core network 3. Otherwise, the AF 5 transmits a third message to the 3GPP core network 3 indicating a failure of the AF 5 processing corresponding to the event. The AF 5 processing corresponding to the event may be, for example, an Application Context Relocation (ACR) procedure or processing corresponding to the impact of an AF request. The first predetermined period may be determined based on the service continuity requirements of the application. The AF request may be a request to subscribe to a service offering notification (e.g., early notification or late notification) of an event related to the establishment of a UP path for a PDU session. The AF response may be a response (positive or negative) to the notification (e.g., early notification or late notification) of an event for which the service offering was subscribed in the AF request.

[0056] If the AF 5 does not receive a second message based on the occurrence of an event related to the establishment of a UP path for the PDU session from the 3GPP core network 3 before the first predetermined period expires, the AF 5 may determine that the event related to the establishment of a UP path for the PDU session has failed. The AF 5 may transmit a third message to the core network 3 based on the determination.

[0057] The first message may be a message regarding the impact of the Application Function on traffic routing of the PDU session of UE 1. Therefore, the first message regarding an event regarding the setting of a UP path for the PDU session of UE 1 may be rephrased as a (first) message regarding the impact of the Application Function on traffic routing of the PDU session of UE 1.

[0058] The second message may be a message regarding the influence of an application function on traffic routing of a PDU session of UE1. The second message may also be a message regarding runtime coordination between the core network 3 and the AF 5. Therefore, the second message may be rephrased as a (second) message regarding the influence of an application function on traffic routing of a PDU session of UE1, or as a (second) message regarding runtime coordination between the core network 3 and the AF 5. The second message may be related to a change from an original user plane (UP) path for traffic of the PDU session to a new UP path. More specifically, the second message may be related to a DNAI change. The second message may be sent directly from the SMF 32 or via the NEF 36 before setting up or activating a new UP path for the new DNAI. The second message may be a notification indicating the start of implementation of the user plane path configuration for the PDU session. The second message may also be a notification indicating the implementation (completion) of the user plane path configuration for the PDU session.

[0059] A positive response to the second message may prompt the SMF 32 in the 3GPP core network 3 to enforce the configuration of the new UP path. Additionally or alternatively, a positive response to the second message may prompt the SMF 32 to activate the configuration of the new UP path.

[0060] The third message may prompt SMF 32 to continue using the original UP path and cancel the change from the original UP path to the new UP path. The third message may be rephrased as a negative response to the second message. The third message may be rephrased as a (third) message prompting 3GPP core network 3 to cancel an event related to the establishment of a UP path for UE1's PDU session. The third message may be rephrased as a third message indicating a failure of an event related to the establishment of a UP path for UE1's PDU session. The third message may be rephrased as a third message indicating a failure of processing related to the impact of AF. The third message may be rephrased as a third message indicating a failure of processing related to the impact of AF (request).

[0061] In a first implementation, the event related to the establishment of a UP path for a PDU session is the establishment of a UP path for the PDU session. In this case, the above-mentioned first message is a positive response to the Early notification (first notification). The Early notification is sent by the SMF 32 based on a subscription request from the AF 5. More specifically, the SMF 32 sends the Early notification to the AF 5 directly or via the NEF 36 before a (new) UP path for traffic of the PDU session is configured. For example, the Early notification may be a prior notification to establish a UP path for the PDU session. The subscription request may further include an indication that "AF acknowledgment to be expected." This indication implies that the AF 5 intends to provide a response to the notification of the UP path management event to the 3GPP core network 3. According to this indication, the SMF 32 may wait for a response from the AF 5 before establishing a new UP path. In this case, SMF32 does not set up a new UP path (eg, a UP path to a new DNAI) until it receives the first message (i.e., a positive AF response to the Early notification).

[0062] In the first implementation, the second message is a late notification. The late notification is sent by the SMF 32 based on a subscription request from the AF 5. More specifically, the SMF 32 sends the late notification to the AF 5 directly or via the NEF 36 after completing the setup of a UP path for a PDU session and before the new UP path is activated. For example, the late notification may be sent to notify the AF 5 that the setup of a UP path for a PDU session has been completed. The subscription request includes an indication of "AF acknowledgment to be expected." According to this indication, the SMF 32 waits for a response from the AF 5 before activating the new UP path. The SMF 32 does not activate the new UP path (e.g., the UP path to a new DNAI) until it receives a positive AF response to the second message (i.e., the late notification).

[0063] In this first implementation, a positive response to the second message (late notification) confirms the UP path management event (eg, DNAI change) indicated in the late notification.

[0064] In this first implementation, the above-mentioned third message indicates a failure of processing corresponding to the effect of the AF request, specifically a failure of AF5 processing (for example, the ACR procedure) corresponding to an event related to the establishment of a UP path for a PDU Session. The third message rejects the UP path management event (e.g., DNAI change) indicated in the late notification. The third message may be a negative response to the second message (late notification). When SMF 32 receives the third message, SMF 32 continues to use the original UP path (e.g., UP path to the original DNAI) and cancels the related PSA rearrangement or addition.

[0065] Alternatively, in a second implementation, the event related to the UP path configuration for the PDU session is the establishment of the UP path configuration for the PDU session. Alternatively, the event related to the UP path configuration for the PDU session may be the establishment of a condition for UP path management event notification. In this case, the above-mentioned first message is an AF request related to AF influence on traffic routing. The AF 5 sends the AF request to the PCF 34 directly or via the NEF 36. The AF request can influence the routing decision by the SMF 32 for traffic of the PDU session of UE1. The AF request can cause the SMF 32 to establish the UP path configuration for the PDU session of UE1. Specifically, based on the AF request, the PCF 34 generates a PCC rule including control information related to AF influence on traffic routing (i.e., AF-influenced Traffic Steering Enforcement Control information) and provides the PCC rule to the SMF 32 (via the UDR). Furthermore, the AF request includes a subscription request for early notification of UP path management events (e.g., DNAI changes). The subscription request includes an indication that "AF acknowledgment is expected." The AF request may further include a request for a subscription to late notifications.

[0066] In this second implementation, the second message is an Early notification. More specifically, the SMF 32 sends the Early notification to the AF 5 directly or via the NEF 36 before the UP path for the PDU session is set up. For example, the Early notification may be a prior notification to set up a UP path for the PDU session. The Early notification is sent by the SMF 32 based on a subscription request from the AF 5. According to the indication "AF acknowledgment to be expected," the SMF 32 does not set up a new UP path (e.g., a UP path to a new DNAI) until it receives a positive response to the second message (i.e., the Early notification).

[0067] In this second implementation, a positive response to the second message (Early notification) confirms the UP path management event (eg, DNAI change) indicated in the Early notification.

[0068] In this second implementation, the above-mentioned third message indicates a failure of processing corresponding to the effect of the AF request, specifically a failure of AF5 processing (for example, the ACR procedure) corresponding to an event related to the establishment of a UP path for a PDU Session. The third message rejects the UP path management event (e.g., DNAI change) indicated in the Early notification. The third message may be a negative response to the second message (Early notification). When SMF 32 receives the third message, SMF 32 continues to use the original UP path (e.g., UP path to the original DNAI) and cancels the related PSA rearrangement or addition.

[0069] In the third implementation, the event related to the establishment of a UP path for a PDU session is the establishment of a UP path for the PDU session. Alternatively, the event related to the establishment of a UP path for a PDU session may be the fulfillment of a condition for UP path management event notification. In this case, the first message described above is an AF request related to AF influence on traffic routing, as in the second implementation. The AF 5 sends the AF request to the PCF 34 directly or via the NEF 36. The AF request can influence the routing decision by the SMF 32 for traffic of the PDU session of UE1. The AF request can cause the SMF 32 to establish a UP path for the PDU session of UE1. Furthermore, the AF request includes a subscription request to late notifications for UP path management events (e.g., DNAI changes). The subscription request includes an indication of "AF acknowledgment to be expected." The AF request may further include a request for subscription to early notifications.

[0070] In the third implementation, the second message described above is a late notification, as in the first implementation. The late notification is sent by the SMF 32 based on a subscription request from the AF 5. More specifically, the SMF 32 sends the late notification to the AF 5 directly or via the NEF 36 after completing the setup of a UP path for a PDU Session and before the new UP path is activated. For example, the late notification may be sent to notify the AF 5 that the setup of a UP path for a PDU Session has been completed. According to the indication "AF acknowledgment to be expected," the SMF 32 does not activate a new UP path (e.g., a UP path to a new DNAI) until it receives a positive AF response to the second message (i.e., the late notification).

[0071] In this third implementation, a positive response to the second message (late notification) confirms the UP path management event (eg, DNAI change) indicated in the late notification.

[0072] In this third implementation, the above-mentioned third message indicates a failure of processing corresponding to the effect of the AF request, specifically a failure of AF5 processing (for example, the ACR procedure) corresponding to an event related to the establishment of a UP path for a PDU Session. The third message rejects the UP path management event (e.g., DNAI change) indicated in the late notification. The third message may be a negative response to the second message (late notification). When SMF 32 receives the third message, SMF 32 continues to use the original UP path (e.g., UP path to the original DNAI) and cancels the related PSA rearrangement or addition.

[0073] 6 is a flowchart showing an example of the operation of the AF 5 according to this embodiment. In step 601, the AF 5 transmits a first message to the 3GPP core network 3 regarding an event related to the establishment of a UP path for a PDU session. In step 602, after transmitting the first message, the AF 5 waits for a second message based on the occurrence of the event related to the establishment of a UP path for the PDU session. The AF 5 may start a timer to count a first predetermined period after, upon, or in response to the transmission of the first message. The event related to the establishment of a UP path for a PDU session may be, for example, the implementation of (re)establishment of a UP path for the PDU session, the implementation of a change in the establishment of a UP path, or the implementation of a change in the establishment of a UP path for the PDU session.

[0074] As previously described, the AF 5 may include the EES 71 or the EAS 72. For example, the AF 5 may include a Source EES (S-EES) or a Source EAS (S-EAS). In parallel with one or both of steps 601 and 602, the AF 5 may signal with other network functions (e.g., EEC, T-EES, T-EAS) regarding an Application Context Relocation (ACR) procedure. The ACR procedure involves transferring application context for the user (i.e., AC 12) from the S-EES to the Target EAS (T-EAS).

[0075] If the AF 5 receives a second message from the 3GPP core network 3 before the first predetermined period expires after transmitting the first message (YES in step 603), the AF 5 transmits a positive response to the second message to the 3GPP core network 3 (step 604). The AF 5 stops the timer. On the other hand, if the AF 5 does not receive a second message from the 3GPP core network 3 before the first predetermined period expires (NO in step 603), the AF 5 determines that a procedure in the 3GPP core network 3 related to AF influence on traffic routing (e.g., UPF relocation or addition) is delayed. The AF 5 then transmits a third message to the 3GPP core network 3 indicating a failure of the AF 5's processing corresponding to the event related to the establishment of a UP path for the PDU Session (step 605). The third message may be a negative response to the second message. The third message may be a message indicating a failure of the processing related to the influence of the AF request.

[0076] According to the operation of the AF 5 in this embodiment, if the AF 5 fails to receive the second message from the 3GPP core network 3 before the expiration of the first predetermined period, the AF 5 can determine that a procedure (e.g., UPF relocation or addition) in the 3GPP core network 3 related to AF influence on traffic routing is delayed, and can cancel this procedure, thus enabling the AF 5 to address delays in procedures in the 3GPP core network 3 related to AF influence on traffic routing.

[0077] For example, if the AF 5 fails to receive the second message from the 3GPP core network 3 by the expiration of the first predetermined period, the AF 5 may cancel the ACR procedure. Canceling the ACR procedure involves the AC 12 of the UE 1 continuing to use S-EAS. To enable this, if the AF 5 includes S-EES, if the AF 5 does not receive the second message from the 3GPP core network 3 before the expiration of the first predetermined period, the AF 5 may send an indication of ACR procedure failure to the EEC 11 of the UE 1. The failure of the ACR procedure is due to a delay in a procedure (e.g., UPF relocation or addition) within the 3GPP core network 3 related to AF influence on traffic routing. The indication of ACR procedure failure may explicitly indicate that the delay is due to a procedure (e.g., UPF relocation or addition) within the 3GPP core network 3. If the AF5 includes an S-EAS, it may request the S-EES to send an indication indicating a failure of the ACR procedure to the EEC11 of the UE1 if the AF5 does not receive the second message from the 3GPP core network 3 before the first predetermined period expires. In response to receiving the indication, the EEC11 of the UE1 may restore (or enable) the S-EAS profile if the S-EAS profile has been disabled.

[0078] <Second embodiment> This embodiment provides a detailed example of the operation of the AF5 described in the first embodiment, and a detailed example of the operation of other network functions effective therefor. An example of a network architecture according to this embodiment is similar to the example described with reference to FIGS.

[0079] 7 to 9 are sequence diagrams showing examples of the operations of the AF 5, the SMF 32, the UPF 33, and the NEF 36. The AF 5 may include an S-EES or an S-EAS. The examples in FIGS. 7 to 9 correspond to the first implementation described in the first embodiment. That is, the AF 5 transmits a first message (a positive response to the Early notification (first notification) from the SMF 32) to the SMF 32 directly or via the NEF 36. Then, if the AF 5 receives a second message (a Late notification) before the first predetermined period expires after transmitting the positive response to the Early notification, the AF 5 transmits a positive response to the Late notification to the SMF 32 directly or via the NEF 36 (FIG. 7). The occurrence of an event related to the establishment of a UP path for a PDU session may be, for example, the establishment of a UP path for the PDU session. If the AF 5 does not receive a second message (Late notification) before the first predetermined period expires after sending a positive response to the Early notification, the AF 5 sends a third message (a message indicating a failure of the AF 5 to process the event) to the SMF 32 directly or via the NEF 36 (FIGS. 8 and 9). The third message may be a negative response to the Late notification. The third message may also be a message indicating a failure to process the effect of the AF request.

[0080] First, let us consider Figure 7. Figure 7 illustrates a case in which the AF 5 receives a late notification based on the occurrence of an event related to the establishment of a UP path for a PDU session before the expiration of a first predetermined period, and the AF 5 sends a positive response to the late notification. In step 701, the SMF 32 determines (or detects) that the condition for early notification regarding UP path management event notifications to which the AF 5 has subscribed has been met. The UP path management event may be that a PSA has been established or released, or that a DNAI has been changed. The UP path management event may be that the SMF 32 has received an AF request and that an ongoing PDU session has met the condition for notifying the AF 5. The SMF 32 may use notification reporting information received from the PCF 34 to issue a notification to the AF 5 directly or via the NEF 36. The notification reporting information may be included in a PCC rule.

[0081] In step 702, if early notification via the NEF is requested by the AF 5, the SMF 32 notifies the NEF 36 of the Target DNAI by invoking the Nsmf_EventExposure_Notify service operation. In step 703, the NEF 36 performs information mapping and triggers the appropriate Nnef_TrafficInfluence_Notify message. The information mapping includes, for example, replacing the AF Transaction Internal ID with the AF Transaction ID and replacing the UE 1's Subscription Permanent Identifier (SUPI) with the Generic Public Subscription Identifier (GPSI). If early direct notification is requested by the AF 5, instead of steps 702 and 703, the SMF 32 notifies the AF 5 of the Target DNAI by invoking the Nsmf_EventExposure_Notify service operation.

[0082] In step 704, the AF 5 sends a positive response to the Early notification about the event regarding the establishment of a UP path for the PDU Session to the NEF 36. Specifically, the AF 5 replies to Nnef_TrafficInfluence_Notify by invoking the Nnef_TrafficInfluence_AppRelocationInfo service operation. The AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation immediately. Alternatively, the AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation after the application layer is ready or after any required application relocation to the Target DNAI is completed. The AF 5 includes an AfAckInfo data type with an "afStatus" attribute set to "SUCCESS" in the payload of the HTTP POST message. This indicates a positive response to the Early notification.

[0083] In step 705, the NEF 36 triggers the appropriate Nsmf_EventExposure_AppRelocationInfo in response to receiving Nsmf_TrafficInfluence_AppRelocationInfo. If the AF 5 receives an Early direct notification, instead of steps 704 and 705, the AF 5 may reply to the Nsmf_EventExposure_Notify by invoking the Nsmf_EventExposure_AppRelocationInfo service operation.

[0084] In step 706, the AF 5 starts a timer to count a first predetermined period of time. For example, but not by way of limitation, the AF 5 may start the timer after, upon, or in response to sending an affirmative response to the Early notification.

[0085] In step 707, SMF 32 enforces the establishment of a UP path for the PDU Session (UP reconfiguration enforcement). Specifically, SMF 32 exchanges control messages with UPF 33 and enforces user plane (UP) reconfiguration. SMF 32 rearranges or adds a PSA to establish a new UP path to the target DNAI. The rearrangement or addition of a PSA includes one or any combination of the addition, modification, and removal of one or more UPFs. If the subscription request to the early notification included an indication of "AF acknowledgment to be expected," SMF 5 does not establish a UP path to the new DNAI based on that indication until it receives a positive response in step 706. If the subscription request to the early notification did not include an indication of "AF acknowledgment to be expected," SMF 5 may enforce the establishment of a UP path to the new DNAI without waiting for a positive response to the early notification. However, before the UP path to the new DNAI is activated, application traffic data continues to be routed to the old DNAI.

[0086] In step 708, if late notification via the NEF is requested by the AF 5, the SMF 32 notifies the NEF 36 of the Target DNAI by invoking the Nsmf_EventExposure_Notify service operation. In step 709, the NEF 36 performs information mapping and triggers the appropriate Nnef_TrafficInfluence_Notify message. If late direct notification is requested by the AF 5, instead of steps 708 and 709, the SMF 32 notifies the AF 5 of the Target DNAI by invoking the Nsmf_EventExposure_Notify service operation. Note that the subscription request for the late (direct) notification includes an indication of "AF acknowledgment to be expected." According to this indication, the SMF 32 waits for a response from the AF 5 before activating the new UP path. The SMF32 does not activate a new UP path (eg, a UP path to a new DNAI) until it receives a positive AF response to the late (direct) notification.

[0087] In step 710, in response to receiving a late notification before the timer expires, the AF 5 stops the timer. The late notification is based on the occurrence of an event related to the establishment of a UP path for the PDU Session. In step 711, the AF 5 sends a positive response to the late notification to the NEF 36. Specifically, the AF 5 replies to Nnef_TrafficInfluence_Notify by invoking the Nnef_TrafficInfluence_AppRelocationInfo service operation. The AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation immediately. Alternatively, the AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation after the application layer is ready or after any required application relocation to the Target DNAI is completed. The AF 5 includes an AfAckInfo data type with an "afStatus" attribute set to "SUCCESS" in the payload of the HTTP POST message. This indicates a positive response to the late notification.

[0088] In step 712, the NEF 36 triggers the appropriate Nsmf_EventExposure_AppRelocationInfo in response to receiving Nsmf_TrafficInfluence_AppRelocationInfo. If the AF 5 receives a late direct notification, instead of steps 711 and 712, the AF 5 may reply to the Nsmf_EventExposure_Notify by invoking the Nsmf_EventExposure_AppRelocationInfo service operation.

[0089] In step 713, the SMF 32 exchanges a control message with the UPF 33 to activate the UP reconfiguration (UP Reconfiguration Activation). In other words, the SMF 32 activates the UP path to the new DNAI. After this, the target application traffic data is routed to the new DNAI.

[0090] FIG. 8 illustrates a case in which a first predetermined period expires before the AF 5 receives a late notification, and the AF 5 receives the late notification during a second predetermined period after the expiration of the first predetermined period. The second predetermined period may be referred to as a graceful period. Steps 801 to 809 in FIG. 8 are the same as steps 701 to 709 in FIG. 7. However, in the case of FIG. 8, the AF 5 receives the late notification (809) during a graceful period (811) after the timer expires (810). When the timer expires (810), the AF 5 may determine that the processing being performed by the AF 5 has failed due to a delay in the 3GPP core network 3.

[0091] In step 812, in response to receiving the late notification after the timer expires, the AF 5 sends a negative response to the late notification to the NEF 36. Specifically, the AF 5 replies to the Nnef_TrafficInfluence_Notify by invoking the Nnef_TrafficInfluence_AppRelocationInfo service operation. The AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation immediately. Alternatively, the AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation after the cancellation of the application relocation is complete.

[0092] The AF5 includes in the payload of the HTTP POST message (step 812) an AfAckInfo data type containing the "afStatus" attribute set to a value other than "SUCCESS". This indicates a negative response to the late notification. The "afStatus" attribute set to a value other than "SUCCESS" indicates a failure cause. Values ​​other than "SUCCESS" may be "TEMP_CONGESTION", "RELOC_NO_ALLOWED", or "OTHER". The value "TEMP_CONGESTION" indicates that application relocation failed due to temporary congestion. The value "RELOC_NO_ALLOWED" indicates that application relocation failed because application relocation is not allowed. The value "OTHER" indicates that application relocation failed due to some other reason. Alternatively, the "afStatus" attribute may explicitly indicate that processing corresponding to the impact of the AF request failed due to processing delays in the 3GPP core network. Additionally or alternatively, the "afStatus" attribute may explicitly indicate that the application relocation procedure failed due to the expiration of a timer governing the procedure in the 3GPP core network. For example, the AF5 may include in the payload of the HTTP POST message (step 812) an AfAckInfo data type containing an "afStatus" attribute set to the value "Failure_because_5GC_delay" or "RELOC_TIMER_EXPIRED".

[0093] In step 813, the NEF 36 triggers the appropriate Nsmf_EventExposure_AppRelocationInfo in response to receiving Nsmf_TrafficInfluence_AppRelocationInfo. If the AF 5 receives a late direct notification, instead of steps 812 and 813, the AF 5 may reply to the Nsmf_EventExposure_Notify by invoking the Nsmf_EventExposure_AppRelocationInfo service operation.

[0094] In step 814, SMF 32 exchanges control messages with UPF 33 to restore the UP path to the original DNAI. Alternatively, SMF 32 disables the setting of the UP path to the new DNAI. SMF 32 continues to use the UP path to the original DNAI and cancels the change to the UP path to the new DNAI.

[0095] 9 shows a case where the AF5 does not receive a late notification during a second graceful period after the first graceful period has expired. Steps 901 to 907 in FIG. 9 are the same as steps 701 to 707 in FIG.

[0096] If the timer expires (908), the AF5 may determine that the processing it is performing has failed based on delays in the 3GPP core network. If the graceful period (909) has elapsed after the timer expires (908), in step 910, the AF5 sends a message indicating the failure of the processing corresponding to the impact of the AF request. In implementation, this negative response may be implemented as a negative response to a late notification or a negative response to an early notification. Specifically, the AF5 replies to Nnef_TrafficInfluence_Notify by calling the Nnef_TrafficInfluence_AppRelocationInfo service operation. The AF5 may also call the Nnef_TrafficInfluence_AppRelocationInfo service operation immediately. Alternatively, the AF5 may call the Nnef_TrafficInfluence_AppRelocationInfo service operation after the cancellation of the application relocation is complete.

[0097] The AF5 includes in the payload of the HTTP POST message (step 910) an AfAckInfo data type containing the "afStatus" attribute set to a value other than "SUCCESS". This indicates a negative response to the Late notification. The AF5 may also include in the payload of the HTTP POST message (step 910) an AfAckInfo data type containing the "afStatus" attribute set to a value of "Failure_because_5GC_delay" or "RELOC_TIMER_EXPIRED". This indicates that processing corresponding to the impact of the AF request failed due to processing delays in the 3GPP core network. Additionally or alternatively, this indicates that the application context relocation procedure failed due to expiration of a timer governing processing in the 3GPP core network.

[0098] In step 911, the NEF 36 triggers the appropriate Nsmf_EventExposure_AppRelocationInfo in response to receiving the Nnef_TrafficInfluence_AppRelocationInfo. Alternatively to steps 910 and 912, the AF 5 may send a negative response directly to the SMF 32 by invoking the Nsmf_EventExposure_AppRelocationInfo service operation.

[0099] In step 912, SMF 32 exchanges control messages with UPF 33 to restore the UP path to the original DNAI. Alternatively, SMF 32 disables the setting of the UP path to the new DNAI. SMF 32 continues to use the UP path to the original DNAI and cancels the change to the UP path to the new DNAI.

[0100] 8 and 9, the graceful period (811, 909) may not be provided. In this case, if the timer expires (or the first predetermined period elapses) before the AF 5 receives the late notification, the AF 5 may send a message indicating a failure in processing corresponding to the effect of the AF request (e.g., a negative response to the late notification).

[0101] According to the procedure described in this embodiment, if the AF 5 fails to receive a Late notification from the 3GPP core network 3 by the expiration of the first predetermined period after sending a positive response to the Early notification, the AF 5 can determine that a procedure (e.g., UPF relocation or addition) in the 3GPP core network 3 related to AF influence on traffic routing is delayed, and can cancel this procedure. This therefore enables the AF 5 to deal with delays in procedures in the 3GPP core network 3 related to AF influence on traffic routing.

[0102] <Third embodiment> This embodiment provides a detailed example of the operation of the AF5 described in the first embodiment, and a detailed example of the operation of other network functions effective therefor. An example of a network architecture according to this embodiment is similar to the example described with reference to FIGS.

[0103] 10 and 11 are sequence diagrams illustrating an example of the operations of the AF 5, the SMF 32, the UPF 33, the PCF 34, the NEF 36, and the UDR 37. The AF 5 may include an S-EES or an S-EAS. The examples in FIGS. 10 and 11 correspond to the second implementation described in the first embodiment. That is, the AF 5 sends a first message (AF request for AF influence on traffic routing) to the PCF 34 directly or via the NEF 36. The AF request relates to an event related to the implementation of UP path configuration for the PDU session. Furthermore, the AF request relates to a subscription to a UP path management event notification. The event related to the UP path configuration for the PDU session is the implementation of UP path configuration for the PDU session. Alternatively, the event related to the UP path configuration for the PDU session may be the fulfillment of a condition for a UP path management event notification.

[0104] The AF request requests the 3GPP core network 3 to reconfigure a UP path for traffic of the UE 1's ongoing PDU session (e.g., change the Target DNAI). The AF request further includes at least a subscription request for the Early notification. If the AF 5 receives a second message (Early notification) before the first predetermined period expires after sending the AF request, the AF 5 sends a positive response to the Early notification to the SMF 32 directly or via the NEF 36 (FIG. 10). The Early notification is sent based on the occurrence of an event related to the establishment of a UP path for the PDU session. Otherwise, the AF 5 sends a third message (a message indicating a failure of the AF 5's processing corresponding to the event) to the SMF 32 directly or via the NEF 36 (FIG. 11). The third message may be a negative response to the Early notification. The third message may also be a message indicating a failure of processing the effect of the AF request.

[0105] FIG. 10 illustrates a case in which the AF 5 receives an Early notification based on the occurrence of an event related to the establishment of a UP path for a PDU Session before the expiration of the first predetermined period, and transmits a positive response to the Early notification. In step 1001, the AF 5 sends an AF request to the NEF 36 by calling the Nnef_TrafficInfluence_Create service operation. The AF request requests the 3GPP core network 3 to reconfigure a UP path for traffic of the ongoing PDU Session of the UE 1 (e.g., a change to the Target DNAI). A notification reporting request for UP path change may be set in Nnef_TrafficInfluence_Create. In step 1002, the NEF 36 stores information of the AF request in the UDR 37. In step 1003, the PCF 34 receives a Nudr_DM_Notify notification regarding the data change from the UDR 37. Instead of steps 1001 to 1003, the AF 5 may directly transmit the AF request to the PCF 34 via a direct interface with the PCF 34 (ie, the N5 interface).

[0106] In step 1004, the PCF 34 determines whether an existing PDU session may be affected by the AF request. Then, for that PDU session, the PDF 34 updates the SMF 32 with the corresponding new PCC rule by calling the Npcf_SMPolicyControl_UpdateNotify service operation. If the AF request includes a request for early notification and / or late notification of a UP path management event (e.g., DNAI change), the PCF 34 includes the information required for reporting the event in the PCC rule. Here, the PCC rule includes the information required for early notification of the event. The PCC rule may also include the information required for late notification of the event.

[0107] In step 1005, the AF 5 starts a timer to count a first predetermined period of time. For example, but not by way of limitation, the AF 5 may start the timer after, upon, or in response to sending an AF request.

[0108] In step 1006, the SMF 32 performs an event related to the establishment of a UP path for the PDU session. Specifically, the SMF 32 determines (or detects) that the condition for early notification for UP path management event notification, to which the AF 5 has subscribed, has been met. The UP path management event may be that the SMF 32 has received an AF request and that an ongoing PDU session has met the condition for notification to the AF 5. If early notification via the NEF is requested by the AF 5, the SMF 32 notifies the NEF 36 of the Target DNAI by invoking the Nsmf_EventExposure_Notify service operation. In step 1007, the NEF 36 performs information mapping and triggers the appropriate Nnef_TrafficInfluence_Notify message. If Early direct notification is requested by the AF 5, instead of steps 1006 and 1007, the SMF 32 notifies the AF 5 of the Target DNAI by calling the Nsmf_EventExposure_Notify service operation.

[0109] In step 1008, in response to receiving the Early notification before the timer expires, the AF 5 stops the timer. The Early notification is based on the occurrence of an event related to the establishment of a UP path for the PDU Session (i.e., the satisfaction of the Early notification condition related to the UP path management event notification). In step 1009, the AF 5 sends a positive response to the Early notification to the NEF 36. Specifically, the AF 5 replies to Nnef_TrafficInfluence_Notify by calling the Nnef_TrafficInfluence_AppRelocationInfo service operation. The AF 5 may call the Nnef_TrafficInfluence_AppRelocationInfo service operation immediately. Alternatively, the AF 5 may call the Nnef_TrafficInfluence_AppRelocationInfo service operation after the application layer is ready or after any required application relocation to the Target DNAI is completed. AF5 includes an AfAckInfo data type in the payload of the HTTP POST message that contains an "afStatus" attribute set to "SUCCESS", indicating a positive response to the Early notification.

[0110] In step 1010, the NEF 36 triggers the appropriate Nsmf_EventExposure_AppRelocationInfo in response to receiving Nsmf_TrafficInfluence_AppRelocationInfo. If the AF 5 receives an Early direct notification, instead of steps 1009 and 1010, the AF 5 may reply to the Nsmf_EventExposure_Notify by invoking the Nsmf_EventExposure_AppRelocationInfo service operation.

[0111] In step 1011, SMF 32 exchanges control messages with UPF 33 to enforce and activate UP reconfiguration (UP Reconfiguration Enforcement and Activation). In other words, SMF 32 configures and activates a UP path to the new DNAI. After this, the target application traffic data is routed to the new DNAI. If late notification was requested, SMF 32 may send a late notification to AF 5 directly or via NEF 36 after implementing UP reconfiguration. Furthermore, if the subscription request for the late notification includes an indication of "AF acknowledgment to be expected," SMF 32 may wait for a response from AF 5 according to the indication before activating the new UP path.

[0112] Fig. 11 shows a case where the first predetermined period expires before the AF 5 receives an Early notification based on the occurrence of an event related to the establishment of a UP path for a PDU session. Steps 1101 to 1107 in Fig. 11 are the same as steps 1001 to 1007 in Fig. 10. However, in the case of Fig. 11, the AF 5 receives the Early notification (1107) during a graceful period (1109) after the timer expires (1108). When the timer expires (1108), the AF 5 may determine that the processing being performed by the AF 5 has failed due to delays in the 3GPP core network.

[0113] In step 1110, in response to receiving the Early notification after the timer has expired, the AF 5 sends a message to the NEF 36 indicating a failure in processing corresponding to the impact of the AF request, specifically, a failure in the AF 5 processing corresponding to an event related to the establishment of a UP path for the PDU session. This message may be a negative response to the Early notification. Specifically, the AF 5 replies to Nnef_TrafficInfluence_Notify by invoking the Nnef_TrafficInfluence_AppRelocationInfo service operation. The AF 5 may also invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation immediately. Alternatively, the AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation after the cancellation of the application relocation is complete.

[0114] The AF5 includes in the payload of the HTTP POST message (step 1110) an AfAckInfo data type containing the "afStatus" attribute set to a value other than "SUCCESS". This indicates a negative response to the Early notification. The "afStatus" attribute set to a value other than "SUCCESS" indicates a failure cause. Values ​​other than "SUCCESS" may be "TEMP_CONGESTION", "RELOC_NO_ALLOWED", or "OTHER". The value "TEMP_CONGESTION" indicates that application relocation failed due to temporary congestion. The value "RELOC_NO_ALLOWED" indicates that application relocation failed because application relocation is not allowed. The value "OTHER" indicates that application relocation failed due to some other reason. Alternatively, the "afStatus" attribute may explicitly indicate that processing corresponding to the impact of the AF request failed due to processing delays in the 3GPP core network. Additionally or alternatively, the "afStatus" attribute may explicitly indicate that the application relocation procedure failed due to the expiration of a timer governing the procedure in the 3GPP core network. For example, the AF5 may include in the payload of the HTTP POST message (step 1110) an AfAckInfo data type containing an "afStatus" attribute set to the value "Failure_because_5GC_delay" or "RELOC_TIMER_EXPIRED".

[0115] In step 1111, the NEF 36 triggers the appropriate Nsmf_EventExposure_AppRelocationInfo in response to receiving Nsmf_TrafficInfluence_AppRelocationInfo. If the AF 5 receives an Early direct notification, instead of steps 1110 and 1111, the AF 5 may reply to the Nsmf_EventExposure_Notify by invoking the Nsmf_EventExposure_AppRelocationInfo service operation.

[0116] In step 1112, SMF32 continues to use the UP path to the original DNAI (Keep Using Original UP Path) and cancels the change to the UP path to the new DNAI. Here, "cancelling the change to the UP path to the new DNAI" may mean invalidating the setting of the UP path to the new DNAI.

[0117] In the procedure of Fig. 11, if the graceful period (1109) has elapsed before the AF5 receives the Early notification, the AF5 may transmit a message indicating a failure in processing corresponding to the effect of the AF request (e.g., a negative response to the Early notification) after, in response to, or in response to the graceful period. In the procedure of Fig. 11, the graceful period (1109) may not be provided. In this case, if the timer expires (or the first predetermined period has elapsed) before the AF5 receives the Early notification, the AF5 may transmit a message indicating a failure in processing corresponding to the effect of the AF request (e.g., a negative response to the Early notification).

[0118] According to the procedure described in this embodiment, if the AF 5 fails to receive an Early notification from the 3GPP core network 3 before the expiration of the first predetermined period after sending the AF request, the AF 5 can determine that a procedure (e.g., UPF relocation or addition) in the 3GPP core network 3 related to AF influence on traffic routing is delayed, and can cancel this procedure. This therefore enables the AF 5 to deal with delays in procedures in the 3GPP core network 3 related to AF influence on traffic routing.

[0119] <Fourth embodiment> This embodiment provides a detailed example of the operation of the AF5 described in the first embodiment, and a detailed example of the operation of other network functions effective therefor. An example of a network architecture according to this embodiment is similar to the example described with reference to FIGS.

[0120] 12 and 13 are sequence diagrams showing an example of the operations of the AF 5, the SMF 32, the UPF 33, the PCF 34, the NEF 36, and the UDR 37. The AF 5 may include an S-EES or an S-EAS. The examples in FIGS. 12 and 13 correspond to the third implementation described in the first embodiment. That is, the AF 5 sends a first message (AF request for AF influence on traffic routing) to the PCF 34 directly or via the NEF 36. The AF request is related to an event related to the establishment of a UP path for a PDU session. The event related to the establishment of a UP path for a PDU session is the establishment of a UP path for a PDU session.

[0121] The AF request requests the 3GPP core network 3 to reconfigure a UP path (e.g., change the Target DNAI) for traffic of the ongoing PDU session of UE 1. The AF request further includes a subscription request for late notification. If the AF 5 receives a second message (late notification) before the first predetermined period expires after sending the AF request, the AF 5 sends a positive response to the late notification to the SMF 32 directly or via the NEF 36 (FIG. 12). Otherwise, the AF 5 sends a third message to the SMF 32 directly or via the NEF 36 indicating a failure in processing corresponding to the effect of the AF request, specifically, a failure in AF 5 processing corresponding to an event related to the establishment of a UP path for the PDU session (FIG. 13). The third message may be a negative response to the late notification.

[0122] FIG. 12 illustrates a case in which the AF 5 receives a late notification based on the occurrence of an event related to the establishment of a UP path for a PDU Session before the expiration of the first predetermined period, and transmits a positive response to the late notification. In step 1201, the AF 5 sends an AF request to the NEF 36 by calling the Nnef_TrafficInfluence_Create service operation. The AF request requests the 3GPP core network 3 to reconfigure a UP path for traffic of the ongoing PDU Session of the UE 1 (e.g., a change to the Target DNAI). A notification reporting request for UP path change may be set in the Nnef_TrafficInfluence_Create. In step 1202, the NEF 36 stores information of the AF request in the UDR 37. In step 1203, the PCF 34 receives a Nudr_DM_Notify notification regarding the data change from the UDR 37. Instead of steps 1201 to 1203, the AF 5 may directly transmit the AF request to the PCF 34 via a direct interface with the PCF 34 (ie, the N5 interface).

[0123] In step 1204, the PCF 34 determines whether an existing PDU Session may be affected by the AF request. For that PDU Session, the PDF 34 then updates the SMF 32 with the corresponding new PCC rule by invoking the Npcf_SMPolicyControl_UpdateNotify service operation. If the AF request includes a request for early notification and / or late notification of a UP path management event (e.g., DNAI change), the PCF 34 includes the information required for reporting that event in the PCC rule. Here, the PCC rule includes the information required for late notification of that event.

[0124] In step 1205, the AF 5 starts a timer to count a first predetermined period of time. For example, but not by way of limitation, the AF 5 may start the timer after, upon, or in response to sending an AF request.

[0125] In step 1206, SMF 32 performs events related to the establishment of a UP path for the PDU Session. Specifically, SMF 32 exchanges control messages with UPF 33 and performs user plane (UP) reconfiguration. Specifically, SMF 32 rearranges or adds a PSA to establish a new UP path to the Target DNAI. The rearrangement or addition of a PSA includes one or any combination of adding, changing, and removing one or more UPFs. However, before the UP path to the new DNAI is activated, application traffic data continues to be routed to the old DNAI.

[0126] In step 1207, if late notification via the NEF is requested by the AF 5, the SMF 32 notifies the NEF 36 of the Target DNAI by invoking the Nsmf_EventExposure_Notify service operation. In step 1208, the NEF 36 performs information mapping and triggers the appropriate Nnef_TrafficInfluence_Notify message. If late direct notification is requested by the AF 5, instead of steps 1207 and 1208, the SMF 32 notifies the AF 5 of the Target DNAI by invoking the Nsmf_EventExposure_Notify service operation. Note that the subscription request for the late (direct) notification includes an indication of "AF acknowledgment to be expected." According to this indication, the SMF 32 waits for a response from the AF 5 before activating the new UP path. The SMF32 does not activate a new UP path (eg, a UP path to a new DNAI) until it receives a positive AF response to the late (direct) notification.

[0127] In step 1209, in response to receiving a late notification before the timer expires, the AF 5 stops the timer. The late notification is based on the occurrence of an event related to the establishment of a UP path for the PDU Session. In step 1210, the AF 5 sends a positive response to the late notification to the NEF 36. Specifically, the AF 5 replies to Nnef_TrafficInfluence_Notify by invoking the Nnef_TrafficInfluence_AppRelocationInfo service operation. The AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation immediately. Alternatively, the AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation after the application layer is ready or after any required application relocation to the Target DNAI is completed. The AF 5 includes an AfAckInfo data type with an "afStatus" attribute set to "SUCCESS" in the payload of the HTTP POST message. This indicates a positive response to the late notification.

[0128] In step 1211, the NEF 36 triggers the appropriate Nsmf_EventExposure_AppRelocationInfo in response to receiving Nsmf_TrafficInfluence_AppRelocationInfo. If the AF 5 receives a late (direct) notification, instead of steps 1210 and 1211, the AF 5 may reply to the Nsmf_EventExposure_Notify by invoking the Nsmf_EventExposure_AppRelocationInfo service operation.

[0129] In step 1212, the SMF 32 exchanges a control message with the UPF 33 to activate the UP reconfiguration (UP Reconfiguration Activation). In other words, the SMF 32 activates the UP path to the new DNAI. After this, the target application traffic data is routed to the new DNAI.

[0130] Fig. 13 shows a case where the first predetermined period expires before the AF 5 receives the late notification. Steps 1301 to 1308 in Fig. 13 are the same as steps 1201 to 1208 in Fig. 12. However, in the case of Fig. 13, the AF 5 receives the late notification (1308) during a graceful period (1310) after the timer expires (1309). When the timer expires (1309), the AF 5 may determine that the processing being performed by the AF 5 has failed due to a delay in the 3GPP core network 3.

[0131] In step 1311, in response to receiving the late notification after the timer expires, the AF 5 sends a negative response to the late notification to the NEF 36. Specifically, the AF 5 replies to the Nnef_TrafficInfluence_Notify by invoking the Nnef_TrafficInfluence_AppRelocationInfo service operation. The AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation immediately. Alternatively, the AF 5 may invoke the Nnef_TrafficInfluence_AppRelocationInfo service operation after the cancellation of the application relocation is complete.

[0132] The AF5 includes in the payload of the HTTP POST message (step 1311) an AfAckInfo data type containing the "afStatus" attribute set to a value other than "SUCCESS". This indicates a negative response to the late notification. The "afStatus" attribute set to a value other than "SUCCESS" indicates a failure cause. Values ​​other than "SUCCESS" may be "TEMP_CONGESTION", "RELOC_NO_ALLOWED", or "OTHER". The value "TEMP_CONGESTION" indicates that application relocation failed due to temporary congestion. The value "RELOC_NO_ALLOWED" indicates that application relocation failed because application relocation is not allowed. The value "OTHER" indicates that application relocation failed due to some other reason. Alternatively, the "afStatus" attribute may explicitly indicate that processing corresponding to the impact of the AF request failed due to processing delays in the 3GPP core network. Additionally or alternatively, the "afStatus" attribute may explicitly indicate that the application relocation procedure failed due to the expiration of a timer governing the procedure in the 3GPP core network. For example, the AF5 may include in the payload of the HTTP POST message (step 1311) an AfAckInfo data type containing an "afStatus" attribute set to the value "Failure_because_5GC_delay" or "RELOC_TIMER_EXPIRED".

[0133] In step 1312, the NEF 36 triggers the appropriate Nsmf_EventExposure_AppRelocationInfo in response to receiving Nsmf_TrafficInfluence_AppRelocationInfo. If the AF 5 receives a late direct notification, instead of steps 1311 and 1312, the AF 5 may reply to the Nsmf_EventExposure_Notify by invoking the Nsmf_EventExposure_AppRelocationInfo service operation.

[0134] In step 1313, SMF 32 exchanges control messages with UPF 33 to restore the UP path to the original DNAI. Alternatively, SMF 32 disables the setting of the UP path to the new DNAI. SMF 32 continues to use the UP path to the original DNAI and cancels the change to the UP path to the new DNAI.

[0135] In the procedure of Fig. 13, if the graceful period (1310) has elapsed before the AF5 receives the late notification, the AF5 may transmit a message indicating a failure in processing corresponding to the effect of the AF request (e.g., a negative response to the late notification) after, in response to, or in response to the graceful period. In the procedure of Fig. 13, the graceful period (1310) may not be provided. In this case, if the timer expires (or the first predetermined period has elapsed) before the AF5 receives the late notification, the AF5 may transmit a message indicating a failure in processing corresponding to the effect of the AF request (e.g., a negative response to the late notification).

[0136] According to the procedure described in this embodiment, if the AF 5 fails to receive a Late notification from the 3GPP core network 3 before the expiration of the first predetermined period after sending the AF request, the AF 5 can determine that a procedure (e.g., UPF relocation or addition) in the 3GPP core network 3 related to AF influence on traffic routing is delayed, and can cancel this procedure. This therefore enables the AF 5 to deal with delays in procedures in the 3GPP core network 3 related to AF influence on traffic routing.

[0137] <Fifth embodiment> This embodiment provides a detailed example of the operation of the AF 5 described in the first embodiment and a detailed example of the operation of the UE 1. The example of the network architecture according to this embodiment is similar to the example described with reference to FIGS.

[0138] In this embodiment, the AF 5 includes the S-EES 71A, the S-EAS 72A, or both. If the AF 5 fails to receive a second message from the 3GPP core network 3 by the expiration of a first predetermined period after sending a first message to the 3GPP core network 3, the AF 5 determines that a procedure in the 3GPP core network 3 related to AF influence on traffic routing (e.g., UPF relocation or addition) is delayed and cancels the ACR procedure. Canceling the ACR procedure involves the AC 12 of the UE 1 continuing to use the S-EAS 72A. To enable this, if the AF 5 includes the S-EES 71A, if the AF 5 does not receive the second message from the 3GPP core network 3 before the expiration of the first predetermined period, the S-EES 71A sends an indication of the failure of the ACR procedure to the EEC 11 of the UE 1. The failure of the ACR procedure is due to a delay in a procedure in the 3GPP core network 3 related to AF influence on traffic routing (e.g., UPF relocation or addition). Thus, the indication of the ACR procedure failure may explicitly indicate that the delay is due to a procedure (e.g., UPF relocation or addition) within the 3GPP core network 3. If the AF5 includes the S-EAS72A, if the AF5 does not receive the second message from the 3GPP core network 3 before the first predetermined period expires, the S-EAS72A requests the S-EES71A to send an indication indicating the ACR procedure failure to the EEC11 of the UE1. In response to receiving the indication, the EEC11 of the UE1 restores (or enables) the profile of the S-EAS72A if the profile of the S-EAS72A has been disabled.

[0139] FIG. 14 illustrates an example of the operation of the AF 5 and the EEC 11 when the AF 5 includes the S-EES 71A. In step 1401, the AF 5 or the S-EES 71A included in the AF 5 detects expiration of a timer that counts a first predetermined period. The timer counts the delay time of a procedure in the 3GPP core network 3 related to AF influence on traffic routing. The first predetermined period can be said to be the maximum allowable delay time. In response to the expiration of the timer, the AF 5 or the S-EES 71A included in the AF 5 determines an ACR failure due to a delay in a procedure in the 3GPP core network 3 related to AF influence on traffic routing (e.g., UPF relocation or addition). In step 1402, after the timer expires, in response or in response, the S-EES 71A transmits an ACR failure notification to the EEC 11 of the UE 1 due to a delay in a procedure in the 3GPP core network 3 related to AF influence on traffic routing (e.g., UPF relocation or addition). The ACR failure notification explicitly or implicitly indicates a failure of the ongoing ACR procedure. The ACR failure notification may include a cause of failure indicating that the failure was due to a delay in a procedure (e.g., UPF relocation or addition) within the 3GPP core network 3 related to AF influence on traffic routing. In step 1403, in response to receiving the ACR failure notification, the EEC 11 restores (or enables) the profile of the S-EAS 72A if the profile of the S-EAS 72A has been disabled.

[0140] FIG. 15 illustrates an example of the operation of the AF 5 and the EEC 11 when the AF 5 includes the S-EAS 72A. In step 1501, the AF 5 or the S-EAS 72A included in the AF 5 detects the expiration of a timer counting a first predetermined period. The timer counts the delay time of a procedure in the 3GPP core network 3 related to AF influence on traffic routing. The first predetermined period can be said to be the maximum allowable delay time. In response to the expiration of the timer, the AF 5 or the S-EAS 72A included in the AF 5 determines that an ACR failure has occurred due to a delay in a procedure in the 3GPP core network 3 related to AF influence on traffic routing (e.g., UPF relocation or addition). In step 1502, after the timer expires, the S-EAS 72A sends an ACR failure notification to the S-EES 71A in response to the expiration of the timer. The ACR failure notification explicitly or implicitly indicates the failure of the ongoing ACR procedure. The ACR failure notification may include a cause of failure indicating that the failure is due to a delay in a procedure (e.g., UPF relocation or addition) in the 3GPP core network 3 related to AF influence on traffic routing. In step 1503, the S-EES 71A sends the ACR failure notification to the EEC 11 of the UE 1. In step 1504, in response to receiving the ACR failure notification, the EEC 11 restores (or enables) the profile of the S-EAS 72A if the profile of the S-EAS 72A is disabled. The ACR failure notification may include a cause of failure indicating that the failure is due to a delay in a procedure (e.g., UPF relocation or addition) in the 3GPP core network 3 related to AF influence on traffic routing.

[0141] 14 or 15 may be, for example, any of the ACR procedures described in Chapter 8.8.2 of Non-Patent Document 3. The first predetermined period may be determined based on the service continuity requirements of the application.

[0142] In the case of the "ACR initiated by the EEC and ACs" procedure (or scenario) described in Chapter 8.2.2.2 of Non-Patent Document 3, the AF5 (e.g., S-EES) may start a timer to count a first predetermined period in parallel with or before step 3 ("T-EAS Discovery") or in parallel with or before step 5 ("ACR Request").

[0143] In the case of the “EEC executed ACR via S-EES” procedure (or scenario) described in Chapter 8.2.2.3 of Non-Patent Document 3, the AF5 (e.g., S-EES) may start a timer to count a first predetermined period in parallel with or before step 3 (“T-EAS Discovery”) or in parallel with or before step 4 (“ACR Request”).

[0144] In the case of the "S-EAS decided ACR" procedure (or scenario) described in chapter 8.2.2.4 of Non-Patent Document 3, the AF5 (e.g., S-EES or S-EAS) may start a timer to count a first predetermined period in parallel with or before step 2 ("ACR Detection") or in parallel with or before step 3 ("T-EAS Discovery").

[0145] In the case of the "S-EES executed ACR" procedure described in Chapter 8.2.2.5 of Non-Patent Document 3, the AF5 (e.g., S-EES) may start a timer to count a first predetermined period in parallel with or before step 2 ("(ACR) Detection"), in parallel with or before step 4 ("Decision of ACR"), or in parallel with or before step 7 ("initiate application traffic influence")

[0146] In the case of the “EEC executed ACR via T-EES” procedure (or scenario) described in Chapter 8.2.2.6 of Non-Patent Document 3, the AF5 (e.g., S-EES) may start a timer to count a first predetermined period in parallel with or before step 2 (“ACR Decision”), in parallel with or before step 3 (“T-EAS Discovery”), or in parallel with or before step 4 (“ACR Request”).

[0147] According to the operations of the AF 5 and the UE 1 described in this embodiment, if the AF 5 fails to receive the second message from the 3GPP core network 3 before the expiration of the first predetermined period, the AF 5 determines that a procedure in the 3GPP core network 3 related to AF influence on traffic routing (e.g., UPF relocation or addition) is delayed, and can cancel this procedure and cancel the ongoing ACR procedure.

[0148] Next, exemplary configurations of UE1 and AF5 according to the above-described embodiments will be described below. FIG. 16 is a block diagram showing an exemplary configuration of UE1. A radio frequency (RF) transceiver 1601 performs analog RF signal processing for communication with a RAN node. The RF transceiver 1601 may include multiple transceivers. The analog RF signal processing performed by the RF transceiver 1601 includes frequency up-conversion, frequency down-conversion, and amplification. The RF transceiver 1601 is coupled to an antenna array 1602 and a baseband processor 1603. The RF transceiver 1601 receives modulation symbol data (or OFDM symbol data) from the baseband processor 1603, generates a transmit RF signal, and provides the transmit RF signal to the antenna array 1602. The RF transceiver 1601 also generates a baseband receive signal based on the receive RF signal received by the antenna array 1602 and provides the baseband receive signal to the baseband processor 1603. The RF transceiver 1601 may include an analog beamformer circuit for beamforming. The analog beamformer circuitry includes, for example, multiple phase shifters and multiple power amplifiers.

[0149] The baseband processor 1603 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication. Digital baseband signal processing includes (a) data compression / decompression, (b) data segmentation / concatenation, (c) transmission format (transmission frame) generation / decomposition, (d) transmission path coding / decoding, (e) modulation (symbol mapping) / demodulation, and (f) generation of OFDM symbol data (baseband OFDM signal) using Inverse Fast Fourier Transform (IFFT). Meanwhile, control plane processing includes communication management for Layer 1 (e.g., transmit power control), Layer 2 (e.g., radio resource management and hybrid automatic repeat request (HARQ) processing), and Layer 3 (e.g., signaling related to attachment, mobility, and call management).

[0150] For example, the digital baseband signal processing by the baseband processor 1603 may include signal processing of a Service Data Adaptation Protocol (SDAP) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, and a Physical (PHY) layer. Also, the control plane processing by the baseband processor 1603 may include processing of a Non-Access Stratum (NAS) protocol, a Radio Resource Control (RRC) protocol, MAC Control Elements (CEs), and Downlink Control Information (DCIs).

[0151] The baseband processor 1603 may perform Multiple Input Multiple Output (MIMO) encoding and precoding for beamforming.

[0152] The baseband processor 1603 may include a modem processor (e.g., a Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., a Central Processing Unit (CPU) or a Micro Processing Unit (MPU)) that performs control plane processing. In this case, the protocol stack processor that performs control plane processing may be shared with the application processor 1604, which will be described later.

[0153] The application processor 1604 is also referred to as a CPU, MPU, microprocessor, or processor core. The application processor 1604 may include multiple processors (multiple processor cores). The application processor 1604 executes a system software program (operating system (OS)) and various application programs (e.g., a calling application, a web browser, a mailer, a camera operation application, and a music playback application) read from the memory 1606 or a memory not shown, thereby realizing various functions of the UE1.

[0154] In some implementations, the baseband processor 1603 and the application processor 1604 may be integrated on a single chip, as indicated by the dashed line (1605) in Figure 16. In other words, the baseband processor 1603 and the application processor 1604 may be implemented as a single System on Chip (SoC) device 1605. An SoC device may also be called a system Large Scale Integration (LSI) or a chipset.

[0155] The memory 1606 is volatile memory, nonvolatile memory, or a combination thereof. The memory 1606 may include multiple physically independent memory devices. The volatile memory may be, for example, static random access memory (SRAM), dynamic RAM (DRAM), or a combination thereof. The nonvolatile memory may be mask read only memory (MROM), electrically erasable programmable ROM (EEPROM), flash memory, a hard disk drive, or any combination thereof. For example, the memory 1606 may include an external memory device accessible from the baseband processor 1603, the application processor 1604, and the SoC 1605. The memory 1606 may also include an internal memory device integrated within the baseband processor 1603, the application processor 1604, or the SoC 1605. Furthermore, the memory 1606 may include memory within a universal integrated circuit card (UICC).

[0156] The memory 1606 may store one or more software modules (computer programs) 1607 including instructions and data for performing the processes described in the above embodiments by the UE 1. In some implementations, the baseband processor 1603 or the application processor 1604 may be configured to read and execute the software modules 1607 from the memory 1606 to perform the processes described in the above embodiments using the drawings by the UE 1.

[0157] It should be noted that the control plane processing and operations performed by UE1 described in the above embodiment can be realized by elements other than the RF transceiver 1601 and the antenna array 1602, namely, at least one of the baseband processor 1603 and the application processor 1604, and the memory 1606 storing the software module 1607.

[0158] FIG. 17 shows an example configuration of a device providing the AF5 function. Devices providing other network functions, such as the AMF31, SMF32, NEF36, ECS6, EES71, and EAS72, may also have a configuration similar to that shown in FIG. 17. Referring to FIG. 17, the AF5 (or the EES71 or EAS72) includes a network interface 1701, a processor 1702, and a memory 1703. The network interface 1701 is used, for example, to communicate with other network functions (NFs) or nodes. The network interface 1701 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

[0159] The processor 1702 may be, for example, a microprocessor, a microprocessing unit (MPU), or a central processing unit (CPU). The processor 1702 may include multiple processors.

[0160] The memory 1703 is composed of volatile memory and nonvolatile memory. The memory 1703 may include multiple physically independent memory devices. The volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof. The nonvolatile memory is, for example, Mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or a hard disk drive, or any combination thereof. The memory 1703 may include storage located remotely from the processor 1702. In this case, the processor 1702 may access the memory 1703 via the network interface 1701 or an I / O interface (not shown).

[0161] The memory 1703 may store one or more software modules (computer programs) 1704 including instructions and data for performing processing by the AF5 (or the EES71, EAS72) described in the above-described embodiments. In some implementations, the processor 1702 may be configured to read and execute the software modules 1704 from the memory 1703, thereby performing processing by the AF5 (or the EES71, EAS72) described in the above-described embodiments.

[0162] As explained using Figures 16 and 17, each of the processors possessed by UE1, AF5 (or EES71, EAS72), and other network functions in the above-mentioned embodiments executes one or more programs including a set of instructions for causing a computer to perform the algorithms explained using the drawings.

[0163] The program includes instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more functions described in the embodiments. The program may be stored in a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technologies, CD-ROM, digital versatile disk (DVD), Blu-ray® disk or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The program may also be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, transitory computer-readable media or communication media include electrical, optical, acoustic, or other forms of propagated signals.

[0164] The above-described embodiments are merely examples of application of the technical ideas obtained by the inventors of the present invention. In other words, the technical ideas are not limited to the above-described embodiments, and various modifications are possible.

[0165] For example, some or all of the above embodiments can be described as, but are not limited to, the following supplementary notes.

[0166] (Appendix 1) An Application Function (AF) node, Memory and at least one processor coupled to the memory; Equipped with The at least one processor: Sending a first message to the core network regarding an event related to the establishment of a user plane path for a Protocol Data Unit (PDU) Session; If the AF node receives a second message from the core network based on the occurrence of the event before a first predetermined period of time expires after transmitting the first message, transmitting a positive response to the second message to the core network; If the AF node does not receive the second message from the core network before the first predetermined period expires, sending a third message to the core network indicating a failure of the AF node's processing of the event. It is configured as follows: AF node. (Appendix 2) the at least one processor determines that the event has failed if the second message is not received from the core network before the first predetermined period expires. AF nodes as described in Appendix 1. (Appendix 3) the at least one processor is configured, in response to transmitting the first message, to start a timer to count the first predetermined period. 1. An AF node according to claim 1 or 2. (Appendix 4) the at least one processor is configured to transmit the third message in response to the AF node receiving the second message during a second predetermined period after expiration of the first predetermined period. AF node according to any one of Supplementary Note 1 to 3. (Appendix 5) The core network includes a Session Management Function (SMF) node, a Policy Control Function (PCF) node, and a Network Exposure Function (NEF) node; The at least one processor: Sending the first message to the SMF node directly or via one or both of the NEF node and the PCF node; receiving the second message from the SMF node directly or via the NEF node; sending the positive response to the second message or the third message to the SMF node directly or via the NEF node; It is configured as follows: 5. The AF node according to any one of Supplementary Note 1 to 4. (Appendix 6) The event is enforcement of a user plane path setting for the PDU Session, the at least one processor is configured to receive a first notification from the SMF node prior to sending the first message, the first notification being a prior notification of the event; the first message includes an affirmative response to the first notification; the second message is sent by the SMF node after the event is completed and before activating the user plane path. AF nodes as described in Appendix 5. (Appendix 7) The event is enforcement of a user plane path setting for the PDU Session, the first message includes a request to cause the event to the SMF node; the second message being an advance notice of the event; AF nodes as described in Appendix 5. (Appendix 8) The event is enforcement of a user plane path setting for the PDU Session, the first message includes a request to cause the event to the SMF node; the second message is sent by the SMF node after the event is completed and before activating the user plane path. AF nodes as described in Appendix 5. (Appendix 9) the second message relates to a change from an original user plane path to a new user plane path for traffic of the PDU Session; the third message causes the SMF node to continue using the original user plane path and cancel the change from the original user plane path to the new user plane path; AF nodes as described in Appendix 5. (Appendix 10) the second message relates to a Data Network Access Identifier (DNAI) change and is sent by the SMF node before setting up or activating the new user plane path towards the new DNAI; AF nodes as described in Appendix 9. (Appendix 11) the AF node includes a Source Edge Enabler Server (S-EES); The at least one processor is configured to, if the second message is not received from the core network before the first predetermined period expires, send an indication to an Edge Enabler Client (EEC) of a User Equipment (UE) indicating a failure of an Application Context Relocation (ACR) procedure, including a transfer of application context from a Source Edge Application Server (S-EAS) to a Target EAS (T-EAS). 11. The AF node according to any one of Supplementary Notes 1 to 10. (Appendix 12) the AF node includes a Source Edge Application Server (S-EAS); The at least one processor is configured to, if the second message is not received from the core network before the first predetermined period expires, request a Source Edge Enabler Server (S-EES) to send an indication to an Edge Enabler Client (EEC) of a User Equipment (UE) indicating a failure of an Application Context Relocation (ACR) procedure including a transfer of application context from the S-EAS to a Target EAS (T-EAS). 11. The AF node according to any one of Supplementary Notes 1 to 10. (Appendix 13) 1. A method performed by an Application Function (AF) node, comprising: sending a first message to the core network regarding an event related to the establishment of a user plane path for a Protocol Data Unit (PDU) Session; If the AF node receives a second message from the core network based on the occurrence of the event before a first predetermined period of time expires after transmitting the first message, transmitting a positive response to the second message to the core network; and if the AF node does not receive the second message from the core network before the first predetermined period expires, sending a third message to the core network indicating a failure of the AF node's processing of the event; A method for providing (Appendix 14) A program for causing a computer to perform a method for an Application Function (AF) node, the method comprising: sending a first message to the core network regarding an event related to the establishment of a user plane path for a Protocol Data Unit (PDU) Session; If the AF node receives a second message from the core network based on the occurrence of the event before a first predetermined period of time expires after transmitting the first message, transmitting a positive response to the second message to the core network; and if the AF node does not receive the second message from the core network before the first predetermined period expires, sending a third message to the core network indicating a failure of the AF node's processing of the event; A program that includes: (Appendix 15) User Equipment (UE), Memory and at least one processor coupled to the memory; Equipped with The at least one processor: Provides Edge Enabler Client (EEC) functionality, receiving an indication from a Source Edge Enabler Server (S-EES) indicating a failure of an Application Context Relocation (ACR) procedure involving the transfer of application context from the Source Edge Application Server (S-EAS) to the Target EAS (T-EAS); In response to receiving the indication, if the S-EAS profile is disabled, enabling the S-EAS profile. It is configured as follows: The failure of the ACR procedure is due to a delay in establishing a user plane path corresponding to a Protocol Data Unit (PDU) Session; UE. (Appendix 16) A method performed by User Equipment (UE), comprising: Provide Edge Enabler Client (EEC) functionality; receiving an indication from a Source Edge Enabler Server (S-EES) indicating a failure of an Application Context Relocation (ACR) procedure involving the transfer of application context from the Source Edge Application Server (S-EAS) to the Target EAS (T-EAS); and In response to receiving the indication, if the S-EAS profile is disabled, enabling the S-EAS profile; Equipped with The method, wherein the failure of the ACR procedure is caused by a delay in setting up a user plane path corresponding to a Protocol Data Unit (PDU) Session. (Appendix 17) A program for causing a computer to perform a method for User Equipment (UE), the method comprising: Provide Edge Enabler Client (EEC) functionality; receiving an indication from a Source Edge Enabler Server (S-EES) indicating a failure of an Application Context Relocation (ACR) procedure involving the transfer of application context from the Source Edge Application Server (S-EAS) to the Target EAS (T-EAS); and In response to receiving the indication, if the S-EAS profile is disabled, enabling the S-EAS profile; Equipped with The failure of the ACR procedure is caused by a delay in setting up a user plane path corresponding to a Protocol Data Unit (PDU) Session, the program.

[0167] This application claims priority based on Japanese Patent Application No. 2021-084222, filed on May 18, 2021, the disclosure of which is incorporated herein in its entirety. [Explanation of symbols]

[0168] 1. User Equipment (UE) 2. Access Network (AN) 3 3GPP Core Network 5 Application Function (AF) 6 Edge Configuration Server (ECS) 7. Edge Data Network (EDN) 8 Public Land Mobile Network (PLMN) 11 Edge Enabler Client (EEC) 12 Application client (AC) 31 Access and Mobility management Function (AMF) 32 Session Management Function (SMF) 33 User Plane Function (UPF) 34 Policy Control Function (PCF) 35 Unified Data Management (UDM) 36 Network Exposure Function (NEF) 41, 42, 43 Data Network (DN) 71 Edge Enabler Server (EES) 72 Edge Application Server (EAS) 1603 Baseband Processor 1604 Application Processor 1606 memory 1607 Module 1702 processor 1703 memory 1704 Module

Claims

1. An Edge Application Server (EAS) node, Memory and at least one processor coupled to the memory; Equipped with The at least one processor If a failure of an Application Context Relocation (ACR) procedure between the source EAS node and the target EAS node is detected, sending a first message to an Edge Enabler Server (ESS) node, the first message including a failure cause, indicating cancellation of the ACR procedure; EAS node.

2. A method performed by an Edge Application Server (EAS) node, comprising: If a failure of an Application Context Relocation (ACR) procedure between the source EAS node and the target EAS node is detected, sending a first message to an Edge Enabler Server (ESS) node indicating cancellation of the ACR procedure, the first message including a failure cause; A method for providing

Images