Methods and network devices for supporting ran capabilities exposure

Abstract

This disclosure is generally directed to wireless communication and is specifically directed to methods and network devices for supporting Radio Access Network (RAN) capabilities exposure. For example, a first node configured to perform a RAN Exposure Function (REF) receives, from a second node, a first message comprising a request for a REF-related operation and transmits, to at least one of the second node or a third node, a second message containing result information on the request.

Description

METHODS AND NETWORK DEVICES FOR SUPPORTING RAN CAPABILITIES EXPOSURETECHNICAL FIELD

[0001] This disclosure is generally directed to wireless communication and is specifically directed to methods and network devices for supporting Radio Access Network (RAN) capabilities exposure.BACKGROUND

[0002] Current network exposure technologies primarily use the Network Exposure Function (NEF) , which has been utilized in fifth-generation (5G) cellular networks to expose information such as location services, traffic management, and other network resources to external applications. NEF provides secure access to network resources through API interfaces, authentication, and authorization mechanisms.SUMMARY

[0003] This disclosure is generally directed to wireless communication and is specifically directed to methods and network devices for supporting Radio Access Network (RAN) capabilities exposure. For example, a first node configured to perform a RAN Exposure Function (REF) receives, from at least one of a second node or a third node, a first message comprising a request for a REF-related operation and transmits, to at least one of the second node or the third node, a second message containing result information on the request.

[0004] In the example implementations above, the request includes at least one of the following: a registration request for registering one of the second node or the third node with the first node, a deregistration request for deregistering the second node from the first node, an onboarding request for onboarding the second node with the first node, an offboarding request for offboarding the second node from the first node, a first authentication request for authenticating the second node with the first node, a second authentication request for facilitating authentication between the second node and the third node, a first authorization request for obtaining authorization to the second node to access the third node, and / or a revoke authorization request for revoking authorization for RAN exposure API of the second node.

[0005] In any one of the example implementations above the second node includes at least one of a consumer node or a Network Exposure Function (NEF) , and / or the third node includes a RAN node.

[0006] In any one of the example implementations above, in response to receiving the registration request from the second node, where the registration request includes registration information, the first node determines, based on the registration information, whether to register the one of the second node or the third node and / or stores the registration information.

[0007] In any one of the example implementations above, the registration information includes at least one of: an ID of the first node, an ID of the second node or the third node, a name of the second node, application service information, query information associated with application programming interface (API) exposure of the third node, and / or security information to authenticate and verify the registration request.

[0008] In any one of the example implementations above, transmitting the second message includes transmitting a registration response to the second node that includes at least one of: an ID of the first node, an ID of the second node or the third node, a name of the second node, a registration result, a registration reason if registering the one of the second node or the third node is unsuccessful, and / or security information associated with subsequent event or information exposure subscriptions of the second node.

[0009] In any one of the example implementations above, in response to receiving the onboarding request from the second node, the first node: checks whether information sent by the second node is complete, creates a configuration profile for the second node, and / or saves the created configuration profile.

[0010] In any one of the example implementations above, the onboarding request includes at least one of: onboarding information including an application name, an application type, a purpose description, and / or an expected access frequency; information used for authentication including credentials for identity verification; information used for authorization including a list or categories of APIs that the second node wishes to access, and / or regions of requested APIs; network slicing information; query information associated with API exposure of the third node; and / or a suggested expiration time for the onboarding.

[0011] In any one of the example implementations above, the configuration profile includes at least one of: an assigned ID of the second node which is assigned to the second node by the first node, detailed onboarding information, detailed authentication information, detailed authorization information, a list and categories of RAN exposure APIs that the second node wishes to access, regions of requested APIs, and / or access control policies based on network slicing requirements.

[0012] In any one of the example implementations above, transmitting the second message includes transmitting an onboarding response to the second node that includes at least one of: an onboarding status, authorization information including an authorization token, a privilege level, a list or categories of accessible APIs, a reason for failure if the onboarding is unsuccessful, an expiration time for the onboarding, a strategy for network slicing, an assigned ID of the second node which is assigned to the second node by the first node, and / or authentication information.

[0013] In any one of the example implementations above, in response to receiving the authentication request from the second node, the first node verifies an identity of the second node based on a configuration profile and / or authenticates the second node.

[0014] In any one of the example implementations above, the authentication request includes at least one of: an ID of the first node, an assigned ID of the second node which is assigned to the second node by the first node, and / or credentials for authentication of the second node.

[0015] In any one of the example implementations above, transmitting the second message includes transmitting an authentication response to the second node that includes at least one of: an authentication result, credentials for authentication of the second node, an ID of the first node, and / or an assigned ID of the second node which is assigned to the second node by the first node.

[0016] In any one of the example implementations above, in response to receiving the second authentication request, the first node retrieves a configuration profile for the second node, and transmitting the second message includes transmitting an information response to the third node, where the information response includes the retrieved configuration profile of the second node.

[0017] In any one of the example implementations above, in response to receiving the first authorization request from the second node to request authorization information for the second node to access the third node, the first node: verifies an identity of the second node based on the previously stored configuration profile of the second node, transmits the configuration profile and a second authorization request to the third node in response to successfully verifying the identity of the second node, and / or receives a first authorization response from the third node containing generated authorization information.

[0018] In any one of the example implementations above, the first authorization request includes at least one of: an ID of the first node, an assigned ID of the second node which is assigned to the second node by the first node, an ID of the third node, query information associated with API exposure of the third node, and / or credentials for authentication of the second node.

[0019] In any one of the example implementations above, transmitting the second message includes transmitting a second authorization response to the second node that includes at least one of: an ID of the first node, an assigned ID of the second node which is assigned to the second node by the first node, an ID of the third node, and / or authorization information for the second node to invoke an API in subsequent operations.

[0020] In any one of the example implementations above, the second authorization request includes at least one of: an ID of the first node, an assigned ID of the second node which is assigned to the second node by the first node, an ID of the third node, query information associated with API exposure of the third node, a profile associated with the second node, and / or credentials for authentication of the second node.

[0021] In any one of the example implementations above, the first authorization response includes at least one of: an ID of the first node, an assigned ID of the second node which is assigned to the second node by the first node, an ID of the third node, and / or authorization information for the second node to invoke an application programming interface (API) in subsequent operations.

[0022] In any one of the example implementations above, in response to receiving the revoke authorization request from the third node, the first node invalidates authorization of an API exposure of the third node to the second node.

[0023] In any one of the example implementations above, the revoke authorization request includes at least one of: an ID of the first node, an assigned ID of the second node which is assigned to the second node by the first node, an ID of the third node, information associated with the API exposure of the third node, and / or a revocation reason.

[0024] In any one of the example implementations above, transmitting the second message includes transmitting a revoke authorization notification to the second node that includes at least one of: an ID of the first node, an assigned ID of the second node which is assigned to the second node by the first node, an ID of the third node, and / or a revocation result.

[0025] In any one of the example implementations above, in response to receiving the offboarding request from the second node, the offboarding request including an ID of the first node, an ID of the second node, and / or an offboarding reason, the first node: cancels registration of the second node with the first node, where the second node is no longer considered an authenticated user of the first node. Transmitting the second message includes transmitting an offboarding response to the second node that includes an offboarding result.

[0026] In any one of the example implementations above, in response to receiving the deregistration request from the second node, the deregistration request including security information used by the first node to verify the deregistration request, the first node: verifies the deregistration request and / or cancels registration of the second node with the first node, where the second node is no longer considered an authenticated user of the first node. Transmitting the second message includes transmitting a deregistration response to the second node that informs the second node of a deregistration result.

[0027] In some other example implementations, methods performed by the second node or third node above corresponding to the methods above are further disclosed.

[0028] In some other implementations, a wireless communication apparatus (e.g., a wireless communication device or wireless communication node) comprising at least one a processor and a memory is disclosed. The at least one processor may be configured to read computer code from the memory to implement any one of the methods above.

[0029] In yet some other implementations, a non-transitory computer-readable storage medium for storing computer code (i.e., program instructions) is disclosed.

[0030] The computer code, when executed by one or more processors, are configured to cause the processor to perform any one of the methods above.

[0031] The above embodiments and other aspects and alternatives of their implementations are described in greater detail in the drawings, the descriptions, and the claims below.BRIEF DESCRIPTION OF THE DRAWINGS

[0032] FIG. 1 illustrates an example wireless communication network including a wireless access network, a core network, and data networks.

[0033] FIG. 2 illustrates an example wireless access network including a plurality of mobile stations / terminals or UEs and a wireless access network node in communication with one another via an over-the-air radio communication interface.

[0034] FIG. 3 shows an exemplary radio access work configured with multiple cells for supporting dual connectivity.

[0035] FIG. 4 shows an example wireless core network.

[0036] FIG. 5 shows an example architecture of consumer equipment interacting with a Radio Access Network (RAN) through a RAN Exposure Function (REF) .

[0037] FIG. 6 shows an alternative example architecture of consumer equipment interacting with a Radio Access Network (RAN) through a RAN Exposure Function (REF) .

[0038] FIG. 7 shows an example messaging flow for registration, onboarding, authentication, and authorization procedures.

[0039] FIG. 8 shows an example messaging flow messaging flow for revocation, offboarding, and deregistration procedures.

[0040] FIG. 9 shows an example messaging flow a messaging flow for a Network Exposure Function (NEF) registration procedure.DETAILED DESCRIPTION

[0041] The technology and examples of implementations and / or embodiments described in this disclosure can be used to support Radio Access Network (RAN) capabilities exposure, such as access to an application programming interface (API) of the RAN by a third-party consumer. The term “exemplary” is used to mean “an example of” and unless otherwise stated, does not imply an ideal or preferred example, implementation, or embodiment. Section headers are used in the present disclosure to facilitate understanding of the disclosed implementations and are not intended to limit the disclosed technology in the sections only to the corresponding section. The disclosed implementations may be further embodied in a variety of different forms and, therefore, the scope of this disclosure or claimed subject matter is intended to be construed as not being limited to any of the embodiments set forth below. The various implementations may be embodied as methods, devices, components, systems, or non-transitory computer readable media. Accordingly, embodiments of this disclosure may, for example, take the form of hardware, software, firmware or any combination thereof.

[0042] This disclosure is generally directed to wireless communication and is specifically directed to methods and network devices for supporting Radio Access Network (RAN) capabilities exposure. For example, one or more network nodes may be registered a RAN Exposure Function (REF) configured to expose RAN-related capabilities or information. In response to registering a network node with the REF, the network node is onboarded with the REF. The network node is authenticated in response to the onboarding of the network node. Authentication is facilitated between the network node and a RAN node. Authorization is granted to the network node to access the RAN node.

[0043] Cellular Wireless Network Overview

[0044] An example cellular wireless communication network, shown as 100 in FIG. 1, may include wireless terminal devices or user equipment (UE) 110, 111, and 112, a carrier network 102, various service applications 140, and other data networks 150. The wireless terminal devices or UEs, may be alternatively referred to as wireless terminals. The carrier network 102, for example, may include access network nodes 120 and 121, and a core network 130. The carrier network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among UEs 110, 111, and 112, between the UEs and the service applications 140, or between the UEs and the other data networks 150. The access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) to interact with the UEs on one side of a communication session and the core network 130 on the other. The term “access network” may be used more broadly to refer a combination of the wireless terminal devices 110, 111, and 112 and the access network nodes 120 and 121. A wireless access network may be alternatively referred to as Radio Access Network (RAN) . The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. The service applications 140 may be hosted by various application servers deployed outside of but connected to the core network 130. Likewise, the other data networks 150 may also be connected to the core network 130.

[0045] The core network 130 of FIG. 1 may include various network nodes geographically distributed and interconnected to provide network coverage of a service region of the carrier network 102. These network nodes may be implemented as dedicated hardware network nodes. Alternatively, these network nodes may be virtualized and implemented as virtual machines or as software entities. These network nodes may each be configured with one or more types of network functions which collectively provide the provisioning and routing functionalities of the core network 130.

[0046] In the example wireless communication network of 100 of FIG. 1, the UEs may communicate with one another via the wireless access network. For example, UE 110 and 112 may be connected to and communicate via the same access network node 120. The UEs may communicate with one another via both the access networks and the core network. For example, UE 110 may be connected to the access network node 120 whereas UE 111 may be connected to the access network node 121, and as such, the UE 110 and UE 111 may communicate to one another via the access network nodes 120 and 121, and the core network 130. The UEs may further communicate with the service applications 140 and the data networks 150 via the core network 130. Further, the UEs may communicate to one another directly via side link communications, as shown by 113.

[0047] FIG. 2 further shows an example system diagram of the wireless access network 120 including a WANN 202 serving UEs 110 and 112 via the over-the-air interface 204. The wireless transmission resources for the over-the-air interface 204 include a combination of frequency, time, and / or spatial resource. Each of the UEs 110 and 112 may be a mobile or fixed terminal device installed with mobile access units such as SIM / USIM modules for accessing the wireless communication network 100. The UEs 110 and 112 may each be implemented as a terminal device including but not limited to a mobile phone, a smartphone, a tablet, a laptop computer, a vehicle on-board communication equipment, a roadside communication equipment, a sensor device, a smart appliance (such as a television, a refrigerator, and an oven) , or other devices that are capable of communicating wirelessly over a network. As shown in FIG. 2, each of the UEs such as UE 112 may include transceiver circuitry 206 coupled to one or more antennas 208 to effectuate wireless communication with the WANN 120 or with another UE such as UE 110. The transceiver circuitry 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage devices. The memory 212 may be transitory or non-transitory and may store therein computer instructions or code which, when read and executed by the processor 210, cause the processor 210 to implement various ones of the methods described herein.

[0048] Similarly, the WANN 120 may include a wireless base station or other wireless network access point or node capable of communicating wirelessly via the over-the-air interface 204 with one or more UEs and communicating with the core network 130. For example, the WANN 120 may be implemented, without being limited, in the form of a 2G base station, a 3G nodeB, an LTE eNB, a 4G LTE base station, a 5G NR base station of a 5G gNB, a 5G central-unit base station, or a 5G distributed-unit base station. Each type of these WANNs may be configured to perform a corresponding set of wireless network functions. The WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include an antenna tower 218 in various forms, to effectuate wireless communications with the UEs 110 and 112. The transceiver circuitry 214 may be coupled to one or more processors 220, which may further be coupled to a memory 222 or other storage devices. The memory 222 may be transitory or non-transitory and may store therein instructions or code that, when read and executed by the one or more processors 220, cause the one or more processors 220 to implement various functions of the WANN 120 described herein.

[0049] Data packets in a wireless access network such as the example described in FIG. 2 may be transmitted as protocol data units (PDUs) . The data included therein may be packaged as PDUs at various network layers wrapped with nested and / or hierarchical protocol headers. The PDUs may be communicated between a transmitting device or transmitting end (these two terms are used interchangeably) and a receiving device or receiving end (these two terms are also used interchangeably) once a connection (e.g., a radio link control (RRC) connection) is established between the transmitting and receiving ends. Any of the transmitting device or receiving device may be either a wireless terminal device such as device 110 and 120 of FIG. 2 or a wireless access network node such as node 202 of FIG. 2. Each device may both be a transmitting device and receiving device for bi-directional communications.

[0050] The example wireless access network or radio access network above may be configured as a cellular network, in which radio communication resources are managed in cells. The communication cells are configured to minimize radio interference. As shown in the wireless access network 120 in FIG. 3, each base station 302, 304, and 306 may be associated with a particular Radio Access Technology (RAT) . The various RATs may include but not limited to 2G, 3G, 4G / LTE, 5G, 6G, and other generations of radio access technologies. The term base station is used to refer to a network node or a portion of a network node that communicates with wireless terminals using one or more OTA interfaces. In wireless access network nodes having functional split, such as a split between distributed units (DUs) and central units (CUs) , the term base station may be used refer to a DU. The base stations 302, 304, and 306 may use separate or shared radio resources (e.g., carrier frequencies and / or time) . Each of the base stations may be associated with a coverage area, which may include one or more cells. For example, as shown in FIG. 3, the base station 302 may be a 4G / LTE base station associated with an approximate coverage area 303 and configured to provision cells 310, 312 and 314; the base station 304 may be a 5G / New Radio (NR) DU associated with approximate coverage area 305 and configured to provision cells 320 and 322; whereas the base station 306 may be another 4G / LTE base station associated with an approximate coverage area 307 and configured to provision cells 330 and 332.

[0051] The wireless terminals 340, 342. and 344 in FIG. 3, for example, may be mobile wireless terminals and thus may move from cell to cell and / or from RAT to RAT. A particular wireless terminal may be potentially connected to multiple cells or multiple RAT. Dual connectivity (DC) (or multi-connectivity) refers to network implementations where a wireless terminal is simultaneously connected to two (or multiple) cells of two (or multiple) distinct RATs. For example, the wireless terminal 342 of FIG. 3 may be configured to be in DC operation m mode with cell 414 (provisioned by the 4G / LET base station 302) and cell 320 (provisioned by the 5G / NR base station 304) .

[0052] The multiple cells shown in FIG. 3 for each base station may be configured into cell groups (CGs) . Both the cells and CGs are provisioned (e.g., added, configured, modified removed, etc. ) by the corresponding base station. A cell group may be either a Master CG (MCG) or Secondary CG (SCG) . Within each type of cell groups, there may be one primary cell and one or more secondary cells. A primary cell in a MSG, for example, may be referred to as a PCell, whereas a primary cell in a SCG may be referred to as PScell. Secondary cells in either an MCG or an SCG may be all referred to as SCells. The primary cells including PCell and PScell may be collectively referred to as spCells (special Cells) . All these cells may be referred to as serving cells or cells. The term “cell” and “serving cell” may be used interchangeably in a general manner unless specifically differentiated. The term “serving cell” may refer to a cell that is serving, will serve, or may serve the UE. In other words, a “serving cell” may not be currently serving the UE. While the various embodiment described below may at times be referred to one of the types of serving cells above, the underlying principles apply to all types of serving cells in both types of serving cell groups.

[0053] FIG. 4 shows an example division of network node functions in the core network 130. While only single instances of network nodes for some functions are illustrated in FIG. 4, those having ordinary skill in the art understand that each of these network nodes may be instantiated as multiple instances that are distributed throughout the core network 130. As shown in FIG. 4, the core network 130 may include but are not limited to access management network function (AMF) nodes 430, location management function (LMF) nodes 421, session management function (SMF) nodes 440, user plane function (UPF) nodes 450, policy control function (PCF) nodes 420, and application data management function (AF) nodes 410.

[0054] The AMF nodes 430 may communicate with the access network 120, the SMF nodes 440, and the PCF nodes 420 respectively via communication interfaces 422, 432, and 424, and may be responsible for provisioning registration, authentication, and access by the UE to the core network 130 was well as allocation of SMF nodes 440 to support particular UE communication sessions. The SMF nodes 440 allocated by the AFM nodes 430 may in turn may be responsible for allocating UPF nodes 450 for supporting the particular UE communication session and control these allocated UPF nodes 450 via communication interface 446. Alternatively, or additionally in some implementations, the UPF nodes 450 may be directly allocated by the AMF nodes 430 via the interface 434 and controlled by the SMF nodes 440 via the communication interface 446. Access policies and session routing policies applicable to the UEs may be managed by the PCF nodes 420 which communicate the policies to the AMF nodes 430 and the SMF nodes 440 via communication interfaces 424 and 423, respectively. The PCF nodes 420 may be further responsible for managing user subscription 412 to service application 140 via the AF nodes 410. The signaling and data exchange between the various types of network nodes through various communication interfaces indicated by the various connection lines in FIG. 4, may be carried by signaling or data messages following predetermined types of format or protocols.

[0055] To support a particular end-to-end communication task requested by a UE, a communication session may be established to support a data traffic pipeline for transporting the particular end-to-end data communication traffic. The carrier network portion of the data traffic pipeline, as illustrated by 470 of FIG. 4, may involve one or more network nodes in the access network 120 and a set of UPF nodes 452, 454, and 456 in the core network 130, as selected and controlled, for example, by a set of SMF nodes 442 and 444 which may be selected and controlled by the AMF nodes 430 that are responsible for establishing and managing the communication session. Data traffic is routed among a UE at one end of the data traffic pipeline, the carrier network portion of the data traffic pipeline (including the set of network nodes in the access network 120 and the selected UPF nodes 452, 454, and 456 in the core network 130) , and another end of the data traffic pipeline including, for example, another UE, a service application or application server 140, or a data network 150, via communication interfaces such as 424, 458, and 459.

[0056] RAN Exposure Function (REF)

[0057] As previously described, current network exposure technologies primarily use the Network Exposure Function (NEF) , which has been utilized in 5G networks to expose information such as location services, traffic management, and other network resources to external applications. NEF provides secure access to network resources through API interfaces, authentication, and authorization mechanisms. However, NEF’s application has been mainly focused on the core network service layer, with limited exposure to the RAN layer.

[0058] In the future sixth-generation (6G) network, as the Radio Access Network (RAN) evolves towards a more open, intelligent, and collaborative architecture, cross-domain network services and applications will become the norm. To meet this demand, third-party applications and service providers will need secure access to critical RAN information, such as network status, traffic load, resource allocation, and user location. The exposure of such information will not only enable data-driven decision-making and network optimization but also promote emerging use cases, such as smart transportation, Internet of Things (IoT) , and augmented reality. To achieve this goal, the RAN Exposure Function (REF) may be defined as an interface for exposing RAN information externally. This function would allow external consumers to access such information while adhering to appropriate security and privacy protection policies.

[0059] To meet the need for exposing RAN information in future 6G networks, the present disclosure describes various techniques to design and implement the REF. This function must not only ensure that external consumers can access RAN information as needed but also ensure the secure transmission and use of the data.

[0060] Thus, the present disclosure describes the design of how the RAN Exposure Function (REF) manages the processes of registration, onboarding, authentication, and / or authorization for external consumers / NEF / RAN nodes. The present disclosure, therefore, may define a series of interactions between the RAN Exposure Function (REF) and the consumer / NEF (network exposure function)  / RAN nodes, including registration, onboarding, authentication, and authorization.

[0061] FIGS. 5 and 6 shows example network architectures of consumer equipment interacting with a Radio Access Network (RAN) through a RAN Exposure Function (REF) . As shown in FIG. 5, the network may include one REF through which a plurality of consumers may be provided access to a plurality of RAN Nodes. As shown in FIG. 6, the network may include multiple RAN nodes each having their own REF through which the consumers may be granted access to the RAN. In one or more example implementations corresponding to FIGS. 5 and 6, the REF may be standalone or may be incorporated into the RAN node (s) .

[0062] An example implementation for registration, onboarding, authentication, and authorization between a consumer node, a REF node, and a RAN node is shown in FIG. 7. FIG. 7 provides a messaging flow for the registration, onboarding, authentication, and authorization procedures. The various steps in the messaging flow of FIG. 7 are described in further detail below with numerals corresponding to FIG. 7.

[0063] In one or more implementations, a RAN Exposure Function (REF) is configured to expose RAN-related capabilities or information. A network node may be a third-party consumer node or a Network Exposure Function (NEF) .

[0064] Registering RAN with REF

[0065] In one or more implementations, the RAN node may need to register with the REF to facilitate management by the REF. At Step 1, the RAN node sends a registration request to the REF, which includes relevant information. The registration request may include, among other things, a RAN node ID, a REF ID, and / or security information. The RAN node ID may be a unique identifier for the RAN node. The REF ID may be a unique identifier for the REF. The security information may include information used by the REF to authenticate and verify the registration request.

[0066] At Step 2, based on the information provided by the RAN node, the REF determines whether to register the RAN node, and if the REF decides to proceed with the registration, the REF stores the relevant RAN node information.

[0067] At Step 3, the REF sends a registration response to the RAN node. The registration response may include a RAN node ID, a REF ID, a registration result, a registration reason, and / or security information. The RAN node ID may be a unique identifier for the RAN node. The REF ID may be an identity of the REF. The registration result may indicate whether the registration was successful or failed. The registration reason may provide the reason for failure if the registration is unsuccessful. The security information may be provided upon successful registration, to be used by the RAN node in subsequent event or information exposure subscriptions.

[0068] Consumer Registration

[0069] In one or more implementations, the consumer may be registered with the REF. At Step 4, the consumer sends a registration request to the REF, which includes relevant information about the consumer. The consumer registration request may include a consumer ID, a REF ID, application service information, and / or query information of RAN exposure. The consumer ID may be a unique identifier for the consumer, such as their name or identity. The REF ID may be a unique identifier for the REF. Application Service Information may be Descriptive details about the consumer's application service. Query Information of RAN Exposure may be The requested RAN exposure information, such as serving area information, preferred RAN node location, RAN exposure API name, and / or exposure information description. Security Information may be Information used by the REF to authenticate and verify the registration request.

[0070] At step 5, based on the information provided by the consumer, the REF determines whether to register the consumer. If the REF decides to proceed with the registration, the REF stores the relevant consumer information.

[0071] At Step 6, the REF sends a registration response to the consumer. The consumer registration response may include a consumer ID, a REF ID, a registration result, a registration reason, and / or security information. The consumer ID may be the consumer's name or identity. The REF ID may be the REF's identity. The registration result may be Indicates whether the registration was successful or failed. The registration reason may provide the reason for failure if the registration is unsuccessful. The security information may be provided upon successful registration, to be used by the consumer in subsequent event or information exposure subscriptions.

[0072] Consumer Onboarding

[0073] In one or more implementations, the consumer may be onboarded with the REF. At Step 7, the consumer retrieves the necessary information for onboarding, such as the REF address, certificates, tokens, etc.

[0074] At Step 8, the consumer sends an onboarding request to the REF. The onboarding request may include information used by the REF for onboarding, information used by the REF for authentication, information used by the REF for authorization, network slicing requirements, query information of RAN exposure, and / or a suggested time for onboarding. The information used by the REF for onboarding may include an application name, an application type, a purpose description, an expected access frequency, etc. The information used by the REF for authentication may include credentials for identity verification (e.g., public key, certificate request, etc. ) . The information used by the REF for authorization may include a list or categories of APIs the consumer wishes to access, regions of the requested APIs, etc. The query information of RAN exposure may include requested RAN exposure information, such as serving area information, preferred RAN node location, RAN exposure API name, and / or exposure information description.

[0075] At Step 9, the REF checks whether the information sent by the consumer is complete. If complete, the REF creates a full configuration profile for the consumer and saves it. The configuration profile may include an assigned consumer ID, detailed onboarding information, detailed authentication information, detailed authorization information, a list and categories of accessible ran exposure APIs, and / or access control policies based on network slicing requirements. The assigned consumer ID may be a unique identity assigned to the consumer by the REF.

[0076] At Step 10, the REF sends an onboarding response to the consumer. The onboarding response may include an onboarding status, authorization information, a reason for failure if onboarding is unsuccessful, an expiration time, a strategy for network slicing, an assigned consumer ID, and / or authentication information. The onboarding status may indicate success or failure. The authorization information may include an authorization token, a privilege level, and / or a list and categories of accessible APIs. The expiration time may be an expiration time for onboarding. The strategy for network slicing may include access control policies related to network slicing. The assigned consumer ID may be a unique identity assigned to the consumer by the REF. The authentication Information may include credentials used by the consumer for authentication (e.g., keys, tokens, certificates) .

[0077] Authentication between Consumer and REF

[0078] In one or more example implementations, the consumer may be authenticated with the REF based on the consumer having been onboarded with the REF. At Step 11, the consumer sends an authentication request to the REF, requesting authentication. The authentication request may include an assigned consumer ID, a REF ID, and / or credentials used for identity authentication. The assigned consumer ID may be a unique identity assigned to the consumer by the REF. The REF ID may be an identity of the REF. The credentials used for identity authentication may include keys, tokens, certificates, etc.

[0079] At Step 12, the REF verifies the consumer's identity based on the previously saved configuration profile and authenticates the consumer.

[0080] At Step 13, the REF sends an authentication response to the consumer, completing the authentication process. The authentication response may include an authentication result, credentials used for identity authentication, an assigned consumer ID, and / or a REF ID. The authentication result may be success or failure. The Credentials used for identity authentication may include keys, tokens, certificates, etc. The assigned consumer ID may be a unique identity assigned to the consumer by the REF. The REF ID may be an identity of the REF.

[0081] Authentication between Consumer and RAN

[0082] In one or more implementations, the REF may facilitate authentication between the consumer and the RAN based on the consumer having been onboarded and authenticated with the REF.

[0083] At Step 14, the consumer sends an authentication request to the RAN node, requesting authentication. The authentication request may include an assigned consumer ID, a REF ID, a RAN node ID, and / or credentials used for identity authentication. The assigned consumer ID may be a unique identity assigned to the consumer by the REF. The REF ID may be an identity of the REF. The RAN node ID may be an identity of RAN node. The credentials used for identity authentication may include keys, tokens, certificates, etc.

[0084] At Step 15, the RAN node sends a consumer information request to the REF to retrieve the consumer's configuration profile.

[0085] At Step 16, the REF sends a consumer information response to the RAN node, which contains the consumer's configuration profile.

[0086] At Step 17, the RAN node then verifies the consumer's identity based on the profile and authenticates the consumer.

[0087] At Step 18, the RAN node sends an authentication response to the consumer, completing the authentication process. The authentication response may include an authentication result, credentials used for authentication, an assigned consumer ID, a REF ID, and / or a RAN node ID. The authentication result may be success or failure. The credentials used for identity authentication may include keys, tokens, certificates, etc. The assigned consumer ID may be a unique identity assigned to the consumer by the REF. The REF ID may be an identity of the REF. The RAN node ID may be the identity of RAN node.

[0088] Consumer Obtains Authorization to Access RAN Exposure API

[0089] In one or more implementations, the consumer may obtain authorization to access a RAN exposure API of the RAN based on the consumer having been onboarded with the REF. At Step 19, the consumer sends an obtain authorization request (i.e., a first authorization request) to the REF to request authorization information for the RAN node. The obtain authorization request may include a consumer ID, a REF ID, a RAN node ID, query information of RAN exposure, and / or identity credentials. The consumer ID may be a unique identifier assigned to the consumer by the REF. The REF ID may be a unique identifier of the REF. The RAN node ID may be a unique identifier of the RAN node. The query information of RAN Exposure may be requested RAN exposure information, such as serving area information, preferred RAN node location, RAN exposure API name, and / or exposure information description. The identity credentials may be credentials used for authentication (e.g., keys, tokens, certificates) .

[0090] At Step 20, the REF verifies the consumer's identity based on the previously stored configuration profile.

[0091] At Step 21, after successful verification, the REF includes the consumer's profile and request in a REF obtaining authorization request (i.e., a second authorization request) , which is sent to the corresponding RAN node. The REF obtaining authorization request may include a consumer ID, a REF ID, a RAN node ID, query information of RAN exposure, a consumer profile, and identity credentials. The consumer ID may be a unique identifier assigned to the consumer by the REF. The REF ID may be a unique identifier of the REF. The RAN node ID may be a unique identifier of the RAN node. The query information of RAN exposure may be requested RAN exposure information, such as serving area information, preferred RAN node location, RAN exposure API name, and / or exposure information description. The consumer profile may be the consumer’s configuration profile stored by the REF. The identity credentials may be credentials used for authentication (e.g., keys, tokens, certificates) .

[0092] At Step 22, the RAN node verifies the consumer’s identity based on the information received from the REF and generates and stores the authorization information.

[0093] At Step 23, the RAN node sends a REF obtaining authorization response (i.e., a first authorization response) to the REF, containing the generated authorization information. The REF obtaining authorization response may include a consumer ID, a REF ID, a RAN node ID, and / or authorization information. The consumer ID may be a unique identifier assigned to the consumer by the REF. The REF ID may be a unique identifier of the REF. The RAN node ID may be a unique identifier of the RAN node. The authorization information may be information used for the consumer to invoke the API in subsequent operations.

[0094] At Step 24, the REF sends an obtain authorization response (i.e., a second authorization response) to the consumer, completing the authorization process. The obtain authorization response may include a consumer ID, a REF ID, a RAN node ID, and / or authorization information. The consumer ID may be a unique identifier assigned to the consumer by the REF. The REF ID may be a unique identifier of the REF. The RAN node ID may be a unique identifier of the RAN node. The authorization information may be information used for the consumer to invoke the API in subsequent operations.

[0095] Revoking Authorization, Offboarding, and Deregistration

[0096] An example implementation for revoking authorization, offboarding, and deregistration between a consumer, a REF node, and a RAN node is shown in FIG. 8. FIG. 8 provides a messaging flow for the revocation, offboarding, and deregistration procedures. The various steps in the messaging flow of FIG. 8 are described in further detail below with numerals corresponding to FIG. 8.

[0097] RAN Revokes Consumer Authorization

[0098] In one or more implementations, the RAN may revoke consumer authorization to access the RAN exposure API for a consumer that is authenticated and authorized to use the RAN exposure API. At step 1, the RAN node triggers the revocation of the consumer authorization of the RAN exposure API.

[0099] At Step 2, the RAN node sends a revoke authorization request to the REF. The revoke authorization request / notification may include a consumer ID, a REF ID, a RAN node ID, and / or a revocation reason. The consumer ID may be a unique identifier assigned to the consumer by the REF. REF ID may be a unique identifier of the REF. RAN Node ID may be a unique identifier of the RAN node. RAN exposure API information may be the identification of RAN exposure API. Revocation reason may be the revocation reason of the authorization.

[0100] At Step 3, based on the revocation request from the RAN node, the REF invalidates the authorization of the RAN exposure API.

[0101] At Step 4, the REF sends a revoke authorization notification to the consumer. The revoke authorization response may include a consumer ID, a REF ID, a RAN node ID, and a revocation result. The consumer ID may be a unique identifier assigned to the consumer by the REF. The REF ID may be a unique identifier of the REF. The RAN node ID may be a unique identifier of the RAN node. The revocation result may indicate whether the revocation was successful or failed.

[0102] Consumer Offboarding

[0103] In one or more implementations, the consumer may be offboarded with the REF. At Step 5, the consumer sends an offboarding request to the REF, which includes the consumer ID, REF ID, and the offboarding reason.

[0104] At Step 6, the REF cancels the consumer's registration in the REF, and the consumer is no longer considered an authenticated user of the REF. All authorization information related to the consumer is revoked.

[0105] At Step 7, the REF sends an offboarding response to the consumer, which includes the offboarding result (success or failure) .

[0106] Consumer Deregistration

[0107] In one or more implementations, the consumer may be deregistered from the REF. At Step 8, the consumer sends a deregistration request to the REF, which includes security information used by the REF to verify the deregistration request.

[0108] At Step 9, the REF verifies the deregistration request information and completes the deregistration process.

[0109] At Step 10, the REF sends a deregistration response to the consumer, informing them of the deregistration result (success or failure) .

[0110] Register NEF with REF

[0111] In one or more implementations, if the NEF is the sole exposure function for 3GPP, then the consumer will register with the NEF to access REF and thereby obtain RAN exposure information. An example implementation for the NEF registering itself with the REF is shown in FIG. 9. FIG. 9 provides a messaging flow for the NEF registration procedure. The various steps in the messaging flow of FIG. 9 are described in further detail below with numerals corresponding to FIG. 9.

[0112] At Step 1, the NEF sends a registration request to the REF, which includes relevant information. The NEF registration request may include a NEF ID, a REF ID, and / or security information. The NEF ID may be a unique identifier for the NEF. The REF ID may be a unique identifier for the REF. The security information may be information used by the REF to authenticate and verify the NEF registration request.

[0113] At Step 2, based on the information provided by the NEF, the REF determines whether to register the NEF. If the REF decides to proceed with the registration, it stores the relevant NEF information.

[0114] At Step 3, the REF sends a registration response to the NEF. The NEF registration response may include the NEF ID, the REF ID, a registration result, a registration reason, and / or security information. The NEF ID may be a unique identifier for the NEF. The REF ID may be a unique identifier for the REF. The registration result may indicate whether the registration was successful or failed. The registration reason may provide the reason for failure if the registration is unsuccessful. The security information may be provided upon successful registration to be used by the NEF in subsequent event or information exposure subscriptions.

[0115] The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

[0116] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment / implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment / implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part. Additionally, the term “step” as used herein describes a given action and does not imply any particular order in which these actions are to be performed. Any of the “steps” described herein may be performed in substantially any combination in substantially any order, including performing any number of steps simultaneously or concurrently.

[0117] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0118] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

[0119] Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

1.A method of supporting Radio Access Network (RAN) capabilities exposure, by a first node configured to perform a RAN Exposure Function (REF) , comprising:receiving, from at least one of a second node or a third node, a first message comprising a request for a REF-related operation; andtransmitting, to at least one of the second node or the third node, a second message containing result information on the request.2.The method of claim 1, wherein the request comprises at least one of the following:a registration request for registering one of the second node or the third node with the first node;a deregistration request for deregistering the second node from the first node;an onboarding request for onboarding the second node with the first node;an offboarding request for offboarding the second node from the first node;a first authentication request for authenticating the second node with the first node;a second authentication request for facilitating authentication between the second node and the third node;a first authorization request for obtaining authorization for the second node to access the third node; and / ora revoke authorization request for revoking authorization for RAN exposure API of the second node to access the third node.3.The method of claims 1 or 2, wherein the second node comprises at least one of a consumer node or a Network Exposure Function (NEF) .4.The method of any one of claims 1 to 3, wherein the third node comprises a RAN node.5.The method of any one of claims 1 to 4, further comprising, in response to receiving the registration request including registration information:determining, based on the registration information, whether to register the one of the second node or the third node; and / orstoring the registration information.6.The method of claim 5, wherein the registration information comprises at least one of:an ID of the first node;an ID of the one of the second node or the third node;a name of the second node;application service information;query information associated with application programming interface (API) exposure of the third node; orsecurity information to authenticate and verify the registration request.7.The method of claims 5 or 6, wherein transmitting the second message comprises transmitting a registration response to the second node, the registration response comprises at least one of:an ID of the first node;an ID of the one of the second node or the third node;a name of the second node;a registration result;a registration reason if registering the one of the second node or the third node is unsuccessful; orsecurity information associated with subsequent event or information exposure subscriptions of the one of the second node or the third node.8.The method of any one of claims 1 to 4, further comprising, in response to receiving the onboarding request:checking whether information sent by the second node is complete;creating a configuration profile for the second node; and / orsaving the created configuration profile.9.The method of claim 8, wherein the onboarding request comprises at least one of:onboarding information comprising an application name, an application type, a purpose description, and / or an expected access frequency;information used for authentication comprising credentials for identity verification;information used for authorization comprising a list or categories of APIs that the second node wishes to access, or regions of requested APIs;network slicing information;query information associated with API exposure of the third node; ora suggested expiration time for the onboarding.10.The method of claims 8 or 9, wherein the configuration profile comprises at least one of:an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;detailed onboarding information;detailed authentication information;detailed authorization information;a list and categories of RAN exposure APIs that the second node wishes to access, or regions of requested APIs; oraccess control policies based on network slicing requirements.11.The method of any one of claims 8 to 10, wherein transmitting the second message comprises transmitting an onboarding response to the second node, the onboarding response comprises at least one of:an onboarding status;authorization information comprising an authorization token, a privilege level, or a list or categories of accessible APIs;a reason for failure if the onboarding is unsuccessful;an expiration time for the onboarding;a strategy for network slicing;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node; orauthentication information.12.The method of any one of claims 1 to 4, further comprising, in response to receiving the first authentication request:verifying an identity of the second node based on a configuration profile; and / orauthenticating the second node.13.The method of claim 12, wherein the first authentication request comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node; orcredentials for authentication of the second node.14.The method of claims 12 or 13, wherein transmitting the second message comprises transmitting an authentication response to the second node, the authentication response comprises at least one of:an authentication result;credentials for authentication of the second node;an ID of the first node; oran assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node.15.The method of any one of claims 1 to 4, further comprising:in response to receiving the second authentication request, retrieving a configuration profile for the second node, wherein transmitting the second message comprises transmitting an information response to the third node, wherein the information response includes the retrieved configuration profile of the second node.16.The method of any one of claims 1 to 4, further comprising, in response to receiving the first authorization request to request authorization information for the second node to access the third node:verifying an identity of the second node based on a configuration profile of the second node, wherein the configuration profile was previously stored by the first node;in response to successfully verifying the identity of the second node, transmitting the configuration profile and a second authorization request to the third node; and / orreceiving, from the third node, a first authorization response containing authorization information generated by the third node.17.The method of claim 16, wherein the first authorization request comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;an ID of the third node;query information associated with API exposure of the third node; orcredentials for authentication of the second node.18.The method of claims 16 or 17, wherein transmitting the second message comprises transmitting, to the second node, a second authorization response, the second authorization response comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;an ID of the third node; orauthorization information for the second node to invoke an API in subsequent operations.19.The method of any one of claims 16 to 18, wherein the second authorization request comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;an ID of the third node;query information associated with API exposure of the third node;a profile associated with the second node; orcredentials for authentication of the second node.20.The method of any one of claims 16 to 19, wherein the first authorization response comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;an ID of the third node; orauthorization information for the second node to invoke an application programming interface (API) in subsequent operations.21.The method of any one of claims 1 to 4, further comprising, in response to receiving the revoke authorization request from the third node:invalidating authorization of an API exposure of the third node to the second node.22.The method of claim 21, wherein the revoke authorization request comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;an ID of the third node;information associated with the API exposure of the third node; ora revocation reason.23.The method of claims 21 or 22, wherein transmitting the second message comprises transmitting a revoke authorization notification to the second node, the revoke authorization notification comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;an ID of the third node; ora revocation result.24.The method of any one of claims 1 to 4, further comprising, in response to receiving the offboarding request, the offboarding request comprising an ID of the first node, an ID of the second node, and an offboarding reason:canceling registration of the second node with the first node, wherein the second node is no longer considered an authenticated user of the first node,wherein transmitting the second message comprises transmitting an offboarding response to the second node, the offboarding response including an offboarding result.25.The method of any one of claims 1 to 4, further comprising, in response to receiving the deregistration request, the deregistration request including security information used by the first node to verify the deregistration request:verifying the deregistration request; and / orcanceling registration of the second node with the first node, wherein the second node is no longer considered an authenticated user of the first node;wherein transmitting the second message comprises transmitting a deregistration response to the second node, the deregistration response informing the second node of a deregistration result.26.A method of supporting Radio Access Network (RAN) capabilities exposure, by one of a second node or a third node, comprising:transmitting, to a first node configured to perform a RAN Exposure Function (REF) or to the other of the second node or the third node, a first message comprising a request for a REF-related operation; andreceiving, from the first node or from the other of the second node or the third node, a second message containing result information on the request.27.The method of claim 26, wherein the request comprises at least one of the following:a registration request for registering the one of the second node or the third node with the first node;a deregistration request for deregistering the second node from the first node;an onboarding request for onboarding the second node with the first node;an offboarding request for offboarding the second node from the first node;a first authentication request for authenticating the second node with the first node;a second authentication request for facilitating authentication between the second node and the third node; and / ora first authorization request for obtaining authorization for the second node to access the third node.28.The method of claims 26 or 27, wherein the second node comprises at least one of a consumer node or a Network Exposure Function (NEF) .29.The method of any one of claims 26 to 28, wherein the third node comprises a RAN node.30.The method of claim 28 or 29, any one of claims 26 to 29, wherein:the registration request includes registration information associated with the one of the second node or the third node; andin response to transmitting the registration request, the second message comprises a registration response.31.The method of claim 30, wherein the registration information comprises at least one of:an ID of the one of the second node or the third node;a name of the second node;an ID of the first node;application service information;query information associated with API exposure of the third node; orsecurity information to authenticate and verify the registration request.32.The method of claims 30 or 31, wherein the registration response comprises at least one of:an ID of the one of the second node or the third node;an ID of the first node;a name of the second node;a registration result;a registration reason if registering the one or the second node or the third node is unsuccessful; orsecurity information associated with subsequent event or information exposure subscriptions of the one of the second node or the third node.33.The method of any one of claims 26 to 29, further comprising, in response to transmitting the onboarding request:retrieving information for onboarding from the third node comprising an address of the first node, certificates, or tokens.34.The method of claim 33, wherein the onboarding request comprises at least one of:onboarding information comprising an application name, an application type, a purpose description, and / or an expected access frequency;authentication information comprising credentials for identity verification;authorization information comprising a list or categories of APIs that the second node wishes to access, or regions of requested APIs;network slicing information;query information associated with API exposure of the third node; ora suggested expiration time for the onboarding.35.The method of claims 33 or 34, wherein receiving the second message comprises receiving an onboarding response comprising at least one of:an onboarding status;authorization information comprising an authorization token, a privilege level, or a list or categories of accessible APIs;a reason for failure if the onboarding is unsuccessful;an expiration time for the onboarding;a strategy for network slicing;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node; orauthentication information.36.The method of any one of claims 26 to 29, wherein, in response to transmitting the first authentication request:receiving the second message comprises receiving a first authentication response.37.The method of claim 36, wherein the first authentication request comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node; orcredentials for authentication of the second node.38.The method of claims 36 or 37, wherein the first authentication response comprises at least one of:an authentication result;credentials used for authentication of the second node;an ID of the first node; oran assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node.39.The method of any one of claims 26 to 29, wherein, in response to transmitting the second authentication request:receiving the second message comprises receiving a second authentication response.40.The method of claim 39, wherein the second authentication request comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;an ID of the third node; orcredentials used for authentication of the second node.41.The method of claims 39 or 40, wherein the second authentication response comprises at least one of:an authentication result;credentials used for authentication of the second node;an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node; oran ID of the third node.42.The method of any one of claims 26 to 29, wherein, in response to transmitting the first authorization request:receiving the second message comprises receiving a second authorization response.43.The method of claim 42, wherein the first authorization request comprises at least one of:an ID of the first node;an assigned ID of the second node, wherein the assigned ID is assigned to the second node by the first node;an ID of the third node;query information associated with API exposure of the third node; orcredentials for authentication of the second node.44.The method of claims 42 or 43, wherein the second authorization response comprises at least one of:an ID of the first node;an ID of the second node;an ID of the third node; orauthorization information for the second node to invoke an API in subsequent operations.45.The method of any one of claims 26 to 29, further comprising receiving a revoke authorization notification from the first node.46.The method of claim 45, wherein the revoke authorization notification comprises at least one of:an ID of the first node;an assigned ID of the second node, where the assigned ID is assigned to the second node by the first node;an ID of the third node; ora revocation result.47.The method of any one of claims 26 to 29, wherein:the offboarding request includes an ID of the first node, an ID of the second node, and an offboarding reason; andin response to transmitting the offboarding request, receiving the second message comprises receiving an offboarding response from the first node, the offboarding response including an offboarding result.48.The method of any one of claims 26 to 29, wherein:the deregistration request includes security information used by the first node to verify the deregistration request; andin response to transmitting the deregistration request, receiving the second message comprises receiving a deregistration response from the first node, the deregistration response informing the second node of a deregistration result.49.A wireless communication apparatus comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement the method of any one of claims 1 to 48.50.A non-transitory computer-readable storage medium for storing instructions, the instructions, when executed by at least one processor, are configured to cause the at least one processor to perform the method of any one of claims 1 to 48.

Images