Edge Enabler Server (EES), Edge Enabler Client (EEC), and methods thereof.

Abstract

In the present invention, a first server (5) receives, from a request entity (2), a request to generate an Edge Enabler Client (EEC) context. Once it has been determined, by verifying the security credentials included in the request, that accessing an edge data network (EDN) (4) can be permitted, the first server (5) attempts to identify, on the basis of a selection criterion, a second server (6) arranged in the EDN (4). The selection criterion includes a requirement indicated by an AC Profile included in the request. If accessing the EDN (4) cannot be permitted or if the requirement indicated by the AC Profile is not met, the first server (5) transmits, to the request entity (2), a second response message including a cause of failure that is information indicating that the second server (6) could not be identified. The invention can contribute to, for example, providing selection criteria that are appropriate for identifying an edge server.

Description

Technical Field

[0001] The present disclosure relates to wireless communication networks, and more particularly to devices and methods for edge computing.

Background Art

[0002] Edge computing aims to move applications, data, and computing power (services) from centralized points (e.g., centralized data centers) to locations closer to the user (e.g., distributed data centers). The Industry Specification Group called Multi-access Edge Computing (MEC) of the European Telecommunications Standards Institute (ETSI) has standardized application platforms and APIs for edge computing. For example, MEC provides cloud computing capabilities and an information technology (IT) service environment within a radio access network (RAN) close to mobile subscribers to application developers and content providers. This environment provides direct access to radio network information (e.g., subscriber location and cell load) that can be leveraged by applications and services, in addition to ultra-low latency and high bandwidth.

[0003] 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 1). This 3GPP architecture is called the EDGEAPP architecture. The EDGEAPP architecture provides a specification for an enabling layer to facilitate communication between application clients (ACs) running on user equipment (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 the UE via the Edge Enabler Client (EEC) of the UE by the Edge Configuration Server (ECS) and Edge Enabler Server (EES).

[0004] An AC running on a UE needs to discover server applications on the edge cloud (i.e., EAS in 3GPP SA6 terminology, or MEC application in ETSI ISG MEC terminology). To discover server applications, the AC can utilize other clients on the UE, i.e., EECs. EECs provide ACs with the discovery of available EASs in the edge data network.

[0005] The UE is initially provisioned by the ECS with the information necessary to connect to the Edge Data Network (EDN). The EDN includes one or more EESs and one or more EASs. More specifically, the UE's EEC communicates with the ECS for service provisioning. Service provisioning allows the EEC to configure information about available edge computing services based on the UE location, service requirements, service performance, and connectivity. This configuration includes address information necessary for the EEC to establish connections with one or more EESs located in the EDN.

[0006] To provide this service, the EEC makes a service provisioning request to the ECS to request resources for providing services on the EDN, as well as information regarding connectivity or configuration. This connectivity or configuration information includes, for example, information about available edge computing services, information about servers within the EDN, identifiers (IDs) and address information for those servers (e.g., Internet Protocol (IP) address, Single-Network Slice Selection Assistance Information (S-NSSAI), and service area information), EDN configuration information, and configuration information about the Edge Data Network for which the EEC will establish connectivity.

[0007] The EEC performs a registration procedure called EEC registration with the EES to provide information that can be used by the EES in edge computing services. EEC registration enables the EES to initialize, update, and remove information resources related to the EEC. It also enables the sharing of the EEC Context among various entities (UEs and Application Servers) in the EDGEAPP architecture. The determination of whether or not EEC registration is permitted (EEC registration permission determination) is based on security credentials and / or at least one Application Client Profile (AC Profile(s)) provided by the EEC. To register for EEC, the EEC submits an EEC registration request to the EES.

[0008] According to Non-Patent Document 1, the EES verifies the Security credentials provided by the EEC and, if an AC Profile(s) is provided by the EEC, determines whether it can meet the requirements contained in the AC Profile(s).

[0009] Hereinafter, entities that perform EEC registration will be collectively referred to as requesting entities. Also, EEC registration requests (EEC registration request or EEC registration update request) will be collectively referred to simply as requests. [Prior art documents] [Non-patent literature]

[0010] [Non-Patent Document 1] 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 [Overview of the project] [Problems that the invention aims to solve]

[0011] The inventors have examined the EDGEAPP architecture and identified various challenges. One of these challenges concerns the identification (or selection, determination, or discovery) of EAS(s) that meet the requirements included in a request from a requesting entity (e.g., EEC). Currently, it is not sufficiently clear how an EES specifically identifies EAS(s) in EEC registration. In other words, the 3GPP SA6 working group has not yet fully defined the criteria or logic for identifying preferred or suitable servers (hereinafter referred to as edge servers) located in the edge data network in EEC registration. In the 3GPP EDGEAPP architecture, an edge server includes one or more EESs and one or more EASs.

[0012] Another issue concerns the behavior of the requesting entity (e.g., EEC) when an EEC registration request fails. Currently, it is not sufficiently clear how the requesting entity should behave when an EEC registration request fails.

[0013] One of the objectives that the embodiments disclosed herein seek to achieve is to provide an apparatus, method, and program that contribute to solving at least one of the problems described above. It should be noted that this objective is only one of several objectives that the embodiments disclosed herein seek to achieve. Other objectives or problems and novel features will be revealed in this specification or in the accompanying drawings. [Means for solving the problem]

[0014] In a first embodiment, the first server includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor includes security credentials and at least one Application Client Profile, receives a request from the requesting entity to generate an Edge Enabler Client (EEC) Context which is information about the requesting entity, verifies the security credentials to determine whether access to the edge data network can be permitted, and if access to the edge data network can be permitted, attempts to identify a second server located within the edge data network based on at least one selection criterion. If the at least one processor identifies the second server, it is configured to send a first response message to the requesting entity which includes information indicating that the request was successful. The at least one selection criterion includes requirements shown in the at least one Application Client Profile. If access to the edge data network cannot be permitted, or if the requirements shown in the at least one Application Client Profile are not met, the at least one processor is configured to send a second response message to the requesting entity which includes a cause of failure which is information indicating that the second server could not be identified.

[0015] In the second aspect, the method performed by the first server includes the following steps: (a) Receiving a request from the requesting entity to generate an Edge Enabler Client (EEC) Context which includes security credentials and at least one Application Client Profile, and which is information about the requesting entity. (b) Determine whether or not to allow access to the edge data network by verifying the Security credentials. (c) If access to the edge data network can be permitted, attempt to identify a second server located within the edge data network based on at least one selection criterion. (d) If the second server is identified, send a first response message to the requesting entity containing information indicating that the request was successful, wherein the at least one selection criterion includes the requirements specified in the at least one Application Client Profile, and (e) If access to the edge data network is not permitted, or if the requirements specified in the at least one Application Client Profile are not met, send a second response message to the requesting entity that includes a cause of failure, which is information indicating that the second server cannot be identified.

[0016] In a third aspect, the requesting entity includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to send a request to a first server to generate an Edge Enabler Client (EEC) Context, which is information relating to the requesting entity, and to receive a response message from the first server to the request, which includes security credentials and at least one Application Client Profile. The at least one processor is configured to send the request to a first server different from the first server if the response message includes a cause of failure, which is information indicating that a second server cannot be identified, wherein the cause of failure is included in the response message if access to the edge data network is not permitted or if the requirements indicated in the at least one Application Client Profile are not met.

[0017] In the fourth aspect, the method performed by the requesting entity includes the following steps: (a) Send a request to a first server to generate an Edge Enabler Client (EEC) Context which includes Security credentials and at least one Application Client Profile, and which is information relating to the request entity. (b) receiving a response message for the request from the first server, (c) If the response message contains a cause of failure which is information indicating that the second server cannot be identified, send the request to a first server different from the first server, wherein the cause of failure is included in the response message if access to the edge data network is not permitted or if the requirements specified in the at least one Application Client Profile are not met.

[0018] In the fifth aspect, the program includes a set of instructions (software code) for causing a computer to perform the method according to the above-described second or fourth aspect when loaded into the computer.

Advantages of the Invention

[0019] According to the above aspect, it is possible to provide an apparatus, a method, and a program that contribute to solving at least one of the above-described problems.

Brief Description of the Drawings

[0020] [Figure 1] It is a diagram showing an example of the architecture of a network according to an embodiment. [Figure 2] It is a flowchart showing an example of the operation of the first server according to an embodiment. [Figure 3] It is a flowchart showing an example of the operation of the first server according to an embodiment. [Figure 4] It is a flowchart showing an example of the operation of a request entity according to an embodiment. [Figure 5] It is a sequence diagram showing an example of the operation of EEC and EES according to an embodiment. [Figure 6] It is a flowchart showing an example of the operation of a request entity according to an embodiment. [Figure 7] It is a sequence diagram showing an example of the operation of EEC and EES according to an embodiment. [Figure 8] It is a sequence diagram showing an example of the operation of EEC and ECS according to an embodiment. [Figure 9] It is a block diagram showing a configuration example of a UE according to an embodiment. [Figure 10] It is a block diagram showing a configuration example of a server according to an embodiment.

Modes for Carrying Out the Invention

[0021] The following describes specific embodiments in detail with reference to the drawings. In each drawing, the same or corresponding elements are denoted by the same reference numeral, and redundant explanations are omitted where necessary for clarity.

[0022] The multiple embodiments described below can be implemented independently or in combination as appropriate. These multiple embodiments have novel features that differ from each other. Therefore, these multiple embodiments contribute to solving different objectives or problems and contribute to producing different effects.

[0023] The following embodiments are described primarily with reference to 3GPP systems (e.g., 5G systems (5GS)). However, these embodiments may be applied to other wireless communication systems.

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

[0025] In the example in Figure 1, User Equipment (UE) 1 includes Edge Enabler Client (EEC) 2 and one or more Application Clients (ACs) 3. In other words, EEC 2 and one or more ACs 3 are located on and operate on UE 1. Although not explicitly shown in Figure 1, UE 1 communicates with the 3GPP core network 8 (e.g., 5G Core (5GC)) via the access network (e.g., Radio Access Network (e.g., NG Radio Access Network (NG-RAN))). This allows UE 1 to provide connectivity to the data network via the access network and the 3GPP core network 8 to EEC 2 and AC(s) 3.

[0026] EEC2 provides the supporting functions required by AC(s)3. Specifically, EEC2 provides provisioning of configuration information to enable the exchange of application data traffic with Edge Application Servers (EAS). Furthermore, EEC2 provides functionality for discovering one or more EASs available within the Edge Data Network (EDN)4. EEC2 uses the EAS endpoint information obtained through EAS discovery to route outgoing application data traffic to the EAS. In addition, EEC2 provides functionality for the registration, update, and de-registration of EES5 and EAS(s)6.

[0027] Each AC3 is an application running on UE1. Each AC3 connects to one or more EASs to utilize edge computing services and exchanges application data traffic with these EASs.

[0028] A single Edge Data Network (EDN) 4 includes one or more Edge Enabler Servers (EES) 5 and one or more Edge Application Servers (EASs) 6. The EDN 4 may also be a Local Area Data Network (LADN). An LADN allows restricted access to a DN (and its corresponding Data Network Name (DNN)) in one or more specific areas only. Outside of these areas, the UE 1 cannot access the DN (and DNN). The areas where an LADN DNN is available are called LADN service areas and are configured within the network as a set of Tracking Areas (TAs). DNNs that do not use the LADN feature do not have an LADN service area and are not restricted by this feature. LADN service areas are provided to the UE 1 by the Access and Mobility Management Function (AMF) within the 3GPP core network 8 when the UE 1 registers. This allows the UE 1 to know which areas the LADN (or EDN) is available in and not attempt to access the LADN (or EDN) outside of these areas.

[0029] Each EES5 provides supporting functions required by EAS(s)6 and EEC2. Specifically, each EES5 provides EEC2 with provisioning of configuration information, thereby enabling the exchange of application data traffic with EAS(s)6. Each EES5 provides registration, update, and de-registration functions for EEC2 and EAS(s)6. Each EES5 provides application context transfer functions between EESs. This function is required for edge application mobility (or application context relocation) for service continuity. Edge application mobility relocates the application context or application instance, or both, relating to a user (i.e., AC) from the source EAS (or EDN or LADN) to the target EAS (or EDN or LADN). Edge application mobility is triggered by UE mobility events or non-UE mobility events. UE mobility events include, for example, UE mobility within the EDN, UE mobility between EDNs, and UE mobility related to the LADN. Non-UE mobility events include, for example, overload conditions of the EAS or EDN, and maintenance of the EAS (e.g., graceful shutdown of the EAS).

[0030] Furthermore, each EES5 supports the functionality of an Application Programming Interface (API) invoker and an API exposing function. Each EES5 may interact with the 3GPP core network 8 directly (e.g., via a Policy Control Function (PCF)) or indirectly (e.g., via a Network Exposure Function (NEF) or Service Capability Exposure Function (SCEF)) to access the services and capabilities of network functions within the 3GPP core network 8. Each EES5 may support the external exposure of the services and capabilities of 3GPP network functions to EAS(s)6.

[0031] Each EAS6 is located on EDN4 and runs the application server functionality. The application server functionality may be available only at the edge. In other words, the application server functionality may be available only as an EAS. However, the application server functionality may be available both at the edge and in the cloud. In other words, the application server functionality may be available as an EAS and also as an application server in the cloud. Here, the cloud refers to a central cloud located further away from UE1 than EDN4. Therefore, an application server in the cloud refers to a server located in a centralized location (e.g., a centralized data center). Each EAS6 may consume or utilize 3GPP core network capabilities. Each EAS6 may directly invoke the 3GPP core network capabilities API. Alternatively, each EAS6 may consume or utilize 3GPP core network capabilities via EES5, or via NEF or SCEF.

[0032] Edge Configuration Server (ECS) 7 provides the supporting functions required by EEC2 to connect to EES(s) 5. Specifically, ECS7 provides provisioning of edge configuration information to EEC2. This edge configuration information includes information for EEC2 to connect to EES(s) 5 (e.g., service area information applicable to LADN) and information for establishing a connection with EES(s) 5 (e.g., Uniform Resource Identifier (URI)). ECS7 provides registration, update, and de-registration functions for EES(s) 5. Furthermore, ECS7 supports API invoker and API exposing function functions. ECS7 may interact directly (e.g., via PCF) or indirectly (e.g., via NEF or SCEF) with the 3GPP core network 8 to access the services and capabilities of network functions within the 3GPP core network 8. ECS7 may be located within the domain of a Mobile Network Operator (MNO) providing the 3GPP core network 8, or it may be located within the third-party domain of a service provider (e.g., Edge Computing Service Provider (ECSP)).

[0033] The configuration example in Figure 1 shows only representative elements for the sake of explanation. For example, ECS7 may be connected to multiple EDNs, including EDN4.

[0034] Figure 2 is a flowchart illustrating an example of the operation of the first server according to this embodiment. The first server attempts to identify (discover, select, or determine) a preferred or appropriate edge server located in EDN4 during EEC registration. In one example, the first server may be EES5 and may attempt to identify one or more EAS(s) in response to a request from EEC2 of UE1.

[0035] In step 201, the first server receives a request from a requesting entity. The requesting entity may be EEC2, and the first server may be EES5. The request may be an EEC registration request or an EEC registration update request. In this specification, the request is also referred to as an EEC registration request.

[0036] In step 202, the first server, upon receiving the request, verifies the Security credentials included in the request. If, as a result of verifying the Security credentials, the first server determines that it can grant access to the edge data network (YES in step 203), the procedure proceeds to step 204. In step 204, the first server attempts to identify a second server located within EDN4 that satisfies at least one selection criterion. In other words, the first server identifies a second server located within EDN4 based on at least one selection criterion, where at least one factor considered in the at least one selection criterion includes requirements included in the request (at least one AC Profile (AC Profile(s))).

[0037] An AC Profile(s) may represent multiple items. Each item represents one or more sets of characteristics. For example, it may include at least one of the following: “Application Client Type”, “Application Client Schedule”, “Expected Application Client Geographical Service Area”, “Service Continuity Support”, or “List of EASs”. The Application Client Type indicates the application category or type (e.g., V2X) of the AC3. The Application Client Schedule indicates the expected operation schedule of the AC3, e.g., time window. The Expected Application Client Geographical Service Area indicates the expected location(s) of the UE1 within the expected operation schedule of the AC3, e.g., route. Service Continuity Support indicates whether service continuity support is required for the AC3. The List of EASs includes the EAS ID and may further include Expected Service Key Performance Indicators (KPIs) and Minimum required Service Key Performance Indicators (KPIs). Service KPIs represent the service characteristics required by AC3.These service characteristics include, for example, at least one of the following: connection bandwidth, maximum request rate to be generated by the AC, maximum response time, maximum compute resources required by the AC, maximum memory resources required by the AC, or information specific to the AC type (e.g., video, virtual reality (VR), etc.).

[0038] The first server may identify EAS(s) that match the provided AC Profile. In this case, the first server may identify EAS(s) that match all items included in the AC Profile. Alternatively, the first server may identify EAS(s) that match at least one item included in the AC Profile. Alternatively, the first server may identify EAS(s) that match all items included in the AC Profile except for the “List of EASs”. Alternatively, the first server may identify EAS(s) that match at least one item included in the AC Profile except for the “List of EASs”.

[0039] For example, if the AC Profile includes Expected Service KPIs, the first server may identify EAS(s) that match at least one item included in the Expected Service KPIs. Alternatively, the first server may identify EAS(s) that match all items included in the Expected Service KPIs. Furthermore, if the Application Client profile includes items other than “List of EASs” (i.e., “Application Client Type”, “Application Client Schedule”, “Expected Application Client Geographical Service Area”, “Service Continuity Support”), in addition to the aforementioned Expected Service KPI matches, the first server may identify EAS(s) that also match at least one of the other items.

[0040] For example, if the AC Profile includes Minimum required Service KPIs, the first server may identify EAS(s) that match at least one item included in the Minimum required Service KPIs. Alternatively, the first server may identify EAS(s) that match all items included in the Minimum required Service KPIs. Furthermore, if the Application Client profile includes items other than “List of EASs” (i.e., “Application Client Type”, “Application Client Schedule”, “Expected Application Client Geographical Service Area”, “Service Continuity Support”), the first server may identify EAS(s) that match at least one of these other items in addition to the Minimum required Service KPIs matches described above.

[0041] If multiple AC Profiles are provided, the first server identifies the EAS(s) on an AC Profile basis, as described above. Here, "identifying the EAS(s)" may mean that the EAS information (e.g., characteristics, performance, status) matches the information about the Application Client included in the AC Profile. Alternatively, this may mean that the EAS information (e.g., characteristics, performance, status) satisfies the conditions for the Application Client included in the AC Profile.

[0042] The first server may exclude from its selection any second server that it determines, based on its selection criteria, does not meet the requirements (AC Profile(s)) included in the request. In the case of selection (or determination, discovery, or identification) of EAS(s) by the first server, the second server is the EAS. In this case, other factors considered in at least one of the selection criteria may include at least one of the following: the congestion status of servers located within EDN4, the location of UE1 (UE location), and the operational status of the second server (i.e., EAS).

[0043] The server congestion status may indicate whether or not the server is congested. Alternatively, the congestion status may indicate one of three or more congestion levels (e.g., no congestion, low congestion, medium congestion, high congestion). The congestion status may also be called the load status. In one example, the first server may identify a second server that is not congested and meets the remaining selection criteria. In another example, the first server may exclude the second server, which has been determined to be congested (high load), from the selection process.

[0044] The second server may dynamically notify the first server of its congestion status. More specifically, the second server may notify the first server of its congestion status when registering the second server with the first server, and may also notify the first server of updates to its congestion status when the congestion status changes. Specifically, each EAS6 may notify the EES5 of its congestion status in the Edge Application Server Registration procedure, and may notify the EES5 of updates to its congestion status in the Edge Application Server Registration Update procedure. Alternatively, the second server may periodically notify the first server of its congestion status.

[0045] Alternatively, the first server may monitor the availability of the second server. More specifically, if the first server determines that the second server is unable to provide services due to a failure of the second server or a failure of the communication path to the second server, the first server may manage the second server as being in a critically congested state. Alternatively, if the second server is scheduled to perform maintenance or otherwise interrupt its services, the second server may notify the first server of this. For example, the first server may exclude the second server, which it has determined is unable to provide services, from its selection criteria. Alternatively, the first server may obtain the congestion status of the second server from a Network Data Analytics Function (NWDAF), which is not explicitly shown in Figure 1. In this case, the first server can obtain congestion information for each second server, each EAS, or each EES by subscribing to the congestion-related services provided by the NWDAF.

[0046] The second server may determine whether or not there is congestion and provide the first server with congestion status information indicating whether or not there is congestion. This congestion status information is not limited to two levels. For example, the second server may identify one of three or more congestion levels (e.g., no congestion, low congestion, medium congestion, high congestion) and inform the first server of the identified congestion level. In this case, the congestion status information may indicate one of the three or more congestion levels.

[0047] The UE location may identify the network to which UE1 is connected or the position of the UE. The value of the UE location may be a Cell Identity (ID), Tracking Area Identity (TAI), Global Positioning System (GPS) coordinates, or a civic address. The selection criteria for the UE location for EAS(s) selection by EES5 may require that the location of UE1 is within the EAS service area. The EAS service area may be a topological service area or a geographical service area. A topological service area may be defined by one or more cell IDs or by one or more TAIs. In one example, the first server may identify a second server whose UE location is within the EAS (second server) service area and that satisfies the remaining selection criteria. In another example, the first server may exclude a second server that is determined to be outside the EAS (second server) service area from selection.

[0048] The selection criteria for UE locations for EAS(s) selection by EES5 may require that the location of UE1 be within the EAS service area. The EAS service area may be a topological service area (e.g., Cell ID(s), or TAI(s)) or a geographical service area. The EAS service area may be the same as or a subset of the EDN service area. The EAS service area may be the same as or a subset of the EES service area.

[0049] If the verification of security credentials in step 202 results in the first server being unable to grant access to the edge data network (No in step 203), the procedure proceeds to step 205. In step 205, the first server responds to the request with a response message containing a failure cause indicating that it is unable to grant access to the edge data network. In step 205, the first server may also respond to the request with a response message containing a failure cause indicating that it is unable to identify the second server (EAS).

[0050] If the identification of a second server that meets the selection criteria was successful in step 204 (YES in step 206), the procedure proceeds to step 207. In step 207, the first server (ie, EES5) sends a response message to the requesting entity (ie, EEC2) that contains information indicating that the request was successful.

[0051] In response to this, if the identification of a second server that satisfies the selection criteria in step 204 fails (NO in step 206), the procedure proceeds to step 208. In step 208, the first server (i.e., EES5) responds to the request with a response message that includes a failure cause indicating that it cannot meet the requirements included in the request. In step 208, the first server (i.e., EES5) may also respond to the request with a response message that includes a failure cause indicating that it cannot identify a second server (EAS).

[0052] According to the operation of the first server described above, the first server can identify, discover, select, or determine a preferred or appropriate second server based on the EEC registration request sent by the requesting entity, taking into account the various requirements contained in the request.

[0053] The first server may distinguish between a response message containing the failure cause sent to a requesting entity when the second server is congested and a response message containing the failure cause sent when the second server cannot find (identify) it. For example, the value of the failure cause set in the response message when the second server is congested may be different from the value set in the response message when the second server cannot find (identify) it. This allows the requesting entity to distinguish between the types of response messages (or failure cause types). Furthermore, the requesting entity may perform different actions depending on the type of response message (or failure cause type).

[0054] If the first server (e.g., EES5) responds to a request with a response message containing a failure cause based on the selection criteria for Application Client profiles performed during EEC registration (and the second server cannot find (identify) it), the response message may indicate an error or status dependent on the request entity, specifically an HTTP Status code 404 Not Found. The failure cause included in the response message may be a value indicating that the information or conditions included in the Application Client profiles cannot be met, specifically "RESOURCE_NOT_FOUND". Note that the failure based on the selection criteria for Application Client profiles here may also be a failure when no EAS(s) matching the Application Client profiles can be found. In this case, if the request entity (e.g., EEC2) receives a response message containing a failure cause, it may act as follows: EEC2 aborts the EEC registration. Alternatively, EEC2 may resend the EEC registration request. If the number of retries reaches a predetermined maximum, EEC2 aborts the EEC registration. Alternatively, EEC2 may send an EEC registration update request. Alternatively, EEC2 may send an EEC de-registration request. Alternatively, EEC2 may inform AC3 of the cause of failure (or error). EEC2 may map the cause of failure (or error) to an AC-specific cause of failure (or error). Alternatively, EEC2 may transparently forward the cause of failure (or error) to AC3. Alternatively, EEC2 may suppress the sending of an EEC registration request or an EEC registration update request based on the cause of failure in the response message.Specifically, EEC2 may suppress the sending of EEC registration requests or EEC registration update requests until it modifies the Application Client profiles or some of the information contained therein. In other words, EEC2 may suppress the sending of EEC registration requests or EEC registration update requests that request or contain the same information resource (EEC Context) as the failed request until it modifies the Application Client profiles or some of the information contained therein. Alternatively, EEC2 may send an EEC registration request to a different EES than EES5. This different EES may be pre-configured in the UE or Mobile Equipment (ME) during the service provisioning procedure. Furthermore, this different EES may be selected based on a policy pre-configured in the UE or ME, or based on the AC3 policy. In addition, if EEC registration fails for all EES(s) configured in the UE or ME, EEC2 may execute a service provisioning request procedure to ECS7 to obtain new EES(s) information from ECS7, and then attempt EEC registration to the new EES indicated (configured) by the obtained information.

[0055] When the first server responds to a request with a response message containing a failure cause based on selection criteria regarding the operational status of EASs (for example, when the second server is congested or undergoing maintenance), the message may indicate a server-dependent error or condition, specifically an HTTP Status code 503 Service Unavailable. In this case, EEC2 may behave as follows, similar to when it receives a response message containing a failure cause based on selection criteria regarding Application Client profiles. For example, EEC2 may abort the EEC registration. Alternatively, EEC2 may resend the EEC registration request. If the number of resends of the request (e.g., EEC registration request) reaches a predetermined maximum number, for example, EEC2 may abort the EEC registration. Alternatively, EEC2 may send an EEC registration update request. Alternatively, EEC2 may send an EEC de-registration request. Alternatively, EEC2 may inform AC3 of the cause of failure (or error). EEC2 may map the cause of failure (or error) to an AC-specific cause of failure (or error). Alternatively, EEC2 may transparently forward the cause of failure (or error) to AC3. Alternatively, EEC2 may suppress the sending of an EEC registration request or an EEC registration update request based on the cause of failure in the response message. Specifically, EEC2 may suppress the sending of an EEC registration request or an EEC registration update request until it modifies the Application Client profiles or some of the information contained therein.In other words, EEC2 may suppress the submission of EEC registration requests or EEC registration update requests containing the same resources or information as the failed request until it modifies the Application Client profiles or some of the information contained therein. Alternatively, EEC2 may submit an EEC registration request to a different EES than EES5. This different EES may be pre-configured in EEC2 during the service provisioning procedure. The different EES may be selected based on a policy pre-configured in the UE or ME, or based on the AC3 policy. Furthermore, if EEC registration fails for all EES(s) configured in the UE or ME, EEC2 may execute a service provisioning request procedure to ECS7 to obtain new EES(s) information from ECS7, and then attempt EEC registration for the new EES indicated (configured) by the obtained information.

[0056] <Second Embodiment> This embodiment provides a variation of the operation of the first server and request entity described in the first embodiment. An example of the network architecture according to this embodiment is the same as the example described with reference to Figure 1.

[0057] In this embodiment, the first server explicitly or implicitly indicates in the response message that, if a request fails, the requesting entity should backoff before sending the next request. For example, the first server explicitly or implicitly indicates in the response message that, if a request fails because the second server is congested (highly loaded), the requesting entity should backoff before sending the next request. Specifically, the first server may include a failure cause in the response message indicating that the second server is congested. This failure cause implicitly indicates that backoff is required. Furthermore, or alternatively, the first server may include in the response message a value indicating a specific backoff time, a value indicating a maximum backoff time, or a parameter for deriving either of these. The backoff time may be called the backoff period or backoff window.

[0058] A requesting entity can send the next request without backoff if the response message does not indicate that backoff is required. For example, a requesting entity can resend the request message, including the missing information indicated by the cause of failure contained in the received response message.

[0059] Conversely, if the response message explicitly or implicitly indicates that a backoff is required, the requesting entity will perform a backoff before sending the next request. In other words, the requesting entity will delay sending the next request until at least the backoff time has elapsed. The backoff time may be specified by the first server or derived by the requesting entity. The requesting entity may determine a random backoff time, with a maximum backoff time as the upper limit.

[0060] Figure 3 is a flowchart illustrating an example of the operation of the first server according to this embodiment. The first server attempts to identify (discover, select, or determine) a preferred or appropriate edge server located in EDN4. In one example, the first server may be EES5 and may attempt to identify one or more EASs in response to a request from EEC2.

[0061] Steps 301-307 are the same as steps 201-207 in Figure 2. In step 308, the first server (ie.e., EES5) responds to the request with a response message that includes a failure cause indicating congestion. This message explicitly or implicitly indicates that a backoff is required before sending the next request. Specifically, if the request fails because the second server is congested (or under heavy load), the first server may indicate in its response message that a backoff is required. Note that in step 307, if the second server is congested (or under heavy load) but the first server determines that the second server is available, the first server may indicate in its response message that a backoff corresponding to the second server is required.

[0062] Figure 4 is a flowchart illustrating an example of the operation of a request entity according to this embodiment. In the case of selecting (or deciding, discovering, or identifying) an EAS(s), the request entity may be an EEC2.

[0063] In step 401, the requesting entity sends a request to the first server (e.g., EES5). In step 402, the requesting entity receives a response message from the first server.

[0064] If the response message in step 402 does not contain the failure cause (NO in step 403), the procedure proceeds to step 404. In step 404, the requesting entity (e.g., EEC2) notifies the AC that the request was successful. If the response message in step 402 indicates that a backoff is required, the AC is notified that the request was successful and that a backoff is required. The AC, notified that a backoff is required, may, for example, send a signal to the EAS after performing the backoff.

[0065] In contrast, if the response message in step 402 contains the failure cause (YES in step 403), the procedure proceeds to step 405. In step 405, the requesting entity determines whether the response message indicates that a backoff is necessary. If a backoff is not necessary (NO in step 405), the requesting entity can send the next request without performing a backoff (step 406). If a backoff is necessary (YES in step 405), the requesting entity performs a backoff before sending the next request.

[0066] According to the operation of the first server and the requesting entity described above, if a request fails, the first server can delay the requesting entity from sending the next request. In particular, if a request fails due to congestion on the second server, delaying the requesting entity from sending the next request can be expected to alleviate or reduce the congestion on the second server.

[0067] The following provides a concrete example of the implementation of the operation of the first server and request entity described above, with reference to Figure 5. Figure 5 shows an example of the operation of EEC2 and EES5 in the EEC registration procedure based on the Request / Response model. EEC2 in Figure 5 corresponds to the request entity described above, and EES5 in Figure 5 corresponds to the first server described above. In step 501, EEC2 sends an EEC registration request or an EEC registration update request to EES5 as the request described above.

[0068] In step 502, EES5 verifies the Security credentials included in the request (corresponding to step 202 in Figure 2 and step 302 in Figure 3) and attempts to identify at least one EAS that satisfies at least one selection criterion (corresponding to step 204 in Figure 2 and step 304 in Figure 3). At least one selection criterion considers the requirements (AC Profile(s)) included in the request. In addition, at least one selection criterion may consider at least one of the following: EAS congestion status, UE location, and EAS operational status. At least one selection criterion may consider other factors, such as UE-specific service information in EES5 or ECSP policies. If EES5 cannot identify an EAS that satisfies at least one selection criterion, as illustrated with reference to Figure 3 (step 308), it responds to the EEC2 request with a response message containing the failure cause.

[0069] In step 503, EES5 responds to EEC2's request with an EEC registration response or an EEC registration update response. Figure 5 shows a case where EEC2's request fails. Therefore, the response message in step 503 includes the cause of the failure. Furthermore, if EAS is congested (high load), the response message explicitly or implicitly indicates that a backoff is required. If the response message explicitly indicates that a backoff is required, a backoff timer value may also be set in the response message in step 503. In step 504, EEC2 delays sending the next request until at least the backoff time has elapsed.

[0070] Even if the EEC2 request is successful, the EEC registration response or EEC registration update response in step 503 may explicitly or implicitly indicate that a backoff is required. For example, access from EEC2 to EAS may be permitted after a certain backoff operation has taken place, even if EAS is congested. In this case, in step 504, EEC2 delays sending requests to EAS until at least the backoff time has elapsed.

[0071] <Third Embodiment> This embodiment provides another example of the operation of the first server and request entity. The example of the network architecture according to this embodiment is similar to the example described with reference to Figure 1.

[0072] In this embodiment, the first server may distinguish between the response message sent to the requesting entity in EEC registration when the second server is not operational and the response message sent when the second server cannot be found. For example, the failure cause value set in the response message when the second server is not operational may be different from the value set in the response message when the second server cannot be found. This allows the requesting entity to distinguish between the types of response messages (or failure cause types). Furthermore, the requesting entity can perform different actions depending on the type of response message (or failure cause type).

[0073] If the requesting entity is EEC2 and receives a response message containing a failure cause based on selection criteria regarding the operational status of EASs during EEC registration, the requesting entity (EEC2) may act as follows: If the message is due to the fact that the second server (i.e., EAS) is not operational, EEC2 aborts the EEC registration without resending the EEC registration request or EEC registration update request. On the other hand, if the message is due to the fact that the second server (i.e., EAS) cannot be found, EEC2 resends the EEC registration request or EEC registration update request.

[0074] <Fourth Embodiment> This embodiment provides a variation of the operation of the first server and request entity described in the first embodiment. An example of the network architecture according to this embodiment is the same as the example described with reference to Figure 1.

[0075] In this embodiment, the requesting entity may be EEC2, and the first server may be EES5. If the requesting entity (i.e., EEC2) fails to register an EEC, it may send an EEC registration request to a different EES than the first server (i.e., EES5). This different EES may be pre-configured in the UE or ME during the service provisioning procedure. Furthermore, this different EES may be selected based on a policy pre-configured in the UE or ME, or based on the AC3 policy.

[0076] Furthermore, if EEC registration fails for all EES(s) configured in the UE or ME, EEC2 may perform a service provisioning procedure on ECS7 to obtain new EES(s) information from ECS7 and attempt to register the new EES(s) indicated (configured) by the obtained information.

[0077] Figure 6 is a flowchart illustrating an example of the operation of a requesting entity (i.e., EEC2) according to this embodiment. The requesting entity sends an EEC registration request to a first server. The first server attempts to identify (discover, select, or determine) a preferred or appropriate edge server located in the EDN4. In one example, the first server may be an EES5, which may attempt to identify one or more EASs in response to a request from EEC2.

[0078] Steps 601-604 are the same as steps 401-404 in Figure 4. If the response message in step 602 includes the failure cause (YES in step 603), the procedure proceeds to step 605. If there are any EESs among those configured in UE or ME that have not yet attempted EEC registration (NO in step 605), EEC2 selects a different EES from the first server (step 606), returns to step 601, and attempts EEC registration with that different EES.

[0079] In contrast, if EEC registration fails for all EESs configured in UE or ME (YES in step 605), EEC2 performs a service provisioning procedure on ECS7 to obtain new EES(s) information from ECS7 (step 607). Then, EEC2 returns to step 601 and attempts to register the new EESs indicated (configured) by the newly obtained information.

[0080] The following provides specific examples of the implementation of the operation of the first server and request entity described above, with reference to Figures 7 and 8. Figure 7 shows an example of the operation of EEC2 and EES5 in the EEC registration procedure based on the Request / Response model. EEC2 in Figure 5 corresponds to the request entity described above, and EES5 in Figure 5 corresponds to the first server described above.

[0081] Steps 701 and 702 are the same as steps 501 and 502 in Figure 4. In step 703, EES5 responds to EEC2's request with an EEC registration response or an EEC registration update response. Figure 7 shows a case where EEC2's request fails. Therefore, the response message in step 703 includes the cause of the failure. In step 704, if EEC registration fails for all EESs configured in the UE or ME, EEC2 obtains new EES(s) information from ECS7 by performing a service provisioning procedure for ECS7 (not shown). In step 705, EEC2 attempts EEC registration by sending an EEC registration request to the new EES51 indicated (configured) by the new EES(s) information obtained in step 704.

[0082] Figure 8 corresponds to step 704 in Figure 7 and shows an example of the operation of EEC2 and ECS7 in a service provisioning procedure based on the Request / Response model. In step 801, EEC2 sends a service provisioning request to ECS7. In step 802, ECS7 attempts to identify at least one EES that satisfies at least one selection criterion. At least one selection criterion considers the congestion status of the EES. In addition, at least one selection criterion may consider one or both of the UE location and at least one Application Client profile provided by EEC2 via the request in step 501. At least one selection criterion may consider other factors, such as UE-specific service information in ECS7 or ECSP policies.

[0083] In step 803, ECS7 responds to the EEC2 request with a service provisioning response. This response message may include EDN configuration information, which may include information indicating a different EES (e.g., EES51) from EES5.

[0084] EDN configuration information may include information that indicates multiple items. Each item indicates one or more sets of characteristics. For example, EDN configuration information may include "EDN connection information" and "List of EESs," and further include "Lifetime." EDN connection information indicates the information required for EDN connection. This information includes the DNN or Access Point Name (APN), and further includes at least one of S-NSSAI or EDN Topological Service Area. List of EESs indicates the EES list for the EDN. The EES list includes the EES ID and EES Endpoint, and further includes at least one of EASIDs, ECSP info, EES Topological Service Area, EES Geographical Service Area, or List of EES DNAI(s). Lifetime indicates the validity period of the EDN configuration information.

[0085] Next, configuration examples of UE1, EES5, EAS6, ECS7, and EES51 according to the above-described embodiments will be explained. Figure 9 is a block diagram showing a configuration example of UE1. The Radio Frequency (RF) transceiver 901 performs analog RF signal processing to communicate with the RAN node. The RF transceiver 901 may include multiple transceivers. The analog RF signal processing performed by the RF transceiver 901 includes frequency up-conversion, frequency down-conversion, and amplification. The RF transceiver 901 is coupled with the antenna array 902 and the baseband processor 903. The RF transceiver 901 receives modulation symbol data (or OFDM symbol data) from the baseband processor 903, generates a transmit RF signal, and supplies the transmit RF signal to the antenna array 902. The RF transceiver 901 also generates a baseband receive signal based on the received RF signal received by the antenna array 902 and supplies it to the baseband processor 903. The RF transceiver 901 may include an analog beamformer circuit for beamforming. The analog beamformer circuit includes, for example, multiple phase shifters and multiple power amplifiers.

[0086] The baseband processor 903 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) generation / decomposition of transmission format (transmission frame), (d) transmission path coding / decoding, (e) modulation (symbol mapping) / demodulation, and (f) generation of OFDM symbol data (baseband OFDM signal) by Inverse Fast Fourier Transform (IFFT). Control plane processing, on the other hand, includes communication management at 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 attach, mobility, and call management).

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

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

[0089] The baseband processor 903 may include a modem processor (e.g., Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., Central Processing Unit (CPU) or 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 904 described later.

[0090] The application processor 904 is also called a CPU, MPU, microprocessor, or processor core. The application processor 904 may include multiple processors (multiple processor cores). The application processor 904 implements various functions of the UE1 by executing system software programs (Operating System (OS)) and various application programs (e.g., calling applications, web browsers, mail clients, camera operation applications, music playback applications) read from memory 906 or memory not shown.

[0091] In some implementations, the baseband processor 903 and the application processor 904 may be integrated on a single chip, as shown by the dashed line (905) in Figure 9. In other words, the baseband processor 903 and the application processor 904 may be implemented as a single System on Chip (SoC) device 905. An SoC device is sometimes called a System Large Scale Integration (LSI) or chipset.

[0092] Memory 906 is volatile memory, non-volatile memory, or a combination thereof. Memory 906 may include multiple physically independent memory devices. Volatile memory is, for example, Static Random Access Memory (SRAM) or Dynamic RAM (DRAM), or a combination thereof. Non-volatile memory is Mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or hard disk drive, or any combination thereof. For example, memory 906 may include an external memory device accessible from the baseband processor 903, the application processor 904, and the SoC 905. Memory 906 may also include an internal memory device integrated within the baseband processor 903, the application processor 904, or the SoC 905. Furthermore, memory 906 may include memory within a Universal Integrated Circuit Card (UICC).

[0093] The memory 906 may store one or more software modules (computer programs) 907 containing instruction sets and data for performing the processing by the UE1 as described in the above-described embodiments. In some implementations, the baseband processor 903 or application processor 904 may be configured to read and execute the software modules 907 from the memory 906 to perform the processing of the UE1 as described with reference to the drawings in the above embodiments.

[0094] Furthermore, the control plane processing and operation performed by the UE1 described in the above embodiment can be realized by other elements other than the RF transceiver 901 and antenna array 902, namely at least one of the baseband processor 903 and application processor 904 and the memory 906 storing the software module 907.

[0095] Figure 10 shows an example configuration of EES5. EAS6, ECS7, and EES51 may also have a similar configuration to that shown in Figure 10. Referring to Figure 10, EES5 (or EAS6, or ECS7) includes a network interface 1001, a processor 1002, and memory 1003. The network interface 1001 is used, for example, to communicate with other network functions (NFs) or nodes. The network interface 1001 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

[0096] The processor 1002 may be, for example, a microprocessor, a Micro Processing Unit (MPU), or a Central Processing Unit (CPU). The processor 1002 may include multiple processors.

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

[0098] The memory 1003 may store one or more software modules (computer programs) 1004 containing instruction sets and data for performing processing by EES5 (or EAS6, or ECS7) as described in the above embodiments. In some implementations, the processor 1002 may be configured to read the software modules 1004 from the memory 1003 and execute them to perform the processing of EES5 (or EAS6, or ECS7) as described in the above embodiments.

[0099] As illustrated with Figures 9 and 10, each of the processors in the UE1, EES5, EAS6, and ECS7 according to the above embodiment executes one or more programs containing a set of instructions for causing a computer to perform the algorithm described with reference to the drawings. This program can be stored and supplied to the computer using various types of non-transitory computer-readable medium. Non-transitory computer-readable mediums include various types of tangible storage mediums. Examples of non-transitory computer-readable mediums include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), Compact Disc Read Only Memory (CD-ROM), CD-R, CD-R / W, and semiconductor memory (e.g., mask ROM, programmable ROM (PROM), erasable PROM (EPROM), flash ROM, and random access memory (RAM)). The program may also be supplied to the computer using various types of transient computer-readable medium. Examples of temporary computer-readable media include electrical signals, optical signals, and electromagnetic waves. Temporary computer-readable media can supply programs to a computer via wired communication channels such as electric wires and optical fibers, or via wireless communication channels.

[0100] In this specification, a User Equipment (UE) is an entity connected to a network via a wireless interface. A User Equipment (UE) in this specification is not limited to a dedicated communication device, but may be any device having the communication capabilities of a User Equipment (UE) as described herein, such as the following:

[0101] The terms "User Equipment (UE)," "mobile station," "mobile terminal," "mobile device," and "wireless device" (as used in 3GPP) are generally intended to be synonymous with each other. A UE may be a standalone mobile station such as a terminal, mobile phone, smartphone, tablet, cellular IoT terminal, or IoT device. The terms "UE" and "wireless device" also encompass devices that remain stationary for extended periods.

[0102] UE may include, for example, production equipment, manufacturing equipment and / or energy-related machinery (such as boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal power generators, nuclear power generators, batteries, nuclear systems, nuclear-related equipment, heavy electrical equipment, pumps including vacuum pumps, compressors, fans, blowers, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots, robotic application systems, tools, molds, rolls, conveying equipment, lifting equipment, cargo handling equipment, textile machinery, sewing machinery, printing presses, printing-related machinery, paper processing machinery, chemical machinery, mining machinery, mining-related machinery, construction machinery, construction-related machinery, agricultural machinery and / or equipment, forestry machinery and / or equipment, fishing machinery and / or equipment, safety and / or environmental protection equipment, tractors, bearings, precision bearings, chains, gears, power transmissions, lubrication systems, valves, pipe fittings and / or application systems of any of the above-mentioned equipment or machinery).

[0103] UE may be, for example, a transport device (such as a vehicle, automobile, motorcycle, bicycle, train, bus, handcart, rickshaw, ship and other watercraft, airplane, rocket, satellite, drone, balloon, etc.).

[0104] The UE may be, for example, information and communication equipment (such as computers and related devices, communication equipment and related devices, electronic components, etc.).

[0105] UE may include, for example, refrigerators, refrigerator applications and equipment, commercial and service equipment, vending machines, automated service machines, office machinery and equipment, and consumer electrical and electronic machinery and appliances (such as audio equipment, speakers, radios, video equipment, televisions, microwave ovens, rice cookers, coffee makers, dishwashers, washing machines, dryers, fans, ventilation fans and related products, vacuum cleaners, etc.).

[0106] The UE may be, for example, an electronic application system or electronic application device (such as an X-ray device, particle accelerator, radioactive material application device, sound wave application device, electromagnetic application device, power application device, etc.).

[0107] UE may include, for example, light bulbs, lighting, weighing machines, analytical instruments, testing machines and measuring instruments (such as smoke detectors, human alarm sensors, motion sensors, and wireless tags), watches or clocks, scientific and chemical instruments, optical instruments, medical equipment and / or medical systems, weapons, tools and implements, or hand tools.

[0108] The UE may be, for example, a personal digital assistant or device with wireless communication capabilities (for example, an electronic device configured to have a wireless card or wireless module attached or inserted into it, such as a personal computer or electronic measuring instrument).

[0109] An UE (Unified User) may be a device or part of a device that provides the following applications, services, and solutions in the Internet of Things (IoT), for example, using wired or wireless communication technologies: An IoT device (or thing) comprises appropriate electronics, software, sensors, network connectivity, etc., that enable the device to collect and exchange data with each other and with other communication devices. An IoT device may be an automated device that follows software instructions stored in internal memory. An IoT device may operate without requiring human supervision or response. An IoT device may be a device that is installed for a long period of time and / or may remain in an inactive state for a long period of time. An IoT device may be implemented as part of a stationary device. An IoT device may be embedded in a non-stationary device (e.g., a vehicle) or attached to an animal or person that is being monitored / tracked. IoT technology may be implemented on any communication device that can be connected to a communication network that sends and receives data regardless of human input control or software instructions stored in memory. IoT devices are sometimes also called Machine Type Communication (MTC) devices, Machine to Machine (M2M) communication devices, or Narrow Band-IoT (NB-IoT) UEs.

[0110] The UE may support one or more IoT or MTC applications.

[0111] Some examples of MTC applications are listed in 3GPP TS22.368 V13.2.0 (2017-01-13) Annex B (the contents of which are incorporated herein by reference). This list is not exhaustive and represents only examples of MTC applications. In this list, the service area of ​​an MTC application includes Security, Tracking & Tracing, Payment, Health, Remote Maintenance / Control, Metering, and Consumer Devices.

[0112] Examples of MTC applications related to security include surveillance systems, landline backup, control of physical access (e.g., to buildings), and car / driver security.

[0113] Examples of MTC applications related to tracking and tracing include fleet management, order management, telematics insurance: pay as you drive (PAYD), asset tracking, navigation, traffic information, road tolling, and road traffic optimization / steering.

[0114] Examples of MTC applications related to payments include point of sales (POS), vending machines, and gaming machines.

[0115] Examples of health-related MTC applications include monitoring vital signs, supporting the aged or handicapped, web-access telemedicine points, and remote diagnostics.

[0116] Examples of MTC applications related to remote maintenance / control include sensors, lighting, pumps, valves, elevator control, vending machine control, and vehicle diagnostics.

[0117] Examples of MTC applications related to metering include power, gas, water, heating, grid control, and industrial metering.

[0118] Examples of MTC applications for consumer electronics include digital photo frames, digital cameras, and ebooks.

[0119] Applications, services, and solutions include, by way of example, MVNO (Mobile Virtual Network Operator) services / systems, disaster prevention wireless services / systems, in-building wireless telephone (PBX (Private Branch eXchange)) services / systems, PHS / digital cordless telephone services / systems, Point of sales (POS) systems, advertising transmission services / systems, multicast (Multimedia Broadcast and Multicast Service (MBMS)) services / systems, V2X (Vehicle to Everything: vehicle-to-vehicle communication and roadside-to-vehicle / pedestrian-to-vehicle communication) services / systems, in-train mobile wireless services / systems, location information-related services / systems, disaster / emergency wireless communication services / systems, IoT (Internet of Things) services / systems, community services / systems, video distribution services / systems, Femto cell application services / systems, VoLTE (Voice over LTE) services / systems, wireless tag services / systems, charging services / systems, radio on-demand services / systems, roaming services / systems, user behavior monitoring services / systems, communication carrier / communication NW selection services / systems, function-limited services / systems, PoC (Proof of Concept) services / systems, personal information management services / systems for terminals, display / video services / systems for terminals, non-communication services / systems for terminals, ad hoc NW / DTN (Delay Tolerant Networking) services / systems, and the like.

[0120] The categories of UEs described above are merely application examples of the technical ideas and embodiments described in this specification. The UEs in this specification are not limited to these examples, and those skilled in the art can make various changes to them.

[0121] Furthermore, the embodiments described above are merely examples of how the technical concept obtained by the present inventor can be applied. In other words, the technical concept is not limited to the embodiments described above, and various modifications are certainly possible.

[0122] For example, some or all of the above embodiments may also be described as follows, but are not limited to the following.

[0123] (Note 1) memory, and The memory is coupled to and A request is received from the requesting entity to generate an Edge Enabler Client (EEC) Context, which is information about the requesting entity, and includes security credentials and at least one Application Client Profile. By verifying the aforementioned security credentials, it is determined whether or not access to the edge data network can be permitted. If access to the edge data network can be permitted, an attempt is made to identify a second server located within the edge data network based on at least one selection criterion. If the second server is identified, a first response message containing information indicating that the request was successful is sent to the requesting entity. A processor configured to include at least one processor, Equipped with, The aforementioned at least one selection criterion includes the requirements set forth in the aforementioned at least one Application Client Profile, The at least one processor is configured to send a second response message to the requesting entity, which includes a failure cause indicating that the second server cannot be identified, if access to the edge data network is not permitted or if the requirements specified in the at least one Application Client Profile are not met. The first server. (Note 2) The second response message causes the requesting entity to perform at least one of the following actions: cancel the request, suppress the transmission of the request, resend the request, or notify the application. The first server mentioned in Appendix 1. (Note 3) The first server mentioned above is the Edge Enabler Server (EES), The second server mentioned above is the Edge Application Server (EAS), The aforementioned request entity is an Edge Enabler Client (EEC) located on User Equipment (UE). The first server as described in Appendix 1 or 2. (Note 4) The first server as described in any one of Annexes 1 to 3, wherein at least one of the first response message and the second response message includes information indicating that the requesting entity should perform a backoff before sending the next request. (Note 5) At least one of the first response message and the second response message includes information for identifying a specific backoff time or a maximum backoff time for the backoff, The first server mentioned in Appendix 4. (Note 6) The information indicating that a backoff should be performed includes information for identifying a specific backoff time or maximum backoff time, and at least one of the causes of failure. The first server as described in Appendix 4 or 5. (Note 7) A request is received from the requesting entity to generate an Edge Enabler Client (EEC) Context, which is information about the requesting entity, and includes security credentials and at least one Application Client Profile. By verifying the aforementioned security credentials, it is determined whether or not access to the edge data network can be permitted. If access to the edge data network can be permitted, an attempt is made to identify a second server located within the edge data network based on at least one selection criterion. If the second server is identified, the requesting entity is sent a first response message containing information indicating that the request was successful, The aforementioned at least one selection criterion includes the requirements set forth in the aforementioned at least one Application Client Profile, If access to the edge data network is not permitted, or if the requirements specified in at least one Application Client Profile are not met, further comprising sending a second response message to the requesting entity, which includes a cause of failure that indicates the second server cannot be identified, A method performed by the first server. (Note 8) A program for causing a computer to perform a method for a first server, The aforementioned method, A request is received from the requesting entity to generate an Edge Enabler Client (EEC) Context, which is information about the requesting entity, and includes security credentials and at least one Application Client Profile. By verifying the aforementioned security credentials, it is determined whether or not access to the edge data network can be permitted. If access to the edge data network can be permitted, an attempt is made to identify a second server located within the edge data network based on at least one selection criterion. If the second server is identified, the requesting entity is sent a first response message containing information indicating that the request was successful, The aforementioned at least one selection criterion includes the requirements set forth in the aforementioned at least one Application Client Profile, The method further includes, if access to the edge data network is not permitted, or if the requirements specified in at least one Application Client Profile are not met, sending a second response message to the requesting entity containing a cause of failure, which is information indicating that the second server cannot be identified. program. (Note 9) A requesting entity, memory, and The memory is coupled to and A request is sent to the first server to generate an Edge Enabler Client (EEC) Context which includes security credentials and at least one Application Client Profile, and is information about the request entity. The response message for the aforementioned request is received from the first server. If the response message contains a failure cause which is information indicating that the second server cannot be identified, the request is sent to a first server different from the first server. A processor configured to include at least one processor, Equipped with, The aforementioned failure cause is the request entity included in the response message when access to the edge data network cannot be permitted or when the requirements specified in at least one Application Client Profile are not met. (Note 10) The first server mentioned above is the Edge Enabler Server (EES), The second server mentioned above is the Edge Application Server (EAS), The aforementioned request entity is an Edge Enabler Client (EEC) located on User Equipment (UE). The requesting entity as described in Appendix 9. (Note 11) A method performed by the requesting entity, A request is sent to the first server to generate an Edge Enabler Client (EEC) Context which includes security credentials and at least one Application Client Profile, and is information about the request entity. The response message for the aforementioned request is received from the first server. If the response message includes a cause of failure which is information indicating that the second server cannot be identified, the request is sent to a first server different from the first server. The failure cause is included in the response message when access to the edge data network is not permitted or when the requirements specified in at least one Application Client Profile are not met. (Note 12) A program for causing a computer to perform a method for a requesting entity, The aforementioned method, A request is sent to the first server to generate an Edge Enabler Client (EEC) Context which includes security credentials and at least one Application Client Profile, and is information about the request entity. The response message for the aforementioned request is received from the first server. If the response message includes a cause of failure which is information indicating that the second server cannot be identified, the request is sent to a first server different from the first server. The failure cause is the program included in the response message when access to the edge data network is not permitted or when the requirements specified in at least one Application Client Profile are not met.

[0124] This application claims priority based on Japanese Patent Application No. 2021-079697, filed on 10 May 2021, and incorporates all of its disclosures herein. [Explanation of Symbols]

[0125] 1. User Equipment (UE) 2 Edge Enabler Client (EEC) 3. Application client (AC) 4. Edge Data Network (EDN) 5. Edge Enabler Server (EES) 51 Edge Enabler Server (EES) 6 Edge Application Server (EAS) 7 Edge Configuration Server (ECS) 903 Baseband Processor 904 Application Processor 906 memory 907 module 1002 Processor 1003 memory 1004 Module

Claims

1. Receiving a message from Edge Enabler Client (EEC), Attempts to identify a matching Edge Application Server (EAS), If no matching EAS is identified, the message is rejected by sending a response to the EEC with a status code of 404 Not Found. How to use Edge Enabler Server (EES).

2. Receiving a message from the Edge Enabler Client (EEC), Attempts to identify a matching Edge Application Server (EAS), If no matching EAS is identified, the message is rejected by sending a response to the EEC with a status code of 404 Not Found. A processor configured to execute instructions for, Edge Enabler Server (EES).

3. The matching EAS satisfies all the information included in the minimum required service Key Performance Indicator (KPI), The EES according to claim 2.

4. The response includes a cause indicating an application error in the status code, The EES according to claim 2.

5. The application error is RESOURCE_NOT_FOUND, The EES according to claim 4.

6. Send a message to the Edge Enabler Server (EES) that prompts the EES to attempt to identify a matching Edge Application Server (EAS), If no matching EAS is identified, the EAS receives a response with a status code of 404 Not Found. How to use Edge Enabler Client (EEC).

7. A transceiver that sends a message to an Edge Enabler Server (EES) causing the EES to attempt to identify a matching Edge Application Server (EAS), If the transceiver does not identify a matching EAS, it receives a response from the EAS with a status code of 404 Not Found. Edge Enabler Client (EEC).

8. The matching EAS satisfies all the information included in the minimum required service Key Performance Indicator (KPI). The EEC as described in claim 7.

9. The response includes a cause indicating an application error in the status code, The EEC as described in claim 7.

10. The application error is RESOURCE_NOT_FOUND. The EEC as described in claim 9.

Images