CN115777193A

CN115777193A - Edge security program for edge enabler server loading

Info

Publication number: CN115777193A
Application number: CN202180048169.2A
Authority: CN
Inventors: 阿比吉特·阿肖克·科勒卡尔
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-08-04
Filing date: 2021-07-29
Publication date: 2023-03-10
Also published as: WO2022031505A1

Abstract

An apparatus and system for implementing a safety procedure for an edge device is described. Authentication and authorization are performed for the loading of the edge configuration server, edge enabler server and edge application server. Also described are security procedures for EDGE-1 and EDGE-4 reference points (which use a secure method selected by the EDGE enabler client and negotiated with the EDGE configuration server). The security method is based on TLS-PSK, certificate-based mutual authentication, or on an access token.

Description

Edge security program for edge enabler server loading

Priority declaration

Priority rights are claimed in this application for U.S. provisional patent application serial No. 63/061,068, filed on 8/4/2020, U.S. provisional patent application serial No. 63/061,071, filed on 8/4/2020, U.S. provisional patent application serial No. 63/061,095, filed on 8/4/2020, and U.S. provisional patent application serial No. 63/061,096, filed on 8/4/2020, which are incorporated herein by reference in their entireties.

Technical Field

Embodiments relate to fifth generation (5G) wireless communications. In particular, some embodiments relate to edge computing in 5G networks.

Background

The use and complexity of wireless systems, including 4 th generation (4G) and 5 th generation (5G) networks, etc., has increased as the device types of User Equipment (UEs) using network resources have increased and the amount of data and bandwidth used by various applications (e.g., video streams) operating on these UEs have increased. With the proliferation of the number and variety of communication devices, the corresponding network environments, including routers, switches, bridges, gateways, firewalls, and load balancers, have become more and more complex, particularly with the advent of Next Generation (NG) (or New Radio (NR)) systems. As expected, the advent of any new technology has brought about a number of problems.

Drawings

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.

Fig. 1A illustrates an architecture of a network according to some aspects.

Fig. 1B illustrates a non-roaming 5G system architecture, in accordance with some aspects.

Fig. 1C illustrates a non-roaming 5G system architecture, in accordance with some aspects.

Fig. 2 illustrates a block diagram of a communication device, in accordance with some embodiments.

FIG. 3 illustrates an architecture for enabling edge applications, in accordance with some embodiments.

Figure 4 illustrates a security process for edge enabler client loading (onboarding) according to some embodiments.

Figure 5 illustrates selection of a security method for use in an EDGE-1 reference point, in accordance with some embodiments.

Fig. 6 illustrates EDGE-1 interface authentication and protection using transport layer secure pre-shared key cipher suites (TLS-PSK) in accordance with some embodiments.

Figure 7 illustrates EDGE-1 interface authentication and protection using certificate-based mutual authentication, in accordance with some embodiments.

Figure 8 illustrates EDGE-1 interface authentication and protection using an access token, in accordance with some embodiments.

Figure 9 illustrates a security process for edge application server loading according to some embodiments.

Detailed Description

The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of others. Embodiments set forth in the claims encompass all available equivalents of those claims.

Fig. 1A illustrates an architecture of a network according to some aspects. The network 140A includes 3GPP LTE/4G and NG network functionality, which may be extended to 6G functionality. Thus, while reference will be made to 5G, it should be understood that this can be extended to 6G structures, systems and functions. The network functions may be implemented as discrete network elements on dedicated hardware, as software instances running on dedicated hardware, and/or as virtualized functions instantiated on an appropriate platform (e.g., dedicated hardware or cloud infrastructure).

Network 140A is shown to include User Equipment (UE) 101 and UE 102. The UEs 101 and 102 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable 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 handset, a drone, or any other computing device that includes a wired and/or wireless communication interface. UEs 101 and 102 may be collectively referred to herein as UE 101, and UE 101 may be configured to perform one or more of the techniques disclosed herein.

Any of the radio links described herein (e.g., as used in network 140A or any other illustrated network) may operate in accordance with any of the exemplary radio communication technologies and/or standards. 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.4GHz, 3.4-3.6GHz, 3.6-3.8GHz, and other frequencies, and Spectrum Access System (SAS) in 3.55-3.7GHz, and other frequencies). Different single carrier or Orthogonal Frequency Domain Multiplexing (OFDM) modes (CP-OFDM, SC-FDMA, SC-OFDM, filter bank based multi-carrier (FBMC), OFDMA, etc.), in particular 3GPP NR, can be used by allocating OFDM carrier data bit vectors to the respective symbol resources.

In some aspects, either of UEs 101 and 102 may comprise an internet of things (IoT) UE or a cellular IoT (CIoT) UE, which may include a network access layer designed for low-power internet of things applications that utilize short-lived UE connections. In some aspects, either of UEs 101 and 102 may include a Narrowband (NB) IoT UE (e.g., an enhanced NB-IoT (eNB-IoT) UE and a further enhanced (FeNB-IoT) UE). IoT UEs may exchange data with MTC servers or devices through Public Land Mobile Networks (PLMNs), proximity-based services (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks using technologies such as machine-to-machine (M2M) or Machine Type Communication (MTC). The M2M or MTC data exchange may be a machine-initiated data exchange. The IoT network includes interconnected connected IoT UEs, which may include uniquely identifiable embedded computing devices (within the internet infrastructure), with short-lived connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network. In some aspects, either of UEs 101 and 102 may comprise an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

UEs 101 and 102 may be configured to connect (e.g., communicatively couple) with a Radio Access Network (RAN) 110. RAN 110 may be, for example, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio Access network (E-UTRAN), a next generation RAN (NG RAN), or other types of RANs.

The UEs 101 and 102 utilize

connections

103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below); in this example,

connections

103 and 104 are shown as air interfaces that enable communicative coupling, and may conform to a cellular communication protocol, such as a global system for mobile communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a push-to-talk (PTT) protocol, a PTT-over-cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a 5G protocol, a 6G protocol, and so forth.

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

UE 102 is shown configured to access an Access Point (AP) 106 via a connection 107. Connection 107 may include a local wireless connection, e.g., a connection conforming to any IEEE 802.11 protocol according to which AP106 may include wireless fidelity

A router. In this example, the AP106 is shown connected to the internet without being connected to the core network of the wireless system (described in further detail below).

RAN 110 may include one or more access nodes that enable

connections

103 and 104. These Access Nodes (ANs) may be referred to as Base Stations (BSs), 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 transmission/reception points (TRPs). In the case where the communication nodes 111 and 112 are nodebs (e.g., enbs or gnbs), one or more TRPs may function within the communication cells of the NodeB. RAN 110 may include one or more RAN nodes (e.g., macro RAN node 111) to provide a macro cell, and one or more RAN nodes (e.g., low Power (LP) RAN node 112) to provide a femto cell or a pico cell (e.g., a cell with less coverage area, less user capacity, or higher bandwidth than the macro cell).

Either of RAN nodes 111 and 112 may terminate (terminate) an air interface protocol and may be the first contact point for UEs 101 and 102. In some aspects, any of RAN nodes 111 and 112 may 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 data packet scheduling, and mobility management. In an example, any of nodes 111 and/or 112 may be a gNB, eNB, or other type of RAN node.

RAN 110 is shown communicatively coupled to a Core Network (CN) 120 over S1 interface 113. In various aspects, the 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., as shown with reference to fig. 1B-1C). In this aspect, the S1 interface 113 is divided into two parts: an S1-U interface 114 that carries traffic data between RAN nodes 111 and 112 and serving gateway (S-GW) 122; and S1 Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN nodes 111 and 112 and MME 121.

In this aspect, CN 120 includes MME 121, S-GW 122, packet Data Network (PDN) gateway (P-GW) 123, and Home Subscriber Server (HSS) 124.MME 121 may be similar in function to the control plane of a conventional serving General Packet Radio Service (GPRS) support node (SGSN). MME 121 may manage mobility aspects in access such as gateway selection and tracking area list management. HSS 124 may include a database of network users that includes subscription-related information used to support network entities handling communication sessions. The CN 120 may include one or several HSS 124 depending on the number of mobile subscribers, the capacity of the devices, the organization of the network, etc. For example, HSS 124 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, and the like.

The S-GW 122 may terminate S1 interface 113 towards RAN 110 and route data packets between RAN 110 and CN 120. In addition, S-GW 122 may be a local mobility anchor for inter-RAN node handovers and may also provide an anchor for inter-3 GPP mobility. Other responsibilities of S-GW 122 may include lawful interception, charging, and some policy enforcement.

The P-GW123 may terminate the SGi interface towards the PDN. P-GW123 may route data packets between EPC network 120 and an external network, such as a network that includes application server 184 (or a network referred to as an Application Function (AF)), through Internet Protocol (IP) interface 125. The P-GW123 may also transmit data to other external networks 131A, which other external networks 131A may include the internet, an IP multimedia Subsystem (IPs) network, and other networks. In general, the application server 184 may be an element that provides applications that use IP bearer resources with a core network (e.g., UMTS Packet Service (PS) domain, LTE PS data services, etc.). In this aspect, P-GW123 is shown communicatively coupled to application server 184 via IP interface 125. The application server 184 may 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 the

UEs

101 and 102 through the CN 120.

The P-GW123 may also be a node for policy enforcement and charging data collection. Policy and Charging Rules Function (PCRF) 126 is a policy and charging control element of CN 120. In a non-roaming scenario, in some aspects, there may be a single PCRF in a Home Public Land Mobile Network (HPLMN) that is associated with an internet protocol connectivity access network (IP-CAN) session for a UE. In a roaming scenario with local traffic disruption, there may be two PCRFs associated with the IP-CAN session of the UE: a home PCRF (H-PCRF) within the HPLMN, and a visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). PCRF 126 may be communicatively coupled to application server 184 via P-GW 123.

In some aspects, the communication network 140A may be an IoT network or a 5G or 6G network, including a 5G new radio network that uses communication in licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current IoT implementations is narrowband IoT (NB-IoT). Operations in unlicensed spectrum may include Dual Connectivity (DC) operations as well as standalone LTE systems in unlicensed spectrum according to which LTE-based technologies operate only in unlicensed spectrum without using an "anchor" in the licensed spectrum, known as MulteFire. In future releases and 5G systems, it is desirable to further enhance the operation of LTE systems in licensed as well as unlicensed spectrum. Such enhanced operations may include techniques for sidelink resource allocation and UE processing behavior for NR sidelink V2X communications.

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

In some aspects, the NG system architecture may use a reference point between various nodes. In some aspects, each of the gnbs and NG-enbs may be implemented as a base station, a mobile edge server, a small cell, a home eNB, or the like. In some aspects, in a 5G architecture, the gNB may be a Master Node (MN) and the NG-eNB may be a Slave Node (SN).

Fig. 1B illustrates a non-roaming 5G system architecture, in accordance with some aspects. In particular, fig. 1B shows a 5G system architecture 140B, denoted by reference point, which may be extended to a 6G system architecture. More specifically, UE 102 may communicate with RAN 110 and one or more other 5GC network entities. The 5G system architecture 140B includes a plurality of Network Functions (NFs), such as an AMF 132, a Session Management Function (SMF) 136, a Policy Control Function (PCF) 148, an Application Function (AF) 150, a UPF134, a Network Slice Selection Function (NSSF) 142, an authentication server function (AUSF) 144, and a Unified Data Management (UDM)/Home Subscriber Server (HSS) 146.

The UPF134 may provide connectivity to a Data Network (DN) 152, which may include, for example, operator services, internet access, or third party services. The AMF 132 may be used to manage access control and mobility and may also include network slice selection functionality. The AMF 132 may provide UE-based authentication, authorization, mobility management, etc., and may be independent of the access technology. SMF136 may be configured to set up and manage various sessions according to network policies. Accordingly, SMF136 may be responsible for session management and assignment of IP addresses to UEs. The SMF136 may also select and control the UPF134 for data transmission. SMF136 may be associated with a single session of UE 101 or multiple sessions of UE 101. That is, the UE 101 may have multiple 5G sessions. Each session may be assigned a different SMF. Using different SMFs may allow each session to be managed separately. Thus, the functionality of each session may be independent of each other.

The UPF134 may be deployed in one or more configurations according to a desired service type and may be connected to a data network. PCF 148 may be configured to provide a policy framework (similar to a PCRF in a 4G communication system) that uses network slicing, mobility management, and roaming. The UDM may be configured to store subscriber profiles and data (similar to the HSS in a 4G communication system).

AF 150 may provide information about the packet flow to PCF 148, which is responsible for policy control, to support the desired QoS. The PCF 148 may set mobility and session management policies for the UE 101. To this end, PCF 148 may use the packet flow information to determine an appropriate policy for proper operation of AMF 132 and SMF 136. The AUSF 144 may store data for UE authentication.

In some aspects, the 5G system architecture 140B includes an IP Multimedia Subsystem (IMS) 168B and a plurality of IP multimedia core network subsystem entities, such as Call Session Control Functions (CSCFs). More specifically, IMS 168B includes a CSCF, which may be a proxy CSCF (P-CSCF) 162B, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) (not shown in FIG. 1B), or an interrogating CSCF (I-CSCF) 166B. P-CSCF 162B may be configured as a first point of contact for UE 102 within IM Subsystem (IMs) 168B. The S-CSCF 164B may be configured to handle session states in the network and the E-CSCF may be configured to handle certain aspects of the emergency session, such as routing the emergency request to the correct emergency centre or PSAP. The I-CSCF 166B may be configured to act as a contact point within an operator's network for all IMS connections destined for subscribers of the network operator, or roaming users currently located within the service area of the network operator. In some aspects, the I-CSCF 166B may be connected to another IP multimedia network 170E, e.g., an IMS operated by a different network operator.

In some aspects, the UDM/HSS 146 may be coupled to an application server 160E, which application server 160E may include a Telephony Application Server (TAS) or other Application Server (AS). The AS 160B may be coupled to the IMS 168B through an S-CSCF 164B or an I-CSCF 166B.

The reference point representation shows that there may be interactions between the respective NF services. For example, fig. 1B shows the following reference points: n1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF134 and DN 152), N7 (between SMF136 and PCF 148, not shown), N8 (between UDM 146 and AMF 132, not shown), N9 (between two UPFs 134, not shown), N10 (between UDM 146 and SMF136, not shown), N11 (between AMF 132 and SMF136, not shown), N12 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and UDM 146, not shown), N14 (between two AMFs 132, not shown), N15 (between

amsfs

148 and 148 in the case of non-roaming, or between amsfs 148 and PCF 148, between SMF 132, between the case of roaming, and PCF 22, between SMF 132, not shown), and visited network 132 (between SMF 22, not shown), and visited network 142). Other reference point representations not shown in FIG. 1B may also be used.

Fig. 1C illustrates a 5G system architecture 140C and a service-based representation. In addition to the network entities shown in fig. 1B, the system architecture 140C may also include a Network Exposure Function (NEF) 154 and a Network Repository Function (NRF) 156. In some aspects, the 5G system architecture may be service-based, and interactions between network functions may be represented by respective point-to-point reference points Ni, or as service-based interfaces.

In some aspects, as shown in fig. 1C, the service-based representation may 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 (a service-based interface exposed by AMF 132), nsmf 158I (a service-based interface exposed by SMF 136), nnef 158B (a service-based interface exposed by NEF 154), npcf 158D (a service-based interface exposed by PCF 148), nudm 158E (a service-based interface exposed by UDM 146), naf 158F (a service-based interface exposed by AF 150), nnrf 158C (a service-based interface exposed by NRF 156), nnssf 158A (a service-based interface exposed by NSSF 142), and Nausf 158G (a service-based interface exposed by AUSF 144). Other service-based interfaces not shown in figure 1C (e.g., nudr, N5g-eir, and Nudsf) may also be used.

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

Fig. 2 illustrates a block diagram of a communication device, in accordance with some embodiments. The communication device 200 may be a UE (e.g., a special purpose computer, a personal or notebook computer (PC), a tablet PC, or a smartphone), a dedicated network device (e.g., an eNB), server-running software that configures a server to operate as a network device, a virtual appliance, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. For example, the communication device 200 may be implemented as one or more of the devices shown in fig. 1A-1C. Note that communications described herein can be encoded prior to transmission by a transmitting entity (e.g., UE, gNB) for reception by a receiving entity (e.g., gNB, UE) and decoded after reception by the receiving entity.

Examples as described herein may include, or operate on, logic or several components, modules, or mechanisms. Modules and components are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner. In an example, the circuitry may be arranged as modules (e.g., internally or to an external entity, such as other circuitry) in a specified manner. In an example, all or portions of one or more computer systems (e.g., a stand-alone, client, or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) to operate to perform modules that specify operations. In an example, the software may reside on a machine-readable medium. In an example, software, when executed by underlying hardware of a module, causes the hardware to perform specified operations.

Thus, the term "module" (and "component") is understood to encompass a tangible entity, whether a physically constructed, specifically configured (e.g., hardwired) or temporarily (e.g., temporarily) configured (e.g., programmed) to operate in a specified manner or to perform a portion or all of any of the operations described herein. Considering the example where modules are temporarily configured, each module need not be instantiated at any one time. For example, where the modules include a general purpose hardware processor configured with software, the general purpose hardware processor may be configured as various different modules at different times. The software may accordingly configure the hardware processor to, for example, constitute one particular module at a time and to constitute different modules at different times.

The 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), a main memory 204 and a static memory 206, some or all of which may communicate with each other via an interconnect (e.g., bus) 208. The main memory 204 may include any or all of removable storage and non-removable storage, volatile memory or non-volatile memory. The 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 an example, the display unit 210, the input device 212, and the UI navigation device 214 may be a touch screen display. The communication device 200 may also include a storage device (e.g., 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, compass, accelerometer, or other sensor. The communication device 200 may also include an output controller, such as a 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., a printer, card reader, etc.).

The storage device 216 may include a non-transitory machine-readable medium 222 (hereinafter simply a machine-readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 224 may also reside, completely or at least partially, within the main memory 204, within static memory 206, and/or within the hardware processor 202 during execution thereof by the communication device 200. While the machine-readable medium 222 is shown to be a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 224.

The term "machine-readable medium" can include any medium that can store, encode or carry instructions for execution by communication device 200 and that cause communication device 200 to perform any one or more of the techniques of this disclosure, or that can store, encode or carry data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory, as well as optical and magnetic media. Specific examples of the machine-readable medium may include: non-volatile memories 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.

The instructions 224 may also be transmitted or received over a communication network using a transmission medium 226 via the network interface device 220 using any one of several Wireless Local Area Network (WLAN) transmission 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 a Local Area Network (LAN), a Wide Area Network (WAN), a packet data network (e.g., the internet), a mobile telephone network (e.g., a cellular network), a Plain Old Telephone (POTS) network, and a wireless data network. The communication over the network may include one or more different protocols, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards (referred to as Wi-Fi), the IEEE802.16 family of standards (referred to as WiMax), the IEEE 802.15.4 family of standards, the Long Term Evolution (LTE) family of standards, the Universal Mobile Telecommunications System (UMTS) family of standards, point-to-point (P2P) networks, the Next Generation (NG)/fifth generation (5G) standards, and so forth. In an example, the network interface device 220 may include one or more physical jacks (e.g., ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the transmission medium 226.

Note that the term "circuit" as used herein refers to, is part of, or includes a hardware component configured to provide the described functionality, e.g., an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a Field Programmable Device (FPD) (e.g., a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a Complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), a Digital Signal Processor (DSP), or the like. In some embodiments, circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuitry" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) and program code for performing the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

Thus, the term "processor circuit" or "processor" as used herein refers to, is part of, or includes the following circuitry: the circuit is 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 refer to one or more application processors, one or more baseband processors, physical Central Processing Units (CPUs), single or multi-core processors, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes).

Any of the radio links described herein may operate in accordance with any 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 rates for GSM evolution (EDGE) radio communication technology, and/or third generation partnership project (3 GPP) radio communication technologies, e.g., 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 (CDMA 2000), cellular Digital Packet Data (CDPD), mobitex, third generation (3G), circuit Switched Data (CSD), high Speed Circuit Switched Data (HSCSD), universal mobile telecommunications system (third generation) (UMTS (3G)), wideband code division multiple access (universal mobile telecommunications system) (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 multiple access (TD-CDMA), time division multiple access (TD-TD), synchronous multiple access (TD-TDD), third generation partnership project (rd generation partnership project) (3 rd generation partnership project version 8.11.11), 3 GPP) version (3.11.10.10.10.10.10.3 GPP) 3GPP rel.12 (3 rd generation partnership project version 12), 3GPP rel.13 (3 rd generation partnership project version 13), 3GPP rel.14 (3 rd generation partnership project version 14), 3GPP rel.15 (3 rd generation partnership project version 15), 3GPP rel.16 (3 rd generation partnership project version 16), 3GPP rel.17 (3 rd generation partnership project version 17), and subsequent versions (e.g., rel.18, rel.19, etc.), 3GPP 5G, 5G new radio (5G NR), 3GPP 5G new radio, 3GPP LTE extensions, LTE advanced specialization, LTE Licensed Assisted Access (LAA), muLTEfire, UMTS Terrestrial Radio Access (UTRA), evolved UMTS terrestrial radio access (E-UTRA), long term evolution advanced (fourth generation) (LTE advanced (4G)), cdmaOne (2G), code division multiple access 2000 (third generation) (CDMA 2000 (3G)), optimized evolution data or evolution data only (EV-DO), advanced mobile phone system (first generation) (AMPS (1G)), full access communication system/extended full access communication system (TACS/ETACS), digital AMPS (second generation) (D-AMPS (2G)), push-to-talk (PTT), mobile phone system (MTS), improved mobile phone system (IMTS), advanced mobile phone system (AMTS), norway ofish sentmobile phone (LTE), public mobile phone (MTD), or mobile phone system (swindy), swindy, emd), or swindy, public automated land mobile (Autotel/PALM), ARP (Autoadio Phone, "automotive cordless Phone"), NMT (Nordic Mobile Phone), high-volume versions of NTT (Japanese Telecommunications Phone) (Hicap), cellular Digital Packet Data (CDPD), mobitex, dataTAC, integrated digital enhanced network (iDEN), personal Digital Cellular (PDC), circuit Switched Data (CSD), personal Handyphone System (PHS), wideband Integrated digital enhanced network (WiDEN), iBurst, unlicensed mobile access (UMA, also known as the 3GPP Universal Access network or GAN standard), zigbee, bluetooth (r), the Wireless gigabit alliance (WiGig) standard, the Universal millimeter wave standard (Wireless systems operating at 10-300GHz and above, such as WiGig, IEEE 802.11ad, IEEE 802.11ay, etc.), technologies operating above the 300GHz and THz bands, (3 GPP/LTE based or IEEE 802.11p, or IEEE 802.11bd, among others) vehicle-to-vehicle (V2V) and vehicle-to-vehicle X (V2X) and vehicle-to-infrastructure (V2I) and infrastructure-to-vehicle (I2V) communication technologies, 3GPP cellular V2X, DSRC (dedicated short range communication) communication systems (e.g., smart transmission systems and others (typically operating at or above 5850MHz to 5925MHz (typically up to 35MHz, following the alteration recommendations in CEPT report 5971)), european ITS-G5 systems (i.e., the style of DSRC based on IEEE 802.11 p), including ITS-G5A (i.e., operating ITS-G5 in the following european ITS band), ITS band dedicated to security-related applications in the frequency range 5875GHz to 5905 GHz), ITS-G5B (i.e., operating in the european ITS band dedicated to ITS non-secure applications in the frequency range 5855GHz to 5875 GHz), ITS-G5C (i.e., operating ITS applications in the frequency range 5470GHz to 5725 GHz), DSRC in japan in the 700MHz band (including 715MHz to 725 MHz), IEEE 802.11bd based systems, and so forth.

The various aspects described herein may be used in the context of any spectrum management scheme, including dedicated licensed spectrum, unlicensed spectrum, license-exempt spectrum, (licensed) shared spectrum (e.g., licensed shared access in frequencies LSA =2.3-2.4GHz, 3.4-3.6GHz, 3.6-3.8GHz, and above, and spectrum access system in SAS =3.55-3.7GHz and above/CBRS =3.55-3.7GHz and above). Suitable spectrum bands include IMT (international mobile telecommunications) spectrum and other types of spectrum/frequency bands, such as frequency bands with national allocations (including 450-470MHz, 902-928MHz (note: e.g. allocated in US (FCC part 15)), 863-868.6MHz (note: allocated e.g. in the European Union (ETSI EN 300 220)), 915.9-929.7MHz (note: allocated e.g. in Japan), 917-923.5MHz (note: allocated e.g. in Korea), 755-779MHz and 779-787MHz (note: allocated e.g. in China), 790-960MHz, 1710-2025MHz, 2110-2200MHz, 2300-2400MHz, 2.4-2.4835GHz (note: it is an ISM band with global availability and used by the Wi-Fi technology series (11 b/g/n/ax) and Bluetooth), 2500-2690MHz, 698-790MHz, 610-790MHz, 3400-3600MHz, 3400-3800MHz, 3800-3800 MHz, 3.55-3.7GHz (note: allocated e.g.5 MHz in US), 698-790MHz, 610-790MHz, 3400-3600MHz, 3400-3800MHz, 3.7GHz (note: allocated e.g.5 GHz), a total frequency bands allocated e.5-5 GHz (note: 25-5 GHz), e.5 GHz) and 500U 5-595 GHz (note: 15.5 GHz) (allocated e.5 GHz), e.g.5 GHz), e.25-5 GHz), e.g. in EU), respectively), and EU-595 GHz (note: 10: 15-5 GHz (note: 15-5 GHz), e.5 GHz (note: 25-5 GHz), and EU), respectively), and EU-595 GHz (EU-595 GHz). The next generation of Wi-Fi systems are expected to include the 6GHz spectrum as the operating band, but it is worth noting that as of 12 months 2017, wi-Fi systems have not been allowed to be used in this band. The regulations are expected to be completed in 2019-2020, IMT advanced spectrum, IMT-2020 spectrum (expected to include 3600-3800MHz, 3800-4200MHz, 3.5GHz band, 700MHz band, bands in the range of 24.25-86GHz, etc.), spectrum available under the FCC's "spectrum front edge" 5G initiative (including 27.5-28.35GHz, 29.1-29.25GHz, 31-31.3GHz, 37-38.6GHz, 38.6-40GHz, 42-42.5GHz, 57-64GHz, 71-76GHz, 81-86GHz, and 92-94GHz, etc.), 5.9GHz (typically 5.85-5.925 GHz) and ITS (Intelligent transportation System) bands of 63-64 GHz), bands currently allocated to WiGigg (e.g 1 (57.24-59.40 GHz), gig 2 (59.40-3245 GHz band), and 3-3563 GHz bands (3532-354363), and Gig-36-3 GHz (354363-3532 GHz): this band has a near globally specified multi-gigabit wireless system (MGWS)/WiGig, with a total of 14GHz spectrum allocated in the US (FCC part 15), while EU (ETSI EN 302 567 and ETSI EN 301-217 for fixed P2P) allocates a total of 9GHz spectrum), a 70.2GHz-71GHz band, any band between 65.88GHz and 71GHz, the band currently allocated for vehicular radar applications (e.g., 76-81 GHz), and future bands (including 94-300GHz and above). Furthermore, the scheme can be used on an auxiliary basis of frequency bands such as the TV whitespace band (typically below 790 MHz), with 400MHz and 700MHz bands being promising candidates. In addition to cellular applications, specific applications in the vertical market may also be addressed, such as PMSE (program and special events), medical, health, surgical, automotive, low latency, unmanned, etc. applications.

Various aspects described herein may also enable hierarchical application of the schemes, such as by introducing hierarchical priorities of use for different types of users (e.g., low/medium/high priority, etc.) based on priority access to the spectrum, e.g., a 1 st user has the highest priority, followed by a2 nd user, followed by a 3 rd user, and so on.

The various aspects described herein may also be applied to different single carrier or OFDM types (CP-OFDM, SC-FDMA, SC-OFDM, filter bank based multi-carrier (FBMC), OFDMA, etc.) (in particular, 3GPP NR (new radio)) by allocating OFDM carrier data bit vectors to respective symbol resources.

Some features in this document are defined for the network side, e.g. AP, eNB, NR, or gNB, note that this term is typically used in the context of 3GPP fifth generation (5G) communication systems and the like. Nevertheless, the UE may also play this role and act as an AP, eNB or gNB; that is, some or all of the features defined for the network device may be implemented by the UE.

Edge computing is used for distributed computing, bringing computation and storage closer to a particular data source. The edge data network is a local data network. FIG. 3 illustrates an architecture for enabling edge applications, in accordance with some embodiments. The edge application server(s) and the edge enabler server are included in an edge data network. The edge configuration server provides configuration related to 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 an edge enabler client. The edge application server(s), edge enabler server and edge configuration server may interact with the 3GPP core network.

In order to use edge computing, various entities need to be authenticated and authorized. EDGE computing authentication and authorization includes EDGE computing EDGE-4 authentication and EDGE-1 reference point authentication and authorization. An EDGE Configuration Server (ECS) and an EDGE Enabler Client (EEC) need to be successfully loaded before initiating EDGE-1 or EDGE-4 authenticated and authorized security flows.

Further, each EDGE reference point enables different interactions according to 3gpp TS 23.558. The EDGE-6 reference point enables interaction between the EDGE configuration server and the EDGE enabler server. EDGE-6 supports registration and registration updates of EDGE enabler server information to the EDGE enabler network configuration server, as well as de-registration. The edge enabler server registration process allows the edge enabler server to provide information to the edge configuration server to request use of its edge configuration functions. The edge enabler server registration update procedure allows the edge enabler server to update the edge configuration server if information at the edge enabler server has changed. The edge enabler server removes its information from the edge configuration server using an edge enabler server de-registration procedure.

The edge configuration server may be deployed in a Mobile Network Operator (MNO) domain, or may also be deployed by a service provider in a third party domain, where one edge enabler client may communicate with one or more edge configuration servers at the same time. An EDGE enabler server may be simultaneously connected to one or more EDGE configuration servers through a single EDGE-6 reference point interface. An edge enabler server configured with multiple edge configuration server endpoint addresses may perform service registration, update, or deregistration procedures multiple times per edge configuration server. In this context, the security context of each EDGE-6 interface will be separate from each other, as the trust domains may be different.

Safety problem

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

A registration update without any confidentiality or integrity may help a broker to emulate an edge configuration server to the edge enabler server, exposing and possibly modifying registration updates with fake edge enabler server configuration files to the edge configuration server. Furthermore, the attack may also result in exposing topology details and server information within the PLMN domain. Malicious actors can use this exposed information to conspire a competitor of the PLMN or edge computing service provider.

Edge-6 security

Confidentiality and integrity protection should be supported for transport messages and data on the EDGE-6 reference point. Message transmissions on the EDGE-6 reference point will be protected from replay attacks.

The edge configuration server will be able to authenticate the edge enabler server to register and update server profile information. The edge configuration server will be able to authorize the edge enabler server to register and update server profile information.

Similarly, the EDGE-3 reference point enables interaction between the EDGE enabler server and the EDGE application server. As with EDGE-6, EDGE-3 supports registration and registration updates of EDGE application server information to the EDGE enabler server, as well as de-registration. An EDGE application server can simultaneously connect to one or more EDGE enabler servers through a single EDGE-3 reference point interface. In this context, the security context of each EDGE-3 interface will be separate from each other, as the trust domains may be different.

Edge-3 security

Confidentiality and integrity protection should be supported for transport messages and data on the EDGE-3 reference point. Message transmissions on the EDGE-3 reference point will be protected from replay attacks.

The load flow begins with the Edge enabler client establishing a Transport Layer Security (TLS) connection to the Edge configuration server over the Edge-4 interface. A successful TLS setup gives the Edge provisioning server an opportunity to transmit Edge-1 Edge enabler server authentication and authorization information to the Edge enabler client. After the Edge-1 Edge enabler server authentication and authorization information is transmitted to the Edge enabler client, the TLS session is released and the Edge-4 security flow ends.

In more detail, 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 establish a secure session using TLS. The TLS implementation and security profile used follow the specifications in TS33.310, annex E.

After establishing the 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 a load credential, which may be an OAuth 2.0 access token, obtained during provisioning of the load registration information. When using OAuth 2.0 token based mechanisms as loading credentials, the access token is encoded as a JavaScript object notation (JSON) web token specified in Internet Engineering Task Force (IETF) request for comments (RFC) 7519, including JSON web signatures specified in IETF RFC 7515 and verified according to OAuth 2.0, IETF RFC 7519, and IETF RFC 7515. Other credentials (e.g., message digest) may also be used.

Figure 4 illustrates a security process for edge enabler client loading according to some embodiments. Authentication credentials based on OAuth 2.0 tokens are shown in fig. 4.

As shown in fig. 4, in operation 1, an edge enabler client obtains load registration information from an edge computing service provider domain as a prerequisite to the load process. The load registration information is used to authenticate and establish secure TLS communications 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 includes the load credential (OAuth 2.0 access token).

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 establishes a TLS session with the edge configuration server using the registration information obtained in operation 1.

In operation 3, after successfully establishing the TLS session, the edge enabler client sends a load edge enabler client request message to the edge configuration server along with the enrollment credentials (OAuth 2.0 access token). The edge enabler client generates a key pair private key, public key, and provides the public key and loads the edge enabler client request.

In operation 4, the edge provisioning server verifies the enrollment credential (OAuth 2.0 access token). If the verification of the credential (OAuth 2.0 access token in fig. 4) is successful, the edge configuration server generates a configuration file for the edge enabler client specified in TS 23.558, which may include the 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 the certificate of the edge enabler client by itself for the assigned edge enabler client identity and public key. The certificate is used by the edge enabler client for subsequent authentication procedures with the edge configuration server and may be used to establish secure connections and authentication with the edge enabler server. The edge configuration server may optionally generate the onbroadcasting _ Secret _ token. The onbroadcasting _ Secret _ token value remains unchanged for the lifetime of the load and is bound to the edge enabler client ID specific to the edge configuration server.

When the client certificate of the edge enabler client is issued by a third party, then 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, the edge configuration server includes the provided certificate in the configuration file of the edge enabler client in operation 4. The decision of whether to accept a client certificate issued by a third party is made by the edge computing service provider domain policy.

In operation 5, the edge configuration server responds with a load edge enabler client response message. The response includes the edge enabler client ID assigned by the edge configuration server, the edge enabler server authentication and authorization information (if generated in operation 4), the credentials of the edge enabler client, and the edge enabler client onkeying _ Secret _ token (if generated by the edge configuration server).

Referring again to fig. 3, the edge-1 reference point enables interaction between the edge enabler server and the edge enabler client. The EDGE-1 reference point supports registration and de-registration of EDGE enabler clients to EDGE enabler servers, acquisition and provisioning of EDGE application server configuration information, and discovery of available EDGE application servers in EDGE data networks.

The EDGE application server provides functionality, such as provisioning of configuration information, and supports the functionality of application context transfer for the EDGE enabler client over the EDGE-1 reference point. The edge enabler client performs functions such as obtaining configuration information from the edge enabler server and discovering available edge application servers in the edge data network. The edge application server(s) and the edge enabler server are included in an edge data network.

The UE is initially provisioned with a configuration to connect to the edge data network. At initial provisioning, the edge enabler client of the UE registers with the selected edge enabler server(s) in the list of provisioned edge enabler server(s). The edge enabler client uses services provided by the edge enabler server, for example, to discover edge application servers in an area of interest. The process enables initialization or updating of edge enabler client context information at the edge enabler server. The edge enabler client sends an edge enabler client registration request to the edge enabler server. Edge application server discovery enables edge enabler clients to obtain information about available edge application servers of interest. The identification of the edge application server is based on matching a query filter or application client profile provided in the request.

Safety problem

When using any registration, discovery, provisioning, de-registration without authorization, a malicious edge enabler client receives service lists and topology within the edge data network from the edge enabler server discovery response message or provisioning response message. The received information may indicate a topology of the edge data network (e.g., uniform Resource Identifier (URI), internet Protocol (IP) address, number of edge application servers, application server functionality, API type, protocol). Malicious edge enabler clients may use this information to launch attacks on the edge data network or use it for competitive reasons. Furthermore, message transmission on the EDGE-1 interface should be protected from replay attacks, man-in-the-middle (MITM) attacks, and disputes to messages should be prohibited.

Safety provisions

The EDGE enabler server can provide mutual authentication with the EDGE enabler client over the EDGE-1 interface.

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

Message transmissions on the EDGE-1 reference point are integrity protected.

Message transmissions on the EDGE-1 reference point are protected from replay attacks.

Message transmissions on the EDGE-1 reference point are confidentiality protected.

EDGE4: problem of protecting EDGE-4 interface

Details of

The EDGE-4 reference point enables interaction between the EDGE configuration server and the EDGE enabler client. The edge configuration server provides support functions for the edge enabler client to interface with the edge enabler server. The EDGE-4 reference point supports the provisioning of EDGE configuration information (e.g., URI or LADN service information) to EDGE enabler clients. The EDGE enabler client performs functions such as acquisition from configuration information of the EDGE configuration server over the EDGE-4 interface.

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

Safety problem

If access to provisioning and configuration information is obtained without authentication and authorization, a malicious edge enabler client may receive the list of edge enabler server configuration information and topology within the edge data network from the provisioning response message. The received information may show the topology of the edge data network (e.g., URI, fully Qualified Domain Name (FQDN), IP address, local Area Data Network (LADN) service information, application server function, application Programming Interface (API) type, protocol).

Using the different edge deployment models described above, the edge configuration server should be able to hide topology and provisioning information between each application's trust domain. Without this access control and hidden topology, a malicious application client can access other edge enabler servers and edge application servers. Malicious edge enabler clients may use this information to launch attacks on edge data networks or use this information for competitive reasons. Furthermore, message transmissions on EDGE-4 should be protected from replay attacks, MITM attacks, and disputes to messages should be prohibited.

Other security

The edge4 is safe: confidentiality and integrity protection should be supported for transport messages and data on the EDGE-4 reference point.

An edge configuration server: the EDGE configuration server can provide mutual authentication with the EDGE enabler client over the EDGE-4 interface. The edge configuration server can determine whether the edge enabler client is authorized to access the provisioning service provided by the edge configuration server. The edge configuration server is able to hide the topology details between the trust domains of each application client.

Safety procedures for EDGE-4 reference points

TLS is used to provide integrity protection, replay protection, and confidentiality protection. Support for TLS is mandatory or, alternatively, used according to the policies of the domain administrator to protect interfaces within the trusted domain. Unless security of the EDGE-4 reference point is provided by other means, the following procedure can be followed.

Safety procedures for EDGE-4 reference points

Authentication and authorization

SUMMARY

For authentication of the EDGE-4 reference point, TLS is used to perform client and server certificate based mutual authentication between the EDGE configuration server and the EDGE enabler client.

Certificate-based authentication complies with the profiles given in 3GPP TS33.310, subclauses 6.1.3a and 6.1.4a. The structure of the Public Key Infrastructure (PKI) for certificates is beyond the scope of this document.

TLS is used to provide integrity protection, replay protection, and confidentiality protection for EDGE-4 interfaces. Support for TLS over the EDGE-4 interface is mandatory. The TLS implementation and security profile used follow the specifications in TS33.310, annex E.

Security method negotiation

The EDGE enabler client and the EDGE configuration server negotiate a security method used by the EDGE enabler client and the EDGE enabler server for EDGE-1 interface authentication and protection. After successful mutual authentication on the EDGE-4 interface, the EDGE configuration server selects a security method based on the EDGE enabler server function and sends the selected security method to the EDGE enabler client along with the EDGE enabler client's authentication information at the EDGE enabler server. Such information can include the time of validity of the EDGE-1 credential. This is depicted in fig. 5, where fig. 5 illustrates the selection of a security method for use in an EDGE-1 reference point, in accordance with some embodiments.

A prerequisite of the method of fig. 5 comprises the edge enabler client loading to the edge configuration server. In fig. 5, in operation 1, TLS is used to establish mutual authentication between an edge enabler client and an edge configuration server based on client and server certificates. The client certificate provided to the edge enabler client due to successful loading is used.

In operation 2, the EDGE enabler client may send EDGE-1 security capability information to the EDGE configuration server in a security method request message indicating a list of security methods supported by the EDGE enabler client on an EDGE-1 reference point for each EDGE enabler server.

In operation 3, the EDGE configuration server selects a security method to be used on the EDGE-1 reference point for each requested EDGE enabler server while considering information from the EDGE enabler client, access scenarios and EDGE enabler server functions in operation 2.

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, and any security information related to the security method. The EDGE enabler client uses this method in subsequent communication setup with the EDGE enabler server over the EDGE-1 reference point.

1.1.3 service and method discovery

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

1.1.4 topology hiding

In 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 a topology hiding entity.

Safety procedures for EDGE-1 reference points

TLS is used to provide integrity protection, replay protection, and confidentiality protection. Support for TLS is mandatory or, alternatively, used according to the policies of the domain administrator to protect interfaces within the trusted domain.

Safety procedures for EDGE-1 reference points

SUMMARY

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

Authentication and authorization

Method 1-use of TLS-PSK

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 pre-shared keys for authenticating EDGE-1 TLS connections. It is assumed that both the edge enabler client and the edge configuration server are pre-provisioned with certificates. The TLS configuration file specified in annex E of TS33.310 is used.

Figure 6 illustrates EDGE-1 interface authentication and protection using TLS-PSK in accordance with some embodiments. Figure 6 details the message flow between an EDGE enabler client, an EDGE configuration server and an EDGE enabler server to establish a secure EDGE-1 interface using a pre-shared key for authentication.

In operation 1, an EDGE-4 authentication and secure session is established as described above. Edge configuration server provided key EES _PSK The valid timer value of (a).

In operation 2, after successfully establishing TLS on EDGE-4, the EDGEEnabler client and edge configuration server obtaining key EES _PSK . Secret key EES _PSK Bound to an edge enabler server. Edge enabler client and edge configuration server start-up key EES _PSK The validity timer of (1).

In operation 3, the edge enabler client transmits an authentication initiation request including an edge enabler client ID allocated by the edge configuration server to the edge enabler server. If the edge enabler client already has a valid key EES _PSK Then

operations

1 and 2 in the process may be skipped. In this case, the edge enabler client starts the process at operation 3.

In operation 4A, if the edge enabler server does not have a valid key, the edge enabler server requests security information from the edge configuration server to perform authentication and secure interface establishment with the edge enabler client. In operation 4B, the EDGE configuration server provides security information (TLS-PSK: EES) related to the selected security method to the EDGE enabler server over an EDGE-6 reference point _PSK ). Edge configuration server provided key EES _PSK The remaining valid timer value.

In operation 5, related security information (EES) for authentication is acquired _PSK ) Thereafter, the edge enabler server sends an authentication initiation response message to the edge enabler client to initiate the TLS session setup. The edge enabler server starts the validity timer according to the value received from the edge configuration server in operation 4.

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 through EDGE-1.

After successfully establishing TLS over the EDGE-1 reference point, the EDGE enabler server authorizes the service API call request of the EDGE enabler client according to the authorization information obtained from the EDGE configuration server.

Method 2-Using PKI

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 according to certificate-based mutual authentication. It is assumed that both the edge enabler client and the edge enabler server are pre-provisioned with certificates.

Figure 7 illustrates EDGE-1 interface authentication and protection using certificate-based mutual authentication, in accordance with some embodiments. Fig. 7 details the message flow between the edge enabler client, the edge configuration server and the edge enabler server in relation to the security method.

In operation 1, an edge enabler client sends an authentication initiation request to an edge enabler server. The request includes an edge enabler client ID.

In operation 2A, the edge enabler server requests security information from the edge configuration server to perform authentication and secure interface establishment 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 over 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 certificate of the edge enabler client.

In operation 3, after acquiring 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 setup procedure.

In operation 4, the EDGE enabler client and the EDGE enabler server perform mutual authentication using the certificate and establish the TLS session over EDGE-1. Certificate-based authentication complies with the profiles given in 3gpp TS33.310, clauses 6.1.3a, and 6.1.4a.

Method 3-TLS with OAuth token

The method details the establishment of a secure channel over EDGE-4, EDGE-1 reference points and grants the EDGE enabler client's service request to the EDGE enabler server using OAuth 2.0 token based mechanisms. Figure 8 illustrates EDGE-1 interface authentication and protection using an access token, in accordance with some embodiments. Figure 8 details the flow of security information between the edge enabler client, the edge configuration server and the edge enabler server. It is assumed that the edge enabler client, the edge configuration server and the edge enabler server are all pre-provisioned with appropriate credentials and related information to establish a secure session.

According to OAuth 2.0, the edge configuration server executes functions of authorization and token protocol end points; the edge enabler client performs the functions of the resource owner, client and redirect endpoint, while the edge enabler server performs the resource server functions. The edge enabler client (client endpoint) is registered as a confidential client type, with the authorization grant type being "client credentials".

In operation 1, EDGE-4 authentication and secure session establishment are performed as described above.

In operation 2, after successfully establishing a TLS session on EDGE-4, the EDGE enabler client sends an access token request message to the EDGE configuration server according to the OAuth 2.0 specification, as described in clause 1.1 of this document.

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

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 an access token response message.

Operations 1 through 4 of fig. 8 may be skipped if the edge enabler client already has a valid OAuth access token. In this case, the edge enabler client starts 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 in the OAuth access token request message for the edge configuration server to validate the access token request.

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 (EDGE enabler server) side certificate authentication or certificate-based mutual authentication.

Before establishing the TLS session, the following steps are performed:

the edge enabler client sends an authentication initiation request to the edge enabler server. The request includes an edge enabler client ID.

The edge enabler server requests security information from the edge configuration server to perform authentication and security interface establishment 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 OAuth token) over the 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 certificate of the edge enabler client.

After obtaining 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 procedure.

In operation 6, the EDGE enabler client initiates other procedures, such as registration, discovery, deregistration with the EDGE enabler server, by successfully authenticating with the EDGE enabler server on EDGE-1. An access token is sent with these methods.

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 edge enabler client's service request against the authorization claim in the access token to ensure that the edge enabler client has access to the requested service.

In operation 8, the edge enabler server transmits a response to the request from the edge enabler client at operation 6.

FIG. 9 illustrates a security process for edge application server loading according to some embodiments. Authentication credentials based on OAuth 2.0 tokens are shown in fig. 9.

As shown in fig. 9, in operation 1, the edge application server obtains load registration information from the edge computing service provider domain as a prerequisite to the load process. The load registration information is used to authenticate and establish secure TLS communications 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 includes the load credential (OAuth 2.0 access token).

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 establishes a TLS session with the edge enabler server using the registration information obtained in operation 1.

In operation 3, after successfully establishing the TLS session, the edge application server sends a load edge application server request message to the edge enabler server along with the enrollment credential (OAuth 2.0 access token). The edge application server generates a key pair private key, public key, and provides the public key and a load edge application server request.

In operation 4, the edge enabler server verifies the enrollment credential (OAuth 2.0 access token). If the verification of the credential (OAuth 2.0 access token in fig. 9) is successful, the edge enabler server generates a configuration file for the edge application server 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 the certificate of the edge application server itself for the assigned edge application server identity and public key. The certificate is used by the edge application server for subsequent authentication procedures with the edge enabler server and may be used to establish secure connections and authentication with the edge application server. The edge enabler server may optionally generate the Onboarding _ Secret _ token. The Onboarding _ Secret _ token value remains unchanged for the lifetime of the load and is bound to the edge application server ID specific to the edge enabler server.

When the client certificate of the edge application server is issued by a third party, then in operation 3 the edge application server may additionally include the certificate in the load edge application server request message. If the edge enabler server trusts the issuer of the client certificate of the edge application server, the edge enabler server includes the provided certificate in the configuration file of the edge application server in operation 4. The decision of whether to accept a client certificate issued by a third party is made by the edge computing service provider domain policy.

In operation 5, the edge enabler server responds with a load edge application server response message. 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 certificate of the edge application server, and the edge application server requesting _ Secret _ token (if generated by the edge enabler server).

The Onboarding _ Secret _ token may bind to events received from an application client on the UE. These events may be, for example, UE configuration, or user approval to access a particular API. In one example, an EDGE application server may request access to the location of a UE by sending a request to an EDGE enabler server, which in turn may contact a 3GPP core network over an EDGE-2 interface. To grant such a request, the edge enabler server checks for an onboardingsecret token that may be bound to the UE for user permission to make such access by the edge application server (in the above example, to access the UE's own location). After a permission-related yes/no indication (whether bound to the on keying _ secret _ token or for generating a token in the token generation function), the edge enabler server may validate the token received from the edge application server for the user to confirm such access, and may then proceed to access the location according to the procedure in TS 23.558.

The token binding algorithm computes the token signature using a byte string that represents a concatenation of: the tokenbinding type value contained in the tokenbinding. Tokenbinding _ type field, which is "user configuration parameters" and "type of service requested, e.g. location service"), the tokenbinding keyparameters value contained in the tokenbinding id. Key _ parameters field, which is "value of user configuration parameters, e.g. yes/no"), and the derived key Material (EKM) value obtained from the current TLS connection. The tokenbindkeyparameters value may be checked first, and if the tokenbindkeyparameters value indicates yes for the service, the tokenbinding _ type value may be checked.

Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the disclosure. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This detailed description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

The subject matter may be referred to herein, individually and/or collectively, by the term "embodiment" merely for convenience and without intending to voluntarily limit the scope of this application to any single inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instances or uses 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 "including" and "in which" are used as plain-english equivalents of the respective terms "comprising" and "wherein. Also, in the appended claims, the terms "include" and "comprise" are open-ended, that is, a system, UE, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim is considered to fall within the scope of that claim. In addition, 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.

The abstract of the present disclosure is provided to comply with 37c.f.r.1.72 (b), which requires an abstract that allows the reader to quickly ascertain the nature of the technical disclosure. Digest is submitted under the following understanding: it is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims

1. An apparatus for an edge device, the apparatus comprising:

a processing circuit configured to:

decoding load registration information from an edge computing service provider domain, the load registration information including a registration credential;

establishing a secure session with another edge device based on Transport Layer Security (TLS) using the load registration information;

after successfully establishing the TLS session, encoding a load edge request message with the enrollment credentials for transmission to the other edge device; and

decoding a load edge response message from the other edge device in response to transmitting the load edge request message; and

a memory configured to store the registration information.

2. The apparatus of claim 1, wherein:

the processing circuitry is further configured to generate a public key and a private key pair, and

the load edge request includes the public key.

3. The apparatus of claim 2, wherein:

the load registration information further includes an address of the other edge device and a root Certificate Authority (CA) certificate,

the enrollment credential includes an OAuth 2.0 access token, and

the load edge request message includes the OAuth 2.0 access token.

4. The apparatus of claim 1, wherein the load edge response message includes an edge Identifier (ID) assigned by an edge device, an edge certificate, and if generated by the other edge device, edge authentication and authorization information, and an edge onboardingsecret token.

5. The apparatus of claim 1, wherein:

the processing circuitry is further configured to decode an edge certificate from a third party issuer, and

the load edge request message includes the edge certificate.

6. The apparatus of claim 1, wherein the edge device is an edge enabler client and the another edge device is an edge configuration server.

7. The apparatus of claim 1, wherein the edge device is an edge application server and the another edge device is an edge enabler server.

8. The apparatus of claim 7, wherein the load edge response message comprises an edge onboardingsecret token bound to an event received from an edge application client on a User Equipment (UE) that includes the edge application client.

9. The apparatus of claim 8, wherein the event comprises a UE configuration or a UE approval for accessing a particular Application Programming Interface (API).

10. The apparatus of claim 8, wherein the processing circuitry is further configured to encode, for transmission to the edge enabler server, a request to access a location of the UE to be authorized using an onboardingsecretpoken bound to a UE permission to access the location by the edge application server.

11. The apparatus of claim 10, wherein:

the token signature of the Onboarding _ Secret _ token is computed by a token binding algorithm using a string of bytes representing a concatenation of: a TokenBindingType value contained in a TokenBindingID.key _ parameters field, a TokenBindingKeyParameters value contained in a TokenBindingID.key _ parameters field, and a derived Key Material (EKM) value obtained from the current TLS connection,

the TokenBindingType value is selected from a user configuration parameter and a requested service type, and

the tokenBindingKeyParameters value is a value of a user configuration parameter.

12. An apparatus for an edge enabler client, the apparatus comprising:

a processing circuit configured to:

performing mutual authentication with the edge configuration server based on the client and server certificates using Transport Layer Security (TLS);

encoding EDGE-1 security capability information in a security method request message for transmission to the EDGE configuration server, the EDGE-1 security capability information indicating a list of security methods supported by the EDGE enabler client on an EDGE-1 reference point for each of a plurality of EDGE enabler servers; and

decoding a security method response message from the EDGE configuration server indicating, for each EDGE enabler server, a security method selected by the EDGE configuration server for use on an EDGE-1 reference point of each EDGE enabler server and security information related to the security method; and

a memory configured to store the security method of each edge enabler server.

13. The apparatus of claim 12, wherein the processing circuit is further configured to encode an edge enabler client Identifier (ID) for transmission to the edge configuration server, the edge enabler client ID to determine whether the edge enabler client is authorized to perform discovery based on a discovery policy.

14. The apparatus of claim 12, wherein the processing circuit is further configured to:

decoding a valid timer value for a key bound to a particular edge enabler server from the edge configuration server,

deriving the key after establishing a TLS session with the EDGE configuration server at an EDGE-4 reference point,

a validity timer for the key is started and,

encoding an authentication initiation request for transmission to the particular edge enabler server, the authentication initiation request including an edge enabler client Identifier (ID) assigned by an edge configuration server,

decoding an authentication initiation response message from the particular edge enabler server before the validity timer expires, the authentication initiation response message to initiate a TLS session setup with the particular edge enabler server in response to the particular edge enabler server obtaining security information of the edge enabler client from the edge configuration server, the security information including the key and the remaining time of the validity timer, and

using the key to perform mutual authentication with the particular EDGE enabler server and establish a TLS session with the particular EDGE enabler server over the EDGE-1 reference point.

15. The apparatus of claim 12, wherein the processing circuitry is further configured to:

encoding an authentication initiation request for transmission to a particular edge enabler server, the authentication initiation request including an edge enabler client Identifier (ID),

decoding a certification initiation response message from the particular edge enabler server, the certification initiation response message for initiating a TLS session setup with the particular edge enabler server in response to the particular edge enabler server obtaining security information of the edge enabler client from the edge configuration server and verifying the edge enabler client based on the security information, the security information relating to a transport layer secure pre-shared key cipher suite (TLS-PSK) and a root Certificate Authority (CA) certificate using the edge enabler client, and

performing mutual authentication with the particular EDGE enabler server using the root CA certificates of the EDGE enabler client and the particular EDGE enabler server, and establishing a TLS session with the particular EDGE enabler server over the EDGE-1 reference point.

16. The apparatus of claim 12, wherein the processing circuitry is further configured to:

encoding an access token request message for transmission to the EDGE configuration server after establishing a TLS session with the EDGE configuration server at an EDGE-4 reference point,

in response to verification of the access token request message by the edge configuration server, decoding an access token response message from the edge configuration server containing an access token for access permissions of the edge enabler client for one or more services,

establishing a TLS session with a particular edge enabler server according to certificate authentication or certificate-based mutual authentication as directed by the edge configuration server,

after establishing a TLS session with the particular EDGE enabler server, invoking one or more procedures with the particular EDGE enabler server over an EDGE-1 reference point by transmitting a service request including the access token and requested service, the one or more procedures selected from registering, discovering, and deregistering, and

decoding a service response from the particular edge enabler server in response to verifying the access token by verifying an edge configuration server signature and verifying the service request against an authorization claim for access permissions to the requested service in the access token, the service response including a response to executing the requested service.

17. The apparatus of claim 16, wherein prior to establishing the TLS session with the edge enabler server, the processing circuitry is further configured to:

encoding an authentication initiation request for transmission to the particular edge enabler server, the authentication initiation request including an edge enabler client Identifier (ID), and

decoding an authentication initiation response message from the particular edge enabler server in response to authentication of the edge enabler client according to security information of the security method selected by the edge enabler client and verification of a root Certificate Authority (CA) certificate of the edge enabler client, the authentication initiation response message for initiating establishment of the TLS session with the edge enabler server.

18. The apparatus of claim 16, wherein the access token request message comprises an edge enabler client Identifier (ID) and an Onboard _ Secret _ token assigned by an edge configuration server for authenticating the access token request message.

19. A non-transitory computer-readable storage medium storing instructions for execution by one or more processors of an edge enabler client, which when executed, configure the edge enabler client to:

establishing a secure session with an edge configuration server based on Transport Layer Security (TLS) using the load registration information;

after successfully establishing a TLS session, encoding a load edge request message with the enrollment credentials for transmission to the edge provisioning server; and

decoding a load edge response message from the edge configuration server in response to transmitting the load edge request message.

20. The medium of claim 19, wherein:

the one or more processors further configure the edge enabler client to generate a public key and private key pair when the instructions are executed,

the load edge request includes the public key,

the load registration information further includes an address of another edge device and a root Certificate Authority (CA) certificate,

the enrollment credential includes an OAuth 2.0 access token, and

the load edge request message includes the OAuth 2.0 access token.