Patent Description:
Interactions between Network Functions (NFs) in Roaming Scenarios: In the scope of the Fifth Generation (<NUM>) core network service-based architecture, and in particular in roaming scenarios, a NF in a visited Public Land Mobile Network (PLMN) (vPLMN) needs to interact with NFs in the home PLMN (hPLMN). For most interactions, the NF in the vPLMN (which is referred to herein as a "vNF") will discover the address and services of the NFs in the hPLMN (which is referred to herein as a "hNF") by means of the NF Repository Function (NRF) discovery service. For that, the vNFs only interact with NRFs in their own PLMN (i.e., the vPLMN); therefore, the vNF will invoke the discovery service in the visited NRF (vNRF), and the vNRF in turn will invoke the discovery service in the home NRF (hNRF). This means that there must be some way for the vNRF to determine the address and service parameters of the hNRF. This can be done in two different ways. For the first way, as part of a Service-Level Agreement (SLA) between the hPLMN and the vPLMN, there can be static configuration parameters in the vNRF that indicates how to interact with the hNRF. For the second way, if such static configuration does not exist, the vNRF needs to dynamically construct the address of the hNRF based on the Mobile Country Code (MCC) / Mobile Network Code (MNC) values of the User Equipment (UE) that is camping on the vPLMN.

Currently, Third Generation Partnership Project (3GPP) Technical Specification (TS) <NUM> clause <NUM>. <NUM> specifies the following:.

This means that the base URI of the NRF would be as follows: https://nrf. 3gppnetwork. However, even with all the information above, it is still not possible for the vNRF to invoke services on the hNRF because the vNRF needs to construct URIs with the following structure:.

The "v1" path segment refers to the major version of the full API version (e.g., if the API version is <NUM>. <NUM>, it refers to the first digit, prepended by the letter "v", i.e. "v1"). This is a mandatory component of almost all service URIs in the 3GPP APIs.

Normally, the version of a given API is discovered by means of the NRF discovery service itself; but, for the NRF APIs themselves, there is currently no way to do such discovery. <FIG> is a call flow diagram illustrating a conventional process for interaction between a vNF and an hNF. In step <NUM>, the vNF determines the address of the vNRF by means of local configuration, which is feasible given that it is a configuration local to the vPLMN. In step <NUM>, the vNRF, in the absence of static configuration (SLA) about the hPLMN, builds the address of the hNRF based on the MCC/MNC of the UE. Still, the vNRF lacks information about the version of the API deployed by the hNRF, and accordingly defaults to using the lowest version (v1) of the API deployed by the hNRF. In step <NUM>, the hNRF returns the search result of the discovery to the vNRF. In step <NUM>, the vNRF returns the search result of the discovery to the vNF.

In addition to the scenario above, an identical problem exists for the Network Slice Selection Function (NSSF). The visited NSSF (vNSSF) needs to invoke services from the home NSSF (hNSSF) and, in order to do that, it needs to either rely on static configuration or dynamically construct a service request URI that uses the MCC/MNC of the UE (see 3GPP TS <NUM>, clause <NUM>. However, the vNSSF needs to know the version of the APIs deployed by the hNSSF. Accordingly, the same problem for communication between a vNRF and an hNRF exists between a vNSSF and an hNSSF. There currently exist certain challenge(s). There is currently no solution in 3GPP to address the problem described above. As of today, the vNRF (or vNSSF) has no other means than defaulting to version <NUM> (v1) or, otherwise, rely on static configuration (SLA) when accessing APIs deployed by an hNRF (or hNSSF). This has a severe limitation, and it is much more preferable to provide a fully dynamic solution that does not impose to have pre-agreed configuration parameters in order to determine how to invoke NRF (or NSSF) services on another PLMN. In <NPL>, as an alternative to the NRF, it is proposed to support dedicated URIs to enable NF service consumers to retrieve information about API versions supported by an NF service producer using a simple GET request.

Systems and methods related to a bootstrapping service for a Network Function (NF) in a core network of a cellular communications system are disclosed. In one embodiment, a method performed by a first NF in a core network of a cellular communications system comprises receiving, from a second NF, a request for services exposed by the first NF. The method further comprises, responsive to receiving the request, sending, to the second NF, information about one or more services exposed by the first NF. In one embodiment, the information about one or more services exposed by the first NF includes Application Programming Interface (API) versions of the one or more services. In this manner, flexibility is provided in the network since there is no need for static configuration of service parameters.

The first NF is a NF Repository Function (NRF), and the second NF is a NF service consumer. In one embodiment, the first NF is a home NRF (hNRF) in a home Public Land Mobile Network (PLMN) (hPLMN) of a particular User Equipment (UE), and the second NF is a visited NRF (vNRF) in a visited PLMN (vPLMN) of the particular UE.

In one embodiment, receiving the request comprises receiving the request for a bootstrapping service of the first NF. In one embodiment, the first NF is a NRF, and the bootstrapping service is separate from a discovery service of the NRF. In one embodiment, the request is a Hyper-Text Transfer Protocol (HTTP) GET request addressed to {nrfApiRoot}/bootstrapping, where {nrfApiRoot} is a concatenation of a scheme component and an authority component of the NRF. In another embodiment, the request is a HTTP GET request addressed to https://nrf. 3gppnetwork. org/bootstrapping, where "MNC" is a Mobile Network Code of a particular UE associated with the request and "MCC" is a Mobile Country Code of the particular UE. In one embodiment, the request comprises an indication of support for a Hypermedia as the Engine of Application State (HATEOAS) format. In one embodiment, the HATEOAS format is the 3gppHal+json format. In one embodiment, sending the information about the one or more services exposed by the first NF to the second NF comprises sending the information in a HATEOAS document that contains a number of link relations that correspond to the one or more services exposed by the first NF and base Uniform Resource Indicators (URIs) of the one or more services, wherein the base URIs comprise API major versions of the one or more services.

In one embodiment, the information about the one or more services exposed by the first NF comprises API versions of the one or more services exposed by the first NF. In one embodiment, the information about the one or more services exposed by the first NF further comprises one or more additional parameters. In one embodiment, the one or more additional parameters comprise load, status, or both load and status.

Corresponding embodiments of a first NF for a core network of a cellular communications system are also disclosed. In one embodiment, a first NF for a core network of a cellular communications system is adapted to receive, from a second NF, a request for services exposed by the first NF. The first NF is further adapted to, responsive to receiving the request, send, to the second NF, information about one or more services exposed by the first NF, wherein the first NF is a Network Repository Function, NRF, (<NUM>; <NUM>) and the second NF is an NF service consumer.

In one embodiment, a network node that implements a first NF for a core network of a cellular communications system comprises processing circuitry configured to cause the network node to receive, from a second NF, a request for services exposed by the first NF. The processing circuitry is further configured to cause the network node to, responsive to receiving the request, send, to the second NF, information about one or more services exposed by the first NF, wherein the first NF is a Network Repository Function, NRF, and the second NF is an NF service consumer.

Embodiments of a method performed by a second NF in a core network of a cellular communications system are also disclosed. In one embodiment, a method performed by a second NF in a core network of a cellular communications system comprises sending, to a first NF, a request for services exposed by the first NF. The method further comprises, responsive to sending the request, receiving, from the first NF, information about one or more services exposed by the first NF. In one embodiment, the information about one or more services exposed by the first NF includes API versions of the one or more services.

The first NF is an NRF, and the second NF is an NF service consumer. In one embodiment, the first NF is an hNRF in an hPLMN of a particular UE, and the second NF is a vNRF in a vPLMN of the particular UE.

In one embodiment, sending the request comprises sending the request to a bootstrapping service of the first NF. In one embodiment, the first NF is an NRF, and the bootstrapping service is separate from a discovery service of the NRF. In one embodiment, the request is an HTTP GET request addressed to {nrfApiRoot}/bootstrapping, where {nrfApiRoot} is a concatenation of a scheme component and an authority component of the NRF. In another embodiment, the request is an HTTP GET request addressed to https://nrf. 3gppnetwork. org/bootstrapping, where "MNC" is a MNC of a particular UE associated with the request and "MCC" is a MCC of the particular UE. In one embodiment, the request comprises an indication of support for a HATEOAS format. In one embodiment, the HATEOAS format is the 3gppHal+json format. In one embodiment, receiving the information about the one or more services exposed by the first NF comprises receiving the information in a HATEOAS document that contains a number of link relations that correspond to the one or more services exposed by the first NF and base URIs of the one or more services, wherein the base URIs comprise API major versions of the one or more services.

Corresponding embodiments of a second NF for a core network of a cellular communications system are also disclosed. In one embodiment, a second NF for a core network of a cellular communications system is adapted to send, to a first NF, a request for services exposed by the first NF. The second NF is further adapted to, responsive to sending the request, receive, from the first NF, information about one or more services exposed by the first NF, wherein the first NF is a Network Repository Function, NRF, and the second NF is an NF service consumer.

In one embodiment, a network node that implements a second NF for a core network of a cellular communications system comprises processing circuity configured to cause the network node to send, to a first NF, a request for services exposed by the first NF. The processing circuitry is further configured to cause the network node to, responsive to sending the request, receive, from the first NF, information about one or more services exposed by the first NF, wherein the first NF is a Network Repository Function, NRF, and the second NF is an NF service consumer.

Radio Access Node: As used herein, a "radio access node" or "radio network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals.

Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. It is proposed to define a version-independent bootstrapping service for the NRF (and similarly for the NSSF) that can be invoked by NFs in a visited Public Land Mobile Network (PLMN) (vPLMN) (i.e., by a visited NRF (vNRF) and a visited NSSF (vNSSF)) so the actual versions (and potentially other service parameters) can be learned by the invoker. The returned information will be defined following the principle of Hypermedia as the Engine of Application State (HATEOAS) in order to accommodate one of the main Representational State Transfer (REST) design goals for the 3GPP core network Application Programming Interfaces (APIs).

In one embodiment, a bootstrapping service is provided that allows NFs in a vPLMN to learn dynamically about the services exposed by NFs in a home PLMN (hPLMN) that are not discovered by means of the NRF discovery service. Rather than relying on static configuration, the NFs can get initial information that allows them to invoke further services such as the NRF discovery service on the hPLMN.

Certain embodiments may provide one or more of the following technical advantage(s). The principles described in the present disclosure provide several advantages to the operation of a network including:.

<FIG> illustrates one example of a cellular communications system <NUM> in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system <NUM> is a <NUM> System (5GS) including a NR RAN. In this example, the RAN includes base stations <NUM>-<NUM> and <NUM>-<NUM>, which in <NUM> NR are referred to as gNBs, controlling corresponding (macro) cells <NUM>-<NUM> and <NUM>-<NUM>. The base stations <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as base stations <NUM> and individually as base station <NUM>. Likewise, the (macro) cells <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as (macro) cells <NUM> and individually as (macro) cell <NUM>. The RAN may also include a number of low power nodes <NUM>-<NUM> through <NUM>-<NUM> controlling corresponding small cells <NUM>-<NUM> through <NUM>-<NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells <NUM>-<NUM> through <NUM>-<NUM> may alternatively be provided by the base stations <NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as low power nodes <NUM> and individually as low power node <NUM>. Likewise, the small cells <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as small cells <NUM> and individually as small cell <NUM>. The cellular communications system <NUM> also includes a core network <NUM>, which in the 5GS is referred to as the <NUM> Core (5GC). The base stations <NUM> (and optionally the low power nodes <NUM>) are connected to the core network <NUM>.

<FIG> illustrates a wireless communication system represented as a <NUM> network architecture composed of core NFs, where interaction between any two NFs is represented by a point-to-point reference point/interface. <FIG> can be viewed as one particular implementation of the system <NUM> of <FIG>.

Seen from the access side the <NUM> network architecture shown in <FIG> comprises a plurality of UEs <NUM> connected to either a RAN <NUM> or an Access Network (AN) as well as an AMF <NUM>. Typically, the R(AN) <NUM> comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in <FIG> include a NSSF <NUM>, an AUSF <NUM>, a UDM <NUM>, the AMF <NUM>, a SMF <NUM>, a PCF <NUM>, and an Application Function (AF) <NUM>.

Reference point representations of the <NUM> network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE <NUM> and AMF <NUM>. The reference points for connecting between the AN <NUM> and AMF <NUM> and between the AN <NUM> and UPF <NUM> are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF <NUM> and SMF <NUM>, which implies that the SMF <NUM> is at least partly controlled by the AMF <NUM>. N4 is used by the SMF <NUM> and UPF <NUM> so that the UPF <NUM> can be set using the control signal generated by the SMF <NUM>, and the UPF <NUM> can report its state to the SMF <NUM>. N9 is the reference point for the connection between different UPFs <NUM>, and N14 is the reference point connecting between different AMFs <NUM>, respectively. N15 and N7 are defined since the PCF <NUM> applies policy to the AMF <NUM> and SMF <NUM>, respectively. N12 is required for the AMF <NUM> to perform authentication of the UE <NUM>. N8 and N10 are defined because the subscription data of the UE <NUM> is required for the AMF <NUM> and SMF <NUM>.

The 5GC network aims at separating user plane and control plane. The user plane carries user traffic while the control plane carries signaling in the network. In <FIG>, the UPF <NUM> is in the user plane and all other NFs, i.e., the AMF <NUM>, SMF <NUM>, PCF <NUM>, AF <NUM>, NSSF <NUM>, AUSF <NUM>, and UDM <NUM>, are in the control plane. Separating the user and control planes guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from control plane functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

The core <NUM> network architecture is composed of modularized functions. For example, the AMF <NUM> and SMF <NUM> are independent functions in the control plane. Separated AMF <NUM> and SMF <NUM> allow independent evolution and scaling. Other control plane functions like the PCF <NUM> and AUSF <NUM> can be separated as shown in <FIG>. Modularized function design enables the 5GC network to support various services flexibly.

<FIG> illustrates a <NUM> network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the <NUM> network architecture of <FIG>. However, the NFs described above with reference to <FIG> correspond to the NFs shown in <FIG>. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In <FIG> the service based interfaces are indicated by the letter "N" followed by the name of the NF, e.g. Namf for the service based interface of the AMF <NUM> and Nsmf for the service based interface of the SMF <NUM>, etc. The NEF <NUM> and the NRF <NUM> in <FIG> are not shown in <FIG> discussed above. However, it should be clarified that all NFs depicted in <FIG> can interact with the NEF <NUM> and the NRF <NUM> of <FIG> as necessary, though not explicitly indicated in <FIG>.

Some properties of the NFs shown in <FIG> and <FIG> may be described in the following manner. The AMF <NUM> provides UE-based authentication, authorization, mobility management, etc. A UE <NUM> even using multiple access technologies is basically connected to a single AMF <NUM> because the AMF <NUM> is independent of the access technologies. The SMF <NUM> is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF <NUM> for data transfer. If a UE <NUM> has multiple sessions, different SMFs <NUM> may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF <NUM> provides information on the packet flow to the PCF <NUM> responsible for policy control in order to support Quality of Service (QoS). Based on the information, the PCF <NUM> determines policies about mobility and session management to make the AMF <NUM> and SMF <NUM> operate properly. The AUSF <NUM> supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM <NUM> stores subscription data of the UE <NUM>. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

<FIG> shows a call flow diagram illustrating a process for interaction between a visited NF (vNF) <NUM> in a vPLMN <NUM> and a home NF (hNF) (not shown) in an hPLMN <NUM> via a vNRF <NUM> / hNRF <NUM>. In step <NUM>, the vNF <NUM> determines the address of the vNRF <NUM> by means of local configuration, which is feasible given that it is a configuration local to the vPLMN <NUM>, and sends a discovery request (including a GET request for the determined address) to the vNRF <NUM>. In step <NUM>, the vNRF <NUM>, after determining that it does not have any static configuration or prior information about the hPLMN <NUM>, builds a bootstrapping URI of the hNRF <NUM> as follows:.

In step <NUM>, the hNRF <NUM> answers with a HATEOAS document containing a number of link relations corresponding to the different services and their base URIs (which include the API major version), and maybe additional useful parameters ("status" and "load" below). An example response is shown below:
HTTP/<NUM><NUM> OK
Content-Type: application/3gppHal+json
{
"status": "ACTIVE",
"load": "<NUM>%",
"_links": {
"self": {
"href": "/bootstrapping"
},
"management": {
"href": "/nnrf-nfm/v1"
},
"discovery": {
"href": "/nnrf-disc/v2"
},
"oauth2": {
"href": "/oauth2/token"
}
}
}
As shown in the response, the hNRF <NUM> indicates that version <NUM> (v1) of the management API is available, while version <NUM> (v2) of the discovery API is available.

In step <NUM>, the vNRF <NUM> uses the bootstrapping information received to build the effective Uniform Resource Indicators (URIs) used for the different services exposed by the hNRF <NUM>. As shown, the vNRF <NUM> uses the latest version of the discovery API available, which is version <NUM> (v2). If the bootstrapping described above were not available, the vNRF <NUM> would not know which APIs were implemented by the hNRF <NUM> (e.g., which versions of the APIs) and thus would be forced to rely on static configuration (Service-Level Agreement (SLA)) or default to the lowest possible version of the desired API, for example, version <NUM> (v1). In step <NUM>, the hNRF <NUM> returns the search result of the discovery to the vNRF <NUM>. In step <NUM>, the vNRF <NUM> returns the search result of the discovery to the vNF <NUM>.

While the foregoing concepts are discussed as they relate to the discovery of available services in a home network by a network node in a visiting network, the concepts are also applicable between NFs in the same network. For example, an NF within a PLMN may communicate with an NRF in the same PLMN. Conventionally, an operator would configure the NF with an address, URIs, and API version(s) supported by the NRF. This means that every time a new API version is rolled out by the NRF, the NF must be re-configured to communicate with the NRF using the new API version. Using the bootstrapping process discussed above with respect to <FIG> within the same PLMN allows NFs in a PLMN to dynamically adapt to changes in an NRF in the same PLMN without reconfiguration.

<FIG> is a schematic block diagram of a network node <NUM> according to some embodiments of the present disclosure. The network node <NUM> may be, for example, a network node that implements a core network entity or core network function such as, e.g., the vNF service consumer of <FIG>, the vNRF of <FIG>, or the hNRF of <FIG>. As illustrated, the network node <NUM> includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. The one or more processors <NUM> operate to provide one or more functions of a network node <NUM> as described herein (e.g., one or more functions of the vNF service consumer of <FIG>, one or more functions of the vNRF of <FIG>, or one or more functions of the hNRF of <FIG>, as described above). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory <NUM> and executed by the one or more processors <NUM>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the network node <NUM> according to some embodiments of the present disclosure. As used herein, a "virtualized" network node is an implementation of the network node <NUM> in which at least a portion of the functionality of the network node <NUM> (e.g., one or more functions of the vNF service consumer of <FIG>, one or more functions of the vNRF of <FIG>, or one or more functions of the hNRF of <FIG>, as described above) is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node <NUM> includes one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>.

In this example, functions <NUM> of the network node <NUM> described herein (e.g., one or more functions of the vNF service consumer of <FIG>, one or more functions of the vNRF of <FIG>, or one or more functions of the hNRF of <FIG>, as described above) are implemented at the one or more processing nodes <NUM> or distributed across two or more processing nodes <NUM> in any desired manner. In some particular embodiments, some or all of the functions <NUM> of the network node <NUM> described herein (e.g., one or more functions of the vNF service consumer of <FIG>, one or more functions of the vNRF of <FIG>, or one or more functions of the hNRF of <FIG>, as described above) are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) <NUM>.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node <NUM> or a node (e.g., a processing node <NUM>) implementing one or more of the functions <NUM> of the network node <NUM> in a virtual environment according to any of the embodiments described herein is provided.

<FIG> is a schematic block diagram of the network node <NUM> according to some other embodiments of the present disclosure. The network node <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the network node <NUM> described herein (e.g., one or more functions of the vNF service consumer of <FIG>, one or more functions of the vNRF of <FIG>, or one or more functions of the hNRF of <FIG>, as described above). This discussion is equally applicable to the processing node <NUM> of <FIG> where the modules <NUM> may be implemented at one of the processing nodes <NUM> or distributed across multiple processing nodes <NUM> and/or distributed across two or more of the processing nodes <NUM>.

One example implementation of at least some aspects of the solutions described herein is shown below as changes to 3GPP Technical Specification (TS) <NUM> V16.

The NRF offers an Nnrf_Bootstrapping service to let NF Service Consumers of the NRF know about the services endpoints it supports, by using a version-independent URI endpoint that does not need to be discovered by using a Discovery service.

This service shall be used in inter-PLMN scenarios where the NRF in a PLMN-A needs to invoke services from an NRF in PLMN-B, when there is no pre-configured information indicating the version of the services deployed in PLMN-B.

This service may also be used in intra-PLMN scenarios, to avoid configuring statically in the different NFs information about the service versions deployed in the NRF to be used by those NFs.

The services operations defined for the Nnrf_Bootstrapping service are as follows:.

This service operation is used by an NF Service Consumer to request bootstrapping information from the NRF.

URIs of this API shall have the following root:
{nrfApiRoot}
where {nrfApiRoot} represents the concatenation of the "scheme" and "authority" components of the NRF, as defined in IETF RFC <NUM> [<NUM>].

HTTP/<NUM>, as defined in IETF RFC <NUM> [<NUM>], shall be used as specified in clause <NUM> of 3GPP TS <NUM> [<NUM>].

HTTP/<NUM> shall be transported as specified in clause <NUM> of 3GPP TS <NUM> [<NUM>].

HTTP messages and bodies this API shall comply with the OpenAPI [<NUM>] specification contained in Annex A.

The HTTP headers as specified in clause <NUM> of IETF RFC <NUM> [<NUM>] shall be supported, with the exception that there shall not be "Authorization" HTTP request header in the access token request.

The following content types shall be supported:.

In this release of this specification, no custom headers specific to the Nnrf_Bootstrapping Service API are defined. For 3GPP specific HTTP custom headers used across all service-based interfaces, see clause <NUM>. <NUM> of 3GPP TS <NUM> [<NUM>].

The structure of the Resource URIs of the Nnrf_Bootstrapping service is shown in <FIG>. <NUM>-<NUM>.

Table <NUM>. <NUM>-<NUM> provides an overview of the resources and applicable HTTP methods.

This resource represents a collection of links pointing to other services exposed by NRF.

This resource is modelled as the Document resource archetype (see clause C. <NUM> of 3GPP TS <NUM> [<NUM>]).

Resource URI: {nrfApiRoot}/bootstrapping.

This resource shall support the resource URI variables defined in table <NUM>. <NUM>-<NUM>.

This method retrieves a list of links pointing to other services exposed by NRF. This method shall support the URI query parameters specified in table <NUM>. <NUM>-<NUM>.

This method shall support the request data structures specified in table <NUM>. <NUM>-<NUM> and the response data structures and response codes specified in table <NUM>. <NUM>-<NUM>.

There are no custom operations defined without any associated resources for the Nnrf_Bootstrapping service in this release of the specification.

There are no notifications defined for the Nnrf_Bootstrapping service in this release of the specification.

This clause specifies the application data model supported by the API.

Table <NUM>. <NUM>-<NUM> specifies the data types defined for the Nnrf_Bootstrapping service-based interface protocol.

Table <NUM>. <NUM>-<NUM> specifies data types re-used by the Nnrf_Bootstrapping service-based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nnrf service-based interface.

This clause defines the structures to be used in resource representations.

This clause defines simple data types and enumerations that can be referenced from data structures defined in the previous clauses.

This clause describes the possible relation types defined within NRF API. See clause <NUM>. <NUM> of 3GPP TS <NUM> [<NUM>] for the description of the relation types.

openapi: <NUM>. <NUM>
info:
version: '<NUM>. alpha-<NUM>'
title: 'NRF Bootstrapping'
description: |
NRF Bootstrapping. © <NUM>, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI,
TSDSI, TTA, TTC). All rights reserved. externalDocs:
description: 3GPP TS <NUM> V16. <NUM>; <NUM> System; Network
Function Repository Services; Stage <NUM>
url: 'http://www. org/ftp/Specs/archive/29_series/<NUM>/'
paths:
/bootstrapping:
get:
summary: Bootstrapping Info Request
operationId: BootstrappingInfoRequest
tags:
- Bootstrapping Request
responses:
'<NUM>':
description: Successful Bootstrapping Request
content:
application/3gppHal+json:
schema:
$ref: '#/components/schemas/BootstrappingInfo'
'<NUM>':
$ref:
'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref:
'TS29571_CommonData. yaml#/components/responses/<NUM>'
default:
$ref:
'TS29571_CommonData. yaml#/components/responses/default'
components:
schemas:
BootstrappingInfo:
type: object
required:
- _links
properties:
status:
$ref: '#/components/schemas/Status'
_links:
type: object
description: 'Map of link objects where the keys are
the link relations defined in 3GPP TS <NUM> clause <NUM>. <NUM>'
additionalProperties:
$ref:
'TS29571_CommonData. yaml#/components/schemas/LinksValueSchema'
minProperties: <NUM>
Status:
anyOf:
- type: string
enum:
- OPERATIVE
- NON_OPERATIVE
- type: string.

Claim 1:
A method performed by a first Network Function, NF, in a core network (<NUM>) of a cellular communications system (<NUM>), the method comprising:
receiving (Fig. <NUM>, step <NUM>; Fig. <NUM>, step <NUM>), from a second NF, a request for services exposed by the first NF; and
responsive to receiving (Fig. <NUM>, step <NUM>; Fig. <NUM>, step <NUM>) the request, sending (Fig. <NUM>, step <NUM>; Fig. <NUM>, step <NUM>), to the second NF, information about one or more services exposed by the first NF;
wherein the first NF is a Network Repository Function, NRF, (<NUM>; <NUM>) and the second NF is an NF service consumer.