Apparatus for edge enabler client

Abstract

An apparatus and system for implementing security procedures for edge devices are described. Authentication and authorization are performed for the onboarding of edge configuration servers, edge enabler servers, and edge application servers. Security procedures for EDGE-1 and EDGE-4 reference points are also described, which use a security method selected by the edge enabler client and negotiated with the edge configuration server. The security method is TLS-PSK based, certificate based mutual authentication, or access token based.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 061,068, filed August 4, 2020; U.S. Provisional Patent Application No. 63 / 061,071, filed August 4, 2020; U.S. Provisional Patent Application No. 63 / 061,095, filed August 4, 2020; and U.S. Provisional Patent Application No. 63 / 061,096, filed August 4, 2020, which are incorporated herein by reference in their entirety. Technical Field

[0003] The embodiments relate to fifth-generation (5G) wireless communication. Specifically, some embodiments relate to edge computing in 5G networks. Background Technology

[0004] The use and complexity of wireless systems (including 4G and 5G networks, etc.) have increased due to the increased types of user equipment (UEs) using network resources and the increased data volume and bandwidth used by various applications operating on these UEs (e.g., video streaming). With the massive increase in the number and diversity of communication devices, the corresponding network environment (including routers, switches, bridges, gateways, firewalls, and load balancers) has become increasingly complex, especially with the emergence of next-generation (NG) (or new radio (NR)) systems. Unsurprisingly, the emergence of any new technology brings many challenges. Attached Figure Description

[0005] In accompanying drawings that are not necessarily drawn to scale, similar reference numerals may describe similar components in different views. Similar reference numerals with different letter suffixes may indicate different instances of similar components. The accompanying drawings illustrate, by way of example and not limitation, the various embodiments discussed in this document.

[0006] Figure 1A The architecture of the network is shown based on some aspects.

[0007] Figure 1B The non-roaming 5G system architecture is shown based on some aspects.

[0008] Figure 1C The non-roaming 5G system architecture is shown based on some aspects.

[0009] Figure 2 A block diagram of a communication device according to some embodiments is shown.

[0010] Figure 3 An architecture for enabling edge applications is shown according to some embodiments.

[0011] Figure 4 A secure process for onboarding an edge enabler client is illustrated according to some embodiments.

[0012] Figure 5 The selection of security methods used at the EDGE-1 reference point is shown according to some embodiments.

[0013] Figure 6 The EDGE-1 interface authentication and protection using Transport Layer Security Pre-Shared Key Cryptography Suite (TLS-PSK) is illustrated according to some embodiments.

[0014] Figure 7 The following illustrates EDGE-1 interface authentication and protection using certificate-based mutual authentication according to some embodiments.

[0015] Figure 8 The use of access tokens for EDGE-1 interface authentication and protection is illustrated according to some embodiments.

[0016] Figure 9 A secure process for loading an edge application server is illustrated according to some embodiments. Detailed Implementation

[0017] The following description and accompanying drawings fully illustrate specific embodiments to enable those skilled in the art to implement them. Other embodiments may include structural, logical, electrical, procedural, and other variations. Parts and features of some embodiments may be included in, or replace, parts and features of other embodiments. The embodiments set forth in the claims include all available equivalents of these claims.

[0018] Figure 1A The network architecture is illustrated based on several aspects. Network 140A includes 3GPP LTE / 4G and NG network functions, which can be extended to 6G capabilities. Therefore, while 5G will be mentioned, it should be understood that this can be extended to 6G architecture, systems, and functions. Network functions can be implemented as discrete network elements on dedicated hardware, software instances running on dedicated hardware, and / or virtualized functions instantiated on appropriate platforms (e.g., dedicated hardware or cloud infrastructure).

[0019] Network 140A is shown as including user equipment (UE) 101 and UE 102. UE 101 and 102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a portable (laptop) or desktop computer, a wireless phone, a drone, or any other computing device including wired and / or wireless communication interfaces. UE 101 and 102 may be collectively referred to herein as UE 101, and UE 101 may be used to perform one or more of the techniques disclosed herein.

[0020] Any radio link described herein (e.g., used in Network 140A or any other illustrated network) may operate according to any exemplary radio communication technology and / or standard. Any spectrum management scheme, including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (e.g., Licensed Shared Access (LSA) in 2.3–2.4 GHz, 3.4–3.6 GHz, 3.6–3.8 GHz and other frequencies, and Spectrum Access System (SAS) in 3.55–3.7 GHz and other frequencies). Different single-carrier or orthogonal frequency domain multiplexing (OFDM) modes (CP-OFDM, SC-FDMA, SC-OFDM, Filter Bank-Based Multicarrier (FBMC), OFDMA, etc.) (especially 3GPP NR) can be used by allocating OFDM carrier data bit vectors to appropriate symbol resources.

[0021] In some aspects, either UE 101 or 102 may include an Internet of Things (IoT) UE or a Cellular IoT (CIoT) UE, which may include a network access layer designed for low-power IoT applications utilizing short-lived UE connectivity. In some aspects, either UE 101 or 102 may include a narrowband (NB) IoT UE (e.g., an enhanced NB-IoT (eNB-IoT) UE and a further enhanced (FeNB-IoT) UE). The IoT UE may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with an MTC server or device via a Public Land Mobile Network (PLMN), Proximity-Based Service (ProSe) or Device-to-Device (D2D) communication, sensor networks, or IoT networks. M2M or MTC data exchange may be machine-initiated. The IoT network includes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connectivity. The IoT UE may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network. In some respects, either UE 101 or 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0022] UEs 101 and 102 can be configured to connect (e.g., communicatively coupled) to a radio access network (RAN) 110. RAN 110 can be, for example, an evolved universal mobile communications system (UMTS) terrestrial radio access network (E-UTRAN), a next-generation RAN (NG RAN), or other types of RAN.

[0023] UEs 101 and 102 utilize connections 103 and 104 respectively, each connection including a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are shown as air interfaces enabling communication coupling and can conform to cellular communication protocols such as Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, PTT protocol, PTT on Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, 5G protocol, 6G protocol, etc.

[0024] In one aspect, UEs 101 and 102 can further exchange communication data directly through the ProSe interface 105. The ProSe interface 105 may also be referred to as a sidelink (SL) interface, which includes one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), Physical Sidelink Broadcast Channel (PSBCH), and Physical Sidelink Feedback Channel (PSFCH).

[0025] UE 102 is shown configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, according to which AP 106 may include a Wi-Fi® router. In this example, AP 106 is shown connected to the Internet but not to the core network of the wireless system (described in further detail below).

[0026] RAN 110 may include one or more access nodes that enable connections to 103 and 104. These access nodes (ANs) may be referred to as base stations (BS), NodeBs, evolved NodeBs (eNBs), next-generation NodeBs (gNBs), RAN nodes, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). In some aspects, communication nodes 111 and 112 may be transmit / receive points (TRPs). In the case that communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may function within the communication cell of the NodeB. RAN 110 may include one or more RAN nodes (e.g., macro RAN node 111) for providing macro cells, and one or more RAN nodes (e.g., low-power (LP) RAN node 112) for providing femtocells or picocells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells).

[0027] Either RAN node 111 or 112 can terminate the air interface protocol and can be the first contact point for UEs 101 and 102. In some aspects, either RAN node 111 or 112 can implement various logical functions of RAN 110, including but not limited to Radio Network Controller (RNC) functions, such as radio bearer management, uplink and downlink dynamic radio resource management and packet scheduling, and mobility management. In the example, either node 111 or 112 can be a gNB, eNB, or other type of RAN node.

[0028] RAN 110 is shown as communicatively coupled to core network (CN) 120 via S1 interface 113. In various aspects, CN 120 may be an evolved packet core (EPC) network, a next-generation packet core (NPC) network, or some other type of CN (e.g., see reference 113). Figures 1B to 1C (As shown). In this aspect, the S1 interface 113 is divided into two parts: the S1-U interface 114, which carries traffic data between RAN nodes 111 and 112 and the serving gateway (S-GW) 122; and the S1 mobility management entity (MME) interface 115, which is the signaling interface between RAN nodes 111 and 112 and the MME 121.

[0029] In this respect, CN 120 includes MME 121, S-GW 122, Packet Data Network (PDN) Gateway (P-GW) 123, and Home Subscriber Server (HSS) 124. MME 121 can functionally resemble the control plane of a traditional Serving General Packet Radio Service (GPRS) Support Node (SGSN). MME 121 can manage mobility aspects of access, such as gateway selection and tracking area list management. HSS 124 can include a database of network users, including subscription-related information used to support network entities in handling communication sessions. CN 120 can include one or more HSS 124s, depending on the number of mobile subscribers, equipment capacity, network organization, etc. For example, HSS 124 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.

[0030] The S-GW 122 can terminate the S1 interface 113 toward RAN 110 and route data packets between RAN 110 and CN 120. Furthermore, the S-GW 122 can serve as a local mobility anchor for inter-RAN node handover and can also provide an anchor for inter-3GPP mobility. Other responsibilities of the S-GW 122 may include lawful interception, charging, and some policy enforcement.

[0031] P-GW 123 can terminate an SGi interface toward the PDN. P-GW 123 can route data packets between EPC network 120 and external networks (e.g., networks including application server 184 (or application function (AF))) via Internet Protocol (IP) interface 125. P-GW 123 can also transmit data to other external networks 131A, which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks. Generally, application server 184 can be an element that provides IP bearer resources for use with the core network (e.g., UMTS Packet Service (PS) domain, LTE PS Data Service, etc.). In this aspect, P-GW 123 is shown communicatively coupled to application server 184 via IP interface 125. Application server 184 can also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UEs 101 and 102 via CN 120.

[0032] P-GW 123 can also be a node for policy enforcement and charging data collection. The Policy and Charging Rule Function (PCRF) 126 is the policy and charging control element of CN 120. In non-roaming scenarios, in some aspects, a single PCRF may exist in the home public land mobile network (HPLMN) associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In roaming scenarios with local traffic disruptions, two PCRFs may exist associated with the UE's IP-CAN session: the home PCRF (H-PCRF) within the HPLMN and the visited PCRF (V-PCRF) within the visited public land mobile network (VPLMN). PCRF 126 can be communicatively coupled to application server 184 via P-GW 123.

[0033] In some aspects, the communication network 140A can be an IoT network or a 5G or 6G network, including 5G new radio networks using licensed (5G NR) and unlicensed (5G NR-U) spectrum for communication. Currently, one IoT implementation is narrowband IoT (NB-IoT). Operation in the unlicensed spectrum can include dual connectivity (DC) operation and a standalone LTE system in the unlicensed spectrum, under which LTE-based technologies operate only in the unlicensed spectrum without using the "anchor" in the licensed spectrum, called MulteFire. In future versions and 5G systems, it is expected that the operation of the LTE system in both licensed and unlicensed spectrum will be further enhanced. This enhanced operation can include technologies for sidelink resource allocation and UE processing behavior for NR sidelink V2X communication.

[0034] The NG system architecture (or 6G system architecture) may include RAN 110 and 5G network core (5GC) 120. NG-RAN 110 may include multiple nodes, such as gNBs and NG-eNBs. The core network 120 (e.g., 5G core network / 5GC) may include Access and Mobility Functions (AMF) and / or User Plane Functions (UPF). The AMF and UPF can be communicatively coupled to the gNB and NG-eNB via NG interfaces. More specifically, in some aspects, the gNB and NG-eNB can connect to the AMF via an NG-C interface and to the UPF via an NG-U interface. The gNB and NG-eNB can be coupled to each other via an Xn interface.

[0035] In some aspects, the NG system architecture can use reference points across various nodes. In some aspects, each gNB and NG-eNB can be implemented as a base station, mobile edge server, small cell, home eNB, etc. In some aspects, in the 5G architecture, the gNB can be the master node (MN), and the NG-eNB can be the slave node (SN).

[0036] Figure 1B The non-roaming 5G system architecture is illustrated based on several aspects. Specifically, Figure 1B The 5G system architecture 140B, shown as a reference point, can be extended to a 6G system architecture. More specifically, UE 102 can communicate with RAN 110 and one or more other 5GC network entities. The 5G system architecture 140B includes multiple network functions (NFs), such as AMF 132, Session Management Function (SMF) 136, Policy Control Function (PCF) 148, Application Function (AF) 150, UPF 134, Network Slice Selection Function (NSSF) 142, Authentication Server Function (AUSF) 144, and Unified Data Management (UDM) / Household Subscriber Server (HSS) 146.

[0037] UPF 134 can provide connectivity to the data network (DN) 152, which may include, for example, carrier services, internet access, or third-party services. AMF 132 can be used to manage access control and mobility, and may also include network slicing selection functionality. AMF 132 can provide UE-based authentication, authorization, mobility management, etc., and can be independent of the access technology. SMF 136 can be configured to set up and manage various sessions according to network policies. Therefore, SMF 136 can be responsible for session management and IP address allocation to the UE. SMF 136 can also select and control UPF 134 for data transmission. SMF 136 can be associated with a single session of UE 101 or multiple sessions of UE 101. That is, UE 101 can have multiple 5G sessions. Different SMFs can be assigned to each session. Using different SMFs allows for individual management of each session. Therefore, the functionality of each session can be independent of each other.

[0038] UPF 134 can be deployed in one or more configurations based on the desired service type and can connect to a data network. PCF 148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in 4G communication systems). UDM can be configured to store subscriber profiles and data (similar to HSS in 4G communication systems).

[0039] AF 150 can provide information about packet flows to PCF 148, which is responsible for policy control, to support desired QoS. PCF 148 can set mobility and session management policies for UE 101. For this purpose, PCF 148 can use packet flow information to determine appropriate policies for the proper operation of AMF 132 and SMF 136. AUSF 144 can store data used for UE authentication.

[0040] In some aspects, the 5G system architecture 140B includes an IP Multimedia Subsystem (IMS) 168B and multiple IP Multimedia Core Network Subsystem entities, such as the Call Session Control Function (CSCF). More specifically, the IMS 168B includes a CSCF, which can function as a proxy CSCF (P-CSCF) 162B, a serving CSCF (S-CSCF) 164B, and an emergency CSCF (E-CSCF) (in... Figure 1B(Not shown in the image), or query the CSCF (I-CSCF) 166B. The P-CSCF 162B can be configured as the first contact point for UE 102 within the IM subsystem (IMS) 168B. The S-CSCF 164B can be configured to handle session states in the network, and the E-CSCF can be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF 166B can be configured to act as the contact point for all IMS connections within the operator's network, where the destination of these IMS connections is a subscriber of that network operator or a roaming user currently within that network operator's service area. In some aspects, the I-CSCF 166B can connect to another IP multimedia network 170E, for example, an IMS operated by a different network operator.

[0041] In some respects, the UDM / HSS 146 can be coupled to an application server 160E, which may include a Telephone Application Server (TAS) or other application servers (AS). The AS 160B can be coupled to the IMS 168B via an S-CSCF 164B or an I-CSCF 166B.

[0042] Reference points indicate that interactions can exist between corresponding NF services. For example, Figure 1B The following reference points are shown: N1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148, not shown), N8 (between UDM 146 and AMF 132, not shown), N9 (between the two UPF 134, not shown), N10 (between UDM 146 and SMF 136, not shown), N11 (between AMF 132 and SMF 136, not shown), N12 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and AMF 132, not shown). N14 (between PCF 144 and UDM 146, not shown), N14 (between two AMF 132s, not shown), N15 (between PCF 148 and AMF 132 in non-roaming scenarios, or between PCF 148 and the visited network and AMF 132 in roaming scenarios, not shown), N16 (between two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Also available are... Figure 1BOther reference points not shown in the text are indicated.

[0043] Figure 1C The 5G system architecture 140C and its service-based representation are shown. In addition... Figure 1B In addition to the network entities shown, system architecture 140C may also include network exposure function (NEF) 154 and network repository function (NRF) 156. In some aspects, the 5G system architecture may be service-based, and the interaction between network functions may be represented by corresponding point-to-point reference points Ni, or represented as service-based interfaces.

[0044] In some aspects, such as Figure 1C As shown, service-based representations can be used to represent network functions within the control plane that enable other authorized network functions to access their services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: Namf 158H (service-based interface shown by AMF 132), Nsmf158I (service-based interface shown by SMF 136), Nnef 158B (service-based interface shown by NEF 154), Npcf158D (service-based interface shown by PCF 148), Nudm 158E (service-based interface shown by UDM 146), Naf158F (service-based interface shown by AF 150), Nnrf 158C (service-based interface shown by NRF 156), Nnssf158A (service-based interface shown by NSSF 142), and Nausf 158G (service-based interface shown by AUSF 144). It is also possible to use... Figure 1C Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf).

[0045] The NR-V2X architecture can support highly reliable, low-latency sidelink communication with various traffic patterns, including periodic and aperiodic communication with random packet arrival times and sizes. The techniques disclosed herein can be used to support high reliability in distributed communication systems with dynamic topologies, including sidelink NR V2X communication systems.

[0046] Figure 2 A block diagram of a communication device according to some embodiments is shown. Communication device 200 may be a UE (e.g., a dedicated computer, personal or notebook computer (PC), tablet PC, or smartphone), a dedicated network device (e.g., an eNB), server-running software configured to operate as a network device, a virtual device, or any machine capable of (sequentially or otherwise) executing instructions for actions to be taken by a specified machine. For example, communication device 200 may be implemented as... Figures 1A to 1C One or more devices are shown. Note that the communications described herein may be encoded before being transmitted by a sending entity (e.g., UE, gNB) for reception by a receiving entity (e.g., gNB, UE) and decoded after being received by the receiving entity.

[0047] The examples described herein may include logic or components, modules, or mechanisms, or may operate on logic or components, modules, or mechanisms. Modules and components are tangible entities (e.g., hardware) capable of performing specified operations and which can be configured or arranged in a particular manner. In the examples, circuitry may be arranged as modules in a specified manner (e.g., internally or to external entities, such as other circuitry). In the examples, all or part of one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) to operate to perform specified operations as modules. In the examples, the software may reside on a machine-readable medium. In the examples, the software, when executed by the underlying hardware of the module, causes that hardware to perform the specified operations.

[0048] Therefore, the terms "module" (and "component") are understood to encompass tangible entities, whether physically constructed, specially configured (e.g., hardwired), or temporarily (e.g., transiently) configured (e.g., programmed), to operate or perform part or all of any of the operations described herein in a specified manner. Consider an example where modules are temporarily configured, where it is not necessary to instantiate each module at any given time. For example, in the case where a module comprises a general-purpose hardware processor configured using software, this general-purpose hardware processor can be configured as various different modules at different times. The software can accordingly configure the hardware processor to constitute a specific module at one time and different modules at different times.

[0049] Communication device 200 may include a hardware processor (or equivalent processing circuitry) 202 (e.g., a central processing unit (CPU), GPU, hardware processor core, or any combination thereof), main memory 204, and static memory 206, some or all of which may communicate with each other via interconnect (e.g., bus) 208. Main memory 204 may include any or all of removable and non-removable storage devices, volatile or non-volatile memory. Communication device 200 may also include a display unit 210, such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In this example, display unit 210, input device 212, and UI navigation device 214 may be a touchscreen display. Communication device 200 may also include a storage device (e.g., a drive unit) 216, a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The communication device 200 may also include an output controller, such as serial (e.g., Universal Serial Bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC) etc.) connection, to communicate with or control one or more peripheral devices (e.g., printer, card reader, etc.).

[0050] Storage device 216 may include non-transitory machine-readable medium 222 (hereinafter referred to as machine-readable medium) storing one or more sets of data structures or instructions 224 (e.g., software) that embody or are utilized by any one or more technologies or functions described herein. During execution of instructions by communication device 200, instructions 224 may also reside wholly or at least partially in main memory 204, in static memory 206, and / or in hardware processor 202. Although machine-readable medium 222 is shown as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., centralized or distributed databases, and / or associated caches and servers) configured to store one or more instructions 224.

[0051] The term "machine-readable medium" can include any medium capable of storing, encoding, or carrying instructions that are executed by the communication device 200 and cause the communication device 200 to perform any one or more of the technologies of this disclosure, or any medium capable of storing, encoding, or carrying data structures used by or associated with such instructions. Examples of non-limiting machine-readable media can include solid-state memory, as well as optical and magnetic media. Specific examples of machine-readable media can include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM disks.

[0052] Commands 224 can also be sent or received via a communication network through network interface device 220 using transmission medium 226, utilizing any of several wireless local area network (WLAN) transport protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Example communication networks may include local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), mobile phone networks (e.g., cellular networks), simple old-style telephone (POTS) networks, and wireless data networks. Communication on the network may include one or more different protocols, such as the IEEE 802.11 standard series (known as Wi-Fi), the IEEE 802.16 standard series (known as WiMax), the IEEE 802.15.4 standard series, the Long Term Evolution (LTE) standard series, the Universal Mobile Telecommunications System (UMTS) standard series, point-to-point (P2P) networks, next-generation (NG) / fifth-generation (5G) standards, etc. In the example, network interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to transmission medium 226.

[0053] Note that the term "circuit" as used herein refers to a hardware component configured to provide the described functions, is part of, or includes the hardware component, such as electronic circuits, logic circuits, processors (shared, dedicated, or grouped) and / or memories (shared, dedicated, or grouped), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable SoCs), digital signal processors (DSPs), and so on. In some embodiments, a circuit may execute one or more software or firmware programs to provide at least some of the described functions. The term "circuit" may also refer to a combination of one or more hardware elements (or combinations of circuits used in electrical or electronic systems) and program code for performing the functions of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit.

[0054] Therefore, as used herein, the term "processor circuit" or "processor" refers to, is part of, or includes the following circuits: circuits capable of sequentially and automatically performing a series of arithmetic or logical operations, or recording, storing, and / or transmitting digital data. The term "processor circuit" or "processor" may also refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core or multi-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and / or functional processes).

[0055] Any radio link described herein may operate according to one or more of the following radio communication technologies and / or standards, including but not limited to: Global System for Mobile Communications (GSM) radio communication technology, General Packet Radio Service (GPRS) radio communication technology, Enhanced Data Rate GSM Evolution (EDGE) radio communication technology, and / or 3rd Generation Partnership Project (3GPP) radio communication technologies, such as Universal Mobile Telecommunications System (UMTS), Free Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Long Term Evolution Advanced (LTE Advanced), Code Division Multiple Access 2000 (CDMA2000), and Cellular Digital Packet Data (CDPD). Mobitex, 3rd Generation (3G), Circuit Switched Data (CSD), High-Speed ​​Circuit Switched Data (HSCSD), Universal Mobile Telecommunications System (3rd Generation) (UMTS (3G)), Wideband Code Division Multiple Access (W-CDMA (UMTS)), High-Speed ​​Packet Access (HSPA), High-Speed ​​Downlink Packet Access (HSDPA), High-Speed ​​Uplink Packet Access (HSUPA), High-Speed ​​Packet Access+ (HSPA+), Universal Mobile Telecommunications System Time Division Duplex (UMTS-TDD), Time Division Code Division Multiple Access (TD-CDMA), Time Division Synchronous Code Division Multiple Access (TD-CDMA), 3rd Generation Partnership Project Version 8 (Prior to 4th Generation) (3GPP) Rel. 8 (pre-4G), 3GPP Rel. 9 (3rd Generation Partnership Project version 9), 3GPP Rel. 10 (3rd Generation Partnership Project version 10), 3GPP Rel. 11 (3rd Generation Partnership Project version 11), 3GPP Rel. 12 (3rd Generation Partnership Project version 12), 3GPP Rel. 13 (3rd Generation Partnership Project version 13), 3GPP Rel. 14 (3rd Generation Partnership Project version 14), 3GPP Rel. 15 (3rd Generation Partnership Project version 15), 3GPP Rel. 16 (3rd Generation Partnership Project version 16), 3GPP Rel. 17 (3rd Generation Partnership Project version 17), and subsequent versions (e.g., Rel. 18, Rel. 17).19, etc.), 3GPP 5G, 5G, 5G New Radio (5G NR), 3GPP 5G New Radio, 3GPP LTE Extensions, LTE Advanced Professional, LTE Licensed Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), LTE Advanced (4th Generation) (LTE Advanced (4G)), cdmaOne (2G), Code Division Multiple Access 2000 (3rd Generation) (CDMA2000 (3G)), Optimized Evolved Data or Evolved Data Only (EV-DO), Advanced Mobile Phone Systems (1st Generation) (AMPS (1G)), Total Access Communication System / Extended Total Access Communication System (TACS / ETACS), Digital AMPS (2nd Generation) (D-AMPS (2G)), Push-to-Talk (PTT), Mobile Phone System (MTS), Improved Mobile Phone System (IMTS), Advanced Mobile Phone System (AMTS), OLT (Norwegian: Offentlig LandmobilTelefoni, Public Land Mobile Phone), MTD (Swedish: Mobiltelefonisystem) The abbreviation for D, or mobile phone system D), public automated land mobile (Autotel / PALM), ARP (Finnish Autoradiopuhelin, "car radio phone"), NMT (Nordic Mobile Telephone), NTT (Japan Telecom Telephone) mass capacity version (Hicap), cellular digital packet data (CDPD), Mobitex, DataTAC, integrated digital enhanced network (iDEN), personal digital cellular (PDC), circuit-switched data (CSD), personal handheld phone system (PHS), broadband integrated digital enhanced network (WiDEN), iBurst, unlicensed mobile access (UMA, also known as 3GPP Universal Access Network or GAN standard), Zigbee, Bluetooth (r), Wireless Gigabit Alliance (WiGig) standard, universal millimeter wave standard (wireless systems operating in 10-300 GHz and above, such as WiGig, IEEE 802.11ad, IEEE 802.11ay, etc.), technologies operating in the 300 GHz and THz bands and above (based on 3GPP / LTE, or IEEE 802.11p, or IEEE 802.11bd and others) Vehicle-to-Vehicle (V2V) and Vehicle-to-X (V2X) and Vehicle-to-Infrastructure (V2I) and Infrastructure-to-Vehicle (I2V) communication technologies, 3GPP cellular V2X, DSRC (Dedicated Short Range Communications) communication systems (e.g., smart transmission systems and others, typically operating at 5850 MHz to 5925 MHz or above (typically up to 5935 MHz, following the change recommendations in CEPT Report 71)), European ITS-G5 systems (i.e., European-style DSRC based on IEEE 802.11p, including ITS-G5A (i.e., ITS-G5 operating in the following European ITS bands, dedicated to safety-related applications in the frequency range of 5875 GHz to 5905 GHz), ITS-G5B (i.e., operating in the following European ITS bands, in the frequency range of 5855 GHz to 5875 GHz) Examples of ITS applications include: ITS-G5C (operating ITS applications in the frequency range of 5470 GHz to 5725 GHz), DSRC in Japan in the 700 MHz band (including 715 MHz to 725 MHz), and systems based on IEEE 802.11bd, etc.

[0056] The various aspects described herein can be used in the context of any spectrum management scheme, including dedicated licensed spectrum, unlicensed spectrum, license-exempt spectrum, and (licensed) shared spectrum (e.g., licensed shared access in frequencies of LSA = 2.3–2.4 GHz, 3.4–3.6 GHz, 3.6–3.8 GHz and above, and spectrum access systems in frequencies of SAS = 3.55–3.7 GHz and above / citizen broadband radio systems in frequencies of CBRS = 3.55–3.7 GHz and above). Applicable spectrum bands include IMT (International Mobile Telecommunications) spectrum and other types of spectrum / bands, such as allocated bands (including 450-470MHz, 902-928MHz (Note: e.g., allocated in the US (FCC Part 15)), 863-868.6MHz (Note: e.g., allocated in the EU (ETSI EN 300 220)), 915.9-929.7MHz (Note: e.g., allocated in Japan), 917-923.5MHz (Note: e.g., allocated in South Korea), 755-779MHz and 779-787MHz (Note: e.g., allocated in China), 790-960MHz, 1710-2025MHz, 2110-2200MHz, 2300-2400MHz, 2.4-2.4835MHz). GHz (Note: This is a globally available ISM band, used by the Wi-Fi technology family (11b / g / n / ax) and Bluetooth), 2500-2690 MHz, 698-790 MHz, 610-790 MHz, 3400-3600 MHz, 3400-3800 MHz, 3800-4200 MHz, 3.55-3.7 GHz (Note: e.g., allocated to citizen broadband radio services in the US), 5.15-5.25 GHz and 5.25-5.35 GHz and 5.47-5.725 GHz and 5.725-5.85 GHz bands (Note: e.g., allocated in the US (FCC Part 15), including four U-NII bands in a total of 500 MHz of spectrum), 5.725-5.875 GHz (Note: e.g., allocated in the EU (ETSI EN 301)). The 5.47-5.65 GHz band (e.g., allocated in South Korea), the 5925-7125 MHz band, and the 5925-6425 MHz band (note: the US and EU are considering these respectively). Next-generation Wi-Fi systems are expected to include 6 GHz spectrum as an operating band, but it's worth noting that as of December 2017, Wi-Fi systems were not permitted to use this band.Regulatory approval is expected to be finalized in 2019-2020 for IMT advanced spectrum, IMT-2020 spectrum (expected to include 3600-3800 MHz, 3800-4200 MHz, 3.5 GHz band, 700 MHz band, and bands in the 24.25-86 GHz range), spectrum available under the FCC's "Spectrum Frontier" 5G initiative (including 27.5-28.35 GHz, 29.1-29.25 GHz, 31-31.3 GHz, 37-38.6 GHz, 38.6-40 GHz, 42-42.5 GHz, 57-64 GHz, 71-76 GHz, 81-86 GHz, and 92-94 GHz), 5.9 GHz (typically 5.85-5.925 GHz), and 63-64 GHz. The frequency bands allocated to WiGig include: GHz ITS (Intelligent Transportation Systems), currently allocated bands to WiGig (e.g., WiGig band 1 (57.24-59.40 GHz), WiGig band 2 (59.40-61.56 GHz), WiGig band 3 (61.56-63.72 GHz), and WiGig band 4 (63.72-65.88 GHz)); 57-64 / 66 GHz (Note: This band has close proximity to the globally designated Multi-Gigabit Wireless Systems (MGWS) / WiGig, with a total of 14 GHz of spectrum allocated in the US (FCC Part 15), while the EU (ETSI EN 302 567 and ETSI EN 301 217-2 for fixed P2P) has allocated a total of 9 GHz of spectrum); 70.2 GHz - 71 GHz band; 65.88 GHz and 71 GHz bands. This solution can be applied to any frequency band between GHz, bands currently allocated to automotive radar applications (e.g., 76-81 GHz), and future bands (including 94-300 GHz and above). Furthermore, it can be used in conjunction with bands such as TV blank bands (typically below 790 MHz), with the 400 MHz and 700 MHz bands being promising candidates. Beyond cellular applications, specific applications in vertical markets can also be addressed, such as PMSE (Procedure for Special Events), medical, health, surgical, automotive, low-latency, and drone applications.

[0057] The various aspects described in this article can also enable the hierarchical application of the scheme, for example, by introducing hierarchical priorities for different types of users (e.g., low / medium / high priority, etc.) based on priority access to the spectrum, such as Level 1 users having the highest priority, followed by Level 2 users, then Level 3 users, and so on.

[0058] The various aspects described in this article can also be applied to different single-carrier or OFDM types (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier (FBMC), OFDMA, etc.) by assigning OFDM carrier data bit vectors to corresponding symbol resources (especially 3GPP NR (New Radio)).

[0059] Some features in this document are defined for the network side, such as AP, eNB, NR, or gNB. Note that these terms are typically used in the context of 3GPP fifth-generation (5G) communication systems, etc. Nevertheless, the UE can also play this role and act as an AP, eNB, or gNB; that is, some or all of the features defined for network devices can be implemented by the UE.

[0060] Edge computing is used for distributed computing, bringing computation and storage closer to a specific data source. Edge data networks are local data networks. Figure 3 An architecture for enabling edge applications, according to some embodiments, is illustrated. One or more edge application servers and edge enabler servers are included in an edge data network. An edge configuration server provides configuration associated with the edge enabler server, including details of the edge data network hosting the edge enabler server. The UE includes one or more application clients and edge enabler clients. The one or more edge application servers, edge enabler servers, and edge configuration servers can interact with the 3GPP core network.

[0061] To utilize edge computing, various entities need to be authenticated and authorized. Edge computing authentication and authorization include EDGE-4 authentication and EDGE-1 reference point authentication and authorization. Before initiating a secure flow for EDGE-1 or EDGE-4 authentication and authorization, the Edge Configuration Server (ECS) and Edge Enabler Client (EEC) must be successfully mounted.

[0062] Furthermore, according to 3GPP TS 23.558, each EDGE reference point enables different interactions. EDGE-6 reference points enable interaction between the edge configuration server and the edge enabler server. EDGE-6 supports registration, registration update, and deregistration of edge enabler server information to the edge enabler network configuration server. The edge enabler server registration process allows the edge enabler server to provide information to the edge configuration server to request the use of its edge configuration functions. If the information at the edge enabler server changes, the edge enabler server registration update process allows the edge enabler server to update the edge configuration server. The edge enabler server uses the edge enabler server deregistration process to remove its information from the edge configuration server.

[0063] Edge configuration servers can be deployed in a mobile network operator (MNO) domain or by a service provider in a third-party domain. One edge enabler client can communicate with one or more edge configuration servers simultaneously. An edge enabler server can connect to one or more edge configuration servers simultaneously through a single EDGE-6 reference point interface. An edge enabler server configured with multiple edge configuration server endpoint addresses can perform service registration, update, or deregistration processes multiple times depending on each edge configuration server. In this context, the security context of each EDGE-6 interface will be separated because the trust domains may be different.

[0064] Security Question

[0065] Without authentication or authorization, a malicious edge enabler server can register with the edge configuration server, further exposing its services to the edge of the UE, thereby enabling clients and applications to run on the UE.

[0066] Registration updates lacking confidentiality or integrity could allow a man-in-the-middle attack to impersonate an edge configuration server by exposing and potentially modifying a registration update with a forged edge enabler server profile to the edge configuration server. Furthermore, this attack could expose topology details and server information within the PLMN domain. Malicious actors could exploit this exposed information to benefit competitors of the PLMN or edge computing service provider.

[0067] Edge-6 Security

[0068] For messages and data transmitted over EDGE-6 reference points, confidentiality and integrity protection should be supported. Message transmissions over EDGE-6 reference points will be protected against replay attacks.

[0069] The edge configuration server will be able to authenticate edge enabler servers to register and update server configuration file information. The edge configuration server will also be able to authorize edge enabler servers to register and update server configuration file information.

[0070] Similarly, the EDGE-3 reference point enables interaction between edge enabler servers and edge application servers. Like EDGE-6, EDGE-3 supports registration, registration updates, and deregistration of edge application server information to edge enabler servers. An edge application server can connect to one or more edge enabler servers simultaneously through a single EDGE-3 reference point interface. In this context, the security context of each EDGE-3 interface will be separate because the trust domains may be different.

[0071] Edge-3 Security

[0072] For messages and data transmitted over the EDGE-3 reference point, confidentiality and integrity protection should be supported. Message transmissions over the EDGE-3 reference point will be protected against replay attacks.

[0073] The loading stream begins with the edge enabler client establishing a Transport Layer Security (TLS) connection to the edge configuration server via the Edge-4 interface. A successful TLS establishment allows the edge configuration server to transmit Edge-1 edge enabler server authentication and authorization information to the edge enabler client. After transmitting the Edge-1 edge enabler server authentication and authorization information to the edge enabler client, the TLS session is released, and the Edge-4 secure stream terminates.

[0074] More specifically, the edge enabler client and the edge configuration server protect and authenticate the loading of the edge enabler client to the edge configuration server. The edge enabler client and the edge configuration server use TLS to establish a secure session. The TLS implementation and the security profile used comply with the provisions of TS 33.310, Appendix E.

[0075] After establishing a secure session, the edge enabler client sends a Load Edge Enabler Client Request message to the edge configuration server. The Load Edge Enabler Client Request message carries loading credentials obtained during the pre-configuration loading registration process, which can be an OAuth 2.0 access token. When using an OAuth 2.0 token-based mechanism as the loading credential, the access token is encoded as a JavaScript Object Symbol (JSON) web token as specified in the Internet Engineering Task Force (IETF) Request Annotation (RFC) 7519, including a JSON web signature specified in IETF RFC 7515 and validated according to OAuth 2.0, IETF RFC 7519, and IETF RFC 7515. Other credentials (e.g., message digests) can also be used.

[0076] Figure 4 A secure process for loading an edge enabler client is illustrated according to some embodiments. Figure 4 The image shows authentication credentials based on OAuth 2.0 tokens.

[0077] like Figure 4As shown, in Operation 1, as a prerequisite for the loading process, the edge enabler client obtains loading registration information from the edge computing service provider domain. The loading registration information is used for authentication and establishing secure TLS communication with the edge configuration server during the loading process. The registration information includes details of the edge configuration server (address and root certificate authority (CA) certificate) and loading credentials (OAuth 2.0 access token).

[0078] In Operation 2, the edge enabler client and the edge configuration server establish a secure session based on TLS (Server-Side Certificate Authentication). The edge enabler client uses the registration information obtained in Operation 1 to establish a TLS session with the edge configuration server.

[0079] In operation 3, after successfully establishing a TLS session, the edge enabler client sends a Load Edge Enabler Client Request message along with registration credentials (OAuth 2.0 access token) to the edge configuration server. The edge enabler client generates a key pair {private key, public key} and provides the public key and the Load Edge Enabler Client Request message.

[0080] In operation 4, the edge configuration server verifies the registration credentials (OAuth 2.0 access token). If the credentials ( Figure 4 If the OAuth 2.0 access token verification is successful, the edge configuration server generates a profile for the edge enabler client as specified in TS 23.558, which may include a selected method for edge enabler server authentication and authorization between the edge enabler client and the edge enabler server. The edge configuration server may generate its own certificate for the edge enabler client based on the assigned edge enabler client identity and public key. This certificate is used by the edge enabler client for subsequent authentication processes with the edge configuration server and can be used to establish a secure connection and authenticate with the edge enabler server. The edge configuration server may optionally generate an Onboarding_Secret_token. The Onboarding_Secret_token value remains unchanged throughout its lifetime and is bound to an edge enabler client ID specific to the edge configuration server.

[0081] When the client certificate of the edge enabler client is issued by a third party, in operation 3, the edge enabler client may additionally include the certificate in the Load Edge Enabler Client Request message. If the edge configuration server trusts the issuer of the client certificate of the edge enabler client, in operation 4, the edge configuration server includes the provided certificate in the configuration file of the edge enabler client. Whether to accept client certificates issued by third parties is determined by the edge computing service provider's domain policy.

[0082] In operation 5, the edge configuration server responds with a loaded edge enabler client response message. The response includes the edge enabler client ID assigned by the edge configuration server, edge enabler server authentication and authorization information (if generated in operation 4), the edge enabler client's certificate, and the edge enabler client's Onboarding_Secret_token (if generated by the edge configuration server).

[0083] Refer again Figure 3 The EDGE-1 reference point enables interaction between edge enabler servers and edge enabler clients. It supports registration and deregistration of edge enabler clients to edge enabler servers, acquisition and configuration of edge application server information, and discovery of available edge application servers in the edge data network.

[0084] The edge application server provides functionality to the edge enabler client via the EDGE-1 reference point, such as configuring configuration information and supporting application context transfer. The edge enabler client performs functions such as retrieving configuration information from the edge enabler server and discovering available edge application servers in the edge data network. One or more edge application servers and edge enabler servers are included in the edge data network.

[0085] The UE is initially configured to connect to an edge data network. During initial configuration, the UE's edge-enabled client registers with one or more selected edge-enabled servers from a list of configured edge-enabled servers. The edge-enabled client uses services provided by the edge-enabled servers, such as discovering edge application servers in the area of ​​interest. This process initializes or updates the edge-enabled client's context information at the edge-enabled server. The edge-enabled client sends an edge-enabled client registration request to the edge-enabled server. Edge application server discovery enables the edge-enabled client to obtain information about available edge application servers of interest. The identification of edge application servers is based on query filters or application client profiles provided in the matching request.

[0086] Security Question

[0087] When a malicious edge enabler client uses any registration, discovery, configuration, or deregistration without authorization, it receives a list of services and the topology within the edge data network from the edge enabler server's discovery or configuration response messages. The received information may reveal the edge data network's topology (e.g., Uniform Resource Identifier (URI), Internet Protocol (IP) addresses, the number of edge application servers, application server functions, API types, and protocols). A malicious edge enabler client may use this information to launch attacks against the edge data network or for competitive reasons. Furthermore, message transmission on the EDGE-1 interface should be protected against replay attacks, man-in-the-middle (MITM) attacks, and message disputes should be prohibited.

[0088] Safety regulations

[0089] The edge enabler server can provide mutual authentication with the edge enabler client through the EDGE-1 interface.

[0090] The edge enabler server can determine whether the edge enabler client is authorized to access the services of the edge enabler server.

[0091] Message transmissions at the EDGE-1 reference point are protected by integrity.

[0092] Message transmissions at the EDGE-1 reference point are protected from replay attacks.

[0093] Message transmissions at the EDGE-1 reference point are protected by confidentiality.

[0094] EDGE4: Issues related to protecting the EDGE-4 interface

[0095] detail

[0096] The EDGE-4 reference point enables interaction between the edge configuration server and the edge enabler client. The edge configuration server provides support for the edge enabler client to connect to the edge enabler server. The EDGE-4 reference point supports the configuration of edge configuration information (e.g., URI or LADN service information) to the edge enabler client. The edge enabler client performs functions, such as retrieving configuration information from the edge configuration server via the EDGE-4 interface.

[0097] As described above, the edge configuration server can be deployed in an MNO domain or in a third-party domain. If a non-MNO edge computing service provider deploys the edge configuration server, the edge configuration server endpoint address is pre-configured to the edge enabler client. An edge enabler client configured with multiple edge configuration server endpoint addresses can perform the service provisioning process multiple times for each edge configuration server. The UE may include a single application client or multiple application clients, which are served by a single edge configuration server. In another scenario, the UE has multiple application clients, where each application client can be served by an edge application server, which in turn is served by edge enabler servers of different edge configuration servers.

[0098] Security Question

[0099] If access to configuration and setup information is gained without authentication and authorization, a malicious edge enabler client can receive a list of edge enabler server configuration information and topology within the edge data network from the configuration response message. The received information may display the topology of the edge data network (e.g., URI, Fully Qualified Domain Name (FQDN), IP address, Local Data Network (LADN) service information, application server functionality, application programming interface (API) type, and protocol).

[0100] Using the different edge deployment models described above, the edge configuration server should be able to hide the topology and configuration information between the trust domains of each application. Without such access control and hidden topology, malicious application clients could access other edge enabler servers and edge application servers. Malicious edge enabler clients might use this information to launch attacks on the edge data network or for competitive reasons. Furthermore, message transmission over EDGE-4 should be protected against replay attacks, MITM attacks, and message disputes should be prohibited.

[0101] Other security

[0102] Edge 4 Security: Confidentiality and integrity protection should be supported for messages and data transmitted over EDGE-4 reference points.

[0103] Edge Configuration Server: The edge configuration server provides mutual authentication with edge enabler clients via the EDGE-4 interface. The edge configuration server can determine whether an edge enabler client is authorized to access the configuration services provided by the edge configuration server. The edge configuration server can hide the topology details between the trust domains of each application client.

[0104] Safety procedures for EDGE-4 reference points

[0105] TLS is used to provide integrity protection, replay protection, and confidentiality protection. Support for TLS is mandatory or optional, depending on the domain administrator's policy, to protect interfaces within a trusted domain. Unless the EDGE-4 reference point is secured by other means, the following procedure can be followed.

[0106] Safety procedures for EDGE-4 reference points

[0107] Authentication and Authorization

[0108] Overview

[0109] For authentication of the EDGE-4 reference point, TLS is used to perform mutual authentication based on client and server certificates between the edge configuration server and the edge enabler client.

[0110] Certificate-based authentication follows the configuration files given in 3GPP TS 33.310, sub-clauses 6.1.3a and 6.1.4a. The structure of the public key infrastructure (PKI) used for certificates is beyond the scope of this document.

[0111] TLS is used to provide integrity, replay, and confidentiality protection for the EDGE-4 interface. Support for TLS on the EDGE-4 interface is mandatory. The TLS implementation and the security profile used comply with the specifications in TS 33.310, Appendix E.

[0112] Security method negotiation

[0113] The edge enabler client and the edge configuration server negotiate a security method used by both for EDGE-1 interface authentication and protection. Following successful mutual authentication on the EDGE-4 interface, the edge configuration server selects a security method based on its capabilities and sends the selected method, along with the edge enabler client's authentication information from the edge enabler server, to the edge enabler client. This information may include the validity period of the EDGE-1 credentials. This is in... Figure 5 It was described in the text. Figure 5 The selection of security methods used at the EDGE-1 reference point is shown according to some embodiments.

[0114] Figure 5 The prerequisites for this method include the edge enabler client loading data to the edge configuration server. Figure 5 In Operation 1, TLS is used to establish mutual authentication between the edge enabler client and the edge configuration server based on client and server certificates. The client certificate provided to the edge enabler client due to successful loading is used.

[0115] In Operation 2, the edge enabler client can send EDGE-1 security capability information to the edge configuration server in a security method request message, indicating the list of security methods supported by the edge enabler client for each edge enabler server at the EDGE-1 reference point.

[0116] In Operation 3, the edge configuration server selects the security method to be used on the EDGE-1 reference point for each request from the edge enabler server, taking into account the information from the edge enabler client, the access scenario, and the edge enabler server functionality from Operation 2.

[0117] In operation 4, the edge configuration server sends a security method response message to the edge enabler client, indicating the selected security method for each edge enabler server, along with any security information associated with that method. The edge enabler client uses this method in establishing subsequent communication with the edge enabler server via the EDGE-1 reference point.

[0118] 1.1.3 Service and Method Discovery

[0119] After successful authentication between the edge enabler client and the edge configuration server, the edge configuration server determines whether to authorize the edge enabler client to perform discovery based on the edge enabler client ID and discovery policy.

[0120] 1.1.4 Topology Hiding

[0121] When implementing topology hiding, the edge configuration server uses edge enabler server information to respond to service application programming interface (API) discovery requests and acts as the topology hiding entity.

[0122] Safety procedures for EDGE-1 reference points

[0123] TLS is used to provide integrity protection, replay protection, and confidentiality protection. Support for TLS is mandatory or optional, depending on the domain administrator's policy, to protect interfaces within a trusted domain.

[0124] Safety procedures for EDGE-1 reference points

[0125] Overview

[0126] Based on the security method selected by the edge configuration server, the edge enabler client and the edge enabler server use one of the following specified methods for EDGE-1 interface authentication and protection.

[0127] Authentication and Authorization

[0128] Method 1 – Using TLS-PSK

[0129] The edge enabler client and edge enabler server follow the procedure of Method 1 to establish a dedicated secure session using a pre-shared key (PSK)-based TLS connection. EDGE-4 authentication is used to bootstrap the PSK for authentication of EDGE-1 TLS connections. It is assumed that both the edge enabler client and the edge configuration server are pre-configured with certificates. The TLS profile specified in Appendix E of TS 33.310 is used.

[0130] Figure 6 The use of TLS-PSK for EDGE-1 interface authentication and protection is illustrated according to some embodiments. Figure 6 The message flow between the edge enabler client, the edge configuration server, and the edge enabler server is described in detail to establish a secure EDGE-1 interface using a pre-shared key for authentication.

[0131] In Operation 1, an EDGE-4 authentication and security session was established as described above. The edge configuration server provides the EES key. PSK The valid timer value.

[0132] In Operation 2, after successfully establishing TLS on EDGE-4, the edge enabler client and the edge configuration server obtain the key EES. PSK Key EES PSK Binds to the edge enabler server. Edge enabler client and edge configuration server startup key EES. PSK Valid timer.

[0133] In operation 3, the edge enabler client sends an authentication initiation request to the edge enabler server, including the edge enabler client ID assigned by the edge configuration server. If the edge enabler client already possesses a valid key EES... PSK If so, operations 1 and 2 in the process can be skipped. In this case, the edge enabler client starts the process at operation 3.

[0134] In Operation 4A, if the edge enabler server does not have a valid key, it requests security information from the edge configuration server to perform authentication and establish a secure interface with the edge enabler client. In Operation 4B, the edge configuration server provides the edge enabler server with security information related to the selected security method (TLS-PSK: EES) via an EDGE-6 reference point. PSK The edge configuration server provides the key EES. PSK The remaining valid timer value.

[0135] In operation 5, the relevant security information (EES) used for authentication is obtained. PSKFollowing this, the edge enabler server sends an authentication initiation response message to the edge enabler client to initiate a TLS session. The edge enabler server starts a valid timer based on the value received from the edge configuration server in step 4.

[0136] In Operation 6, the edge enabler client and the edge enabler server use the key EES. PSK To perform mutual authentication and establish a TLS session via EDGE-1.

[0137] After successfully establishing TLS at the EDGE-1 reference point, the edge enabler server authorizes the service API call requests of the edge enabler client based on the authorization information obtained from the edge configuration server.

[0138] Method 2 – Using PKI

[0139] The edge enabler client and edge enabler server follow the procedure of Method 2 to establish a dedicated secure session over EDGE-1 using TLS with mutual certificate authentication. It is assumed that both the edge enabler client and edge enabler server are pre-configured with certificates.

[0140] Figure 7 The following illustrates EDGE-1 interface authentication and protection using certificate-based mutual authentication according to some embodiments. Figure 7 The message flow between the edge enabler client, edge configuration server, and edge enabler server related to this security method is described in detail.

[0141] In Operation 1, the edge enabler client sends an authentication initiation request to the edge enabler server. This request includes the edge enabler client ID.

[0142] In Operation 2A, the edge enabler server requests security information from the edge configuration server to perform authentication and establish a secure interface with the edge enabler client. In Operation 2B, the edge configuration server provides the edge enabler server with security information (TLS-PKI) related to the selected security method via an EDGE-6 reference point. The edge configuration server may return the root CA certificate of the edge enabler client for the edge enabler server to verify the client's certificate.

[0143] In operation 3, after obtaining the relevant security information for authentication, the edge enabler server sends an authentication initiation response message to the edge enabler client to initiate the TLS session establishment process.

[0144] In Operation 4, the edge enabler client and edge enabler server use certificates to perform mutual authentication and establish a TLS session via EDGE-1. Certificate-based authentication follows the configuration files given in 3GPP TS 33.310, Clauses 6.1.3a and 6.1.4a.

[0145] After successfully establishing TLS at the EDGE-1 reference point, the edge enabler server authorizes the service API call requests of the edge enabler client based on the authorization information obtained from the edge configuration server.

[0146] Method 3 – TLS with OAuth Token

[0147] This method details how to establish a secure channel through EDGE-4 and EDGE-1 reference points, and how to authorize service requests from edge enabler clients to edge enabler servers using an OAuth2.0 token-based mechanism. Figure 8 The use of access tokens for EDGE-1 interface authentication and protection is illustrated according to some embodiments. Figure 8 This document details the secure information flow between the edge enabler client, the edge configuration server, and the edge enabler server. It assumes that the edge enabler client, edge configuration server, and edge enabler server are all pre-configured with appropriate credentials and related information to establish a secure session.

[0148] According to OAuth 2.0, the edge configuration server performs the functions of the authorization and token protocol endpoint; the edge enabler client performs the functions of the resource owner, client, and redirection endpoints; and the edge enabler server performs the resource server functions. The edge enabler client (client endpoint) is registered as a confidential client type, and its authorization grant type is "client credentials".

[0149] In Operation 1, EDGE-4 authentication and secure session establishment are performed as described above.

[0150] In Operation 2, after a successful TLS session is established on EDGE-4, the edge enabler client sends an access token request message to the edge configuration server in accordance with the OAuth 2.0 specification, as described in Subclause 1.1 of this document.

[0151] In operation 3, the edge configuration server verifies the access token request message according to the OAuth 2.0 specification.

[0152] In operation 4, if the edge configuration server successfully verifies the access token request message, the edge configuration server generates an access token specific to the edge enabler client and returns the access token in the access token response message.

[0153] If the edge-enabled client already has a valid OAuth access token, it can skip this step. Figure 8 Operations 1 through 4. In this case, the edge enabler client begins the process at operation 5. The edge enabler client may include the edge enabler client ID assigned by the edge configuration server and the Onboard_Secret_token from the OAuth access token request message for the edge configuration server to verify the access token request.

[0154] In Operation 5, on EDGE-1, the edge enabler client authenticates to the edge enabler server by establishing a TLS session with the edge enabler server according to the authentication and authorization method indicated by the edge configuration server (i.e., server-side certificate authentication (edge ​​enabler server) or certificate-based mutual authentication).

[0155] Before establishing a TLS session, the following steps must be performed:

[0156] The edge enabler client sends an authentication initiation request to the edge enabler server. This request includes the edge enabler client ID.

[0157] The edge enabler server requests security information from the edge configuration server to perform authentication and establish a secure interface with the edge enabler client. The edge configuration server provides the edge enabler server with security information related to the selected security method (TLS with an OAuth token) via an EDGE-6 reference point. The edge configuration server may return the root CA certificate of the edge enabler client for the edge enabler server to verify the client's certificate.

[0158] After obtaining the relevant security information for authentication, the edge enabler server sends an authentication initiation response message to the edge enabler client to initiate the TLS session establishment process.

[0159] In Operation 6, after successful authentication with the edge enabler server on EDGE-1, the edge enabler client initiates other processes, such as registering, discovering, and deregistering with the edge enabler server. An access token is sent along with these methods.

[0160] In operation 7, the edge enabler server verifies the access token. The edge enabler server verifies the integrity of the access token by verifying the edge configuration server signature. If the verification of the access token is successful, the edge enabler server will verify the service request from the edge enabler client against the authorization statement in the access token to ensure that the edge enabler client has access rights to the requested service.

[0161] In operation 8, the edge enabler server sends a response to the request from the edge enabler client in operation 6.

[0162] Figure 9 A secure process for loading an edge application server is illustrated according to some embodiments. Figure 9 The image shows authentication credentials based on OAuth 2.0 tokens.

[0163] like Figure 9 As shown, in Operation 1, as a prerequisite for the loading process, the edge application server obtains loading registration information from the edge computing service provider domain. This loading registration information is used for authentication and establishing secure TLS communication with the edge enabler server during the loading process. The registration information includes details of the edge enabler server (address and root CA certificate) and loading credentials (OAuth 2.0 access token).

[0164] In Operation 2, the edge application server and the edge enabler server establish a secure session based on TLS (Server-Side Certificate Authentication). The edge application server uses the registration information obtained in Operation 1 to establish a TLS session with the edge enabler server.

[0165] In operation 3, after successfully establishing a TLS session, the edge application server sends an Edge Application Server Request message along with registration credentials (OAuth 2.0 access token) to the edge enabler server. The edge application server generates a key pair {private key, public key} and provides the public key and the Edge Application Server Request message.

[0166] In operation 4, the edge enabler server verifies the registration credentials (OAuth 2.0 access token). If the credentials ( Figure 9 If the OAuth 2.0 access token verification is successful, the edge enabler server generates a configuration file for the edge application server as specified in TS 23.558, which may include the selected method for edge application server authentication and authorization between the edge application server and the edge enabler server. The edge enabler server may generate its own certificate for the assigned edge application server identity and public key. This certificate is used by the edge application server in subsequent authentication processes with the edge enabler server and can be used to establish a secure connection and authenticate with the edge application server. The edge enabler server may optionally generate an Onboarding_Secret_token. The Onboarding_Secret_token value remains unchanged throughout its lifetime and is bound to an edge application server ID specific to the edge enabler server.

[0167] When the client certificate for the edge application server is issued by a third party, in operation 3, the edge application server can additionally include the certificate in the loading edge application server request message. If the edge enabler server trusts the issuer of the client certificate for the edge application server, in operation 4, the edge enabler server includes the provided certificate in the edge application server's configuration file. Whether to accept client certificates issued by third parties is determined by the edge computing service provider's domain policy.

[0168] In operation 5, the edge enabler server responds with a response message loaded from the edge application server. The response includes the edge application server ID assigned by the edge enabler server, the edge enabler server authentication and authorization information (if generated in operation 4), the edge application server certificate, and the edge application server Onboarding_Secret_token (if generated by the edge enabler server).

[0169] The Onboarding_Secret_token can be bound to events received from the application client on the UE. These events can be, for example, UE configuration or user approval for access to a specific API. In one example, the edge application server can request access to the UE's location by sending a request to the edge enabler server, which in turn can contact the 3GPP core network via the EDGE-2 interface. To authorize such a request, the edge enabler server checks the Onboarding_Secret_token, which can be bound to the user's permission on the UE for such access by the edge application server (in the example above, access to the UE's own location). After a yes / no indication related to permission (either bound to the Onboarding_secret_token or used to generate a token in the token generation function), the edge enabler server can verify the token received from the edge application server so that the user confirms the access, and then proceed to access the location according to the procedures in TS 23.558.

[0170] The token binding algorithm uses a byte string to compute the token signature, which represents a concatenation of the following: the TokenBindingType value contained in the TokenBinding.tokenbinding_type field (which is the "user configuration parameter" and the "type of the requested service, e.g., location service"), the TokenBindingKeyParameters value contained in the TokenBindingID.key_parameters field (which is the "value of the user configuration parameter, e.g., yes / no"), and the Exported Keying Material (EKM) value obtained from the current TLS connection. The TokenBindingKeyParameters value can be checked first, and if the TokenBindingKeyParameters value indicates yes for the service, the TokenBinding.tokenbinding_type value can then be checked.

[0171] While embodiments have been described with reference to specific exemplary examples, it will be understood that various modifications and changes can be made to these embodiments without departing from the broader scope of this disclosure. Therefore, the specification and drawings should be considered illustrative rather than restrictive. The accompanying drawings, which form a part of this document, illustrate specific embodiments in which the subject matter can be implemented in an illustrative and not limiting manner. The illustrated embodiments have been described in sufficient detail to enable those skilled in the art to implement the teachings disclosed herein. Other embodiments can be utilized and derived from them, thereby allowing structural and logical substitutions and changes to be made without departing from the scope of this disclosure. This detailed description section should therefore not be construed in a limiting sense, and the scope of the various embodiments is defined only by the appended claims and their full equivalents.

[0172] The subject matter may be referred to herein individually and / or generally by the term "embodiment," for convenience only, and is not intended to actively limit the scope of this application to any single inventive concept if more than one is actually disclosed. Thus, while specific embodiments have been illustrated and described herein, it should be understood that any arrangement intended to achieve the same purpose may replace the specific embodiments shown. This disclosure is intended to cover any and all adaptive changes or variations of the various embodiments. Those skilled in the art will clearly see, upon reading the above description, combinations of the above embodiments and other embodiments not specifically described herein.

[0173] In this document, as is common in patent documents, the terms “a” or “an” are used to include one or more, independent of any other instance or use of “at least one” or “one or more.” In this document, the term “or” is used to refer to a non-exclusive “or,” such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In this document, the terms “comprising” and “in which” are used as concise English equivalents to the corresponding terms “including” and “wherein.” Furthermore, in the appended claims, the terms “comprising” and “including” are open-ended, meaning that a system, UE, article, composition, formulation, or process that includes other elements besides those listed after such terms in the claims is still considered to fall within the scope of the claims. Additionally, in the appended claims, the terms “first,” “second,” and “third,” etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0174] This abstract is provided to comply with 37 CFR 1.72(b), which requires an abstract that allows the reader to quickly determine the nature of the technical disclosure. The abstract is submitted under the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the foregoing Detailed Description section, various features are grouped together in a single embodiment for the purpose of simplification. This approach to disclosure should not be construed as reflecting a desire to claim embodiments requiring more features than expressly recited in each claim. Rather, as reflected in the appended claims, the inventive subject matter resides in fewer than all features of a single disclosed embodiment. Therefore, the appended claims are hereby incorporated into the Detailed Description section, wherein each claim stands alone as a separate embodiment.

Claims

1. An apparatus for an edge-enabled client, the apparatus comprising: The processing circuit is configured as follows: Use Transport Layer Security (TLS) and client and server certificates to perform mutual authentication with the edge configuration server; Encode the EDGE-1 security capability information in the security method request message for transmission to the edge configuration server. The EDGE-1 security capability information indicates a list of security methods supported by the edge enabler client at the EDGE-1 reference point of each of the multiple edge enabler servers. as well as Decode the security method response message from the edge configuration server, the security method response message indicating to each edge enabler server the security method selected by the edge configuration server to be used on the EDGE-1 reference point of each edge enabler server and the security information associated with the security method; as well as The memory is configured to store secure methods for each edge enabler server.

2. The apparatus according to claim 1, wherein, The processing circuitry is also configured to encode an edge enabler client identifier (ID) for transmission to the edge configuration server, the edge enabler client identifier being used to determine whether the edge enabler client is authorized to perform discovery based on a discovery policy.

3. The apparatus according to claim 1, wherein, The processing circuit is further configured to: Decode the valid timer value of the key bound to a specific edge enabler server from the edge configuration server. After establishing a TLS session with the edge configuration server at the EDGE-4 reference point, the key is exported. Start the valid timer for the key. An authentication initiation request is encoded for transmission to the specific edge enabler server, and the authentication initiation request includes an edge enabler client identifier (ID) assigned by the edge configuration server. Before the expiration of the validity timer, decode the authentication initiation response message from the specific edge enabler server. This message is used in response to the specific edge enabler server obtaining security information about the edge enabler client from the edge configuration server to initiate a TLS session with the specific edge enabler server. The security information includes the key and the remaining time of the validity timer. The key is used to perform mutual authentication with the specific edge enabler server and to establish a TLS session with the specific edge enabler server at the EDGE-1 reference point.

4. The apparatus according to claim 1, wherein, The processing circuit is further configured to: An authentication initiation request is encoded for transmission to a specific edge enabler server, and the authentication initiation request includes an edge enabler client identifier (ID). Decode the authentication initiation response message from the specific edge enabler server. This message is used in response to the specific edge enabler server obtaining security information about the edge enabler client from the edge configuration server and verifying the edge enabler client based on that security information to initiate a TLS session with the specific edge enabler server. The security information involves the use of the edge enabler client's Transport Layer Security Pre-Shared Key Cipher Suite (TLS-PSK) and root certificate authority (CA) certificate. The root CA certificate of the edge enabler client and the specific edge enabler server is used to perform mutual authentication with the specific edge enabler server and to establish a TLS session with the specific edge enabler server at the EDGE-1 reference point.

5. The apparatus according to claim 1, wherein, The processing circuit is further configured to: After establishing a TLS session with the edge configuration server at the EDGE-4 reference point, an access token request message is encoded for transmission to the edge configuration server. In response to the edge configuration server's verification of the access token request message, an access token response message from the edge configuration server is decoded. This access token response message contains an access token granting the edge enabler client access to one or more services. A TLS session is established with a specific edge enabler server based on certificate authentication or certificate-based mutual authentication as indicated by the edge configuration server. After establishing a TLS session with the specific edge enabler server, one or more procedures are invoked with the specific edge enabler server at the EDGE-1 reference point via a transport service request. The service request includes the access token and the requested service, and the one or more procedures are selected from registration, discovery, and deregistration. In response to the verification of the access token by verifying the signature of the edge configuration server and the verification of the service request by verifying the authorization statement of access permission for the requested service in the access token, a service response from the specific edge enabler server is decoded, the service response containing a response to the service that performed the request.

6. The apparatus according to claim 5, wherein, Before establishing the TLS session with the edge enabler server, the processing circuitry is also configured to: An authentication initiation request is encoded for transmission to the specific edge enabler server. The authentication initiation request includes an edge enabler client identifier (ID), and... In response to the authentication of the edge enabler client based on the security information of the security method selected by the edge enabler client and the verification of the root certificate authority (CA) certificate of the edge enabler client, an authentication initiation response message from the specific edge enabler server is decoded, the authentication initiation response message being used to initiate the establishment of the TLS session with the edge enabler server.

7. The apparatus according to claim 5, wherein, The access token request message includes an edge enabler client identifier (ID) assigned by the edge configuration server and an Onboard_Secret_token, which are used to verify the access token request message.

Images