Patent Description:
<NPL>)" relates to roaming and non-roaming scenarios in all aspects, including interworking between 5GS and EPS, mobility within 5GS, QoS, policy control and charging, authentication and in general <NUM> System wide features.

<NPL>" relates to the security architecture, i.e., the security features and the security mechanisms for the <NUM> System and the <NUM> Core, and the security procedures performed within the <NUM> System including the <NUM> Core and the <NUM> New Radio.

<NPL>" relates to the Stage <NUM> procedures and Network Function Services for the <NUM> system architecture described in the TS <NUM> and the policy and charging control framework described in TS <NUM>.

3GPP is currently standardizing the <NUM> Core Network as part of the overall <NUM> System architecture. The <NUM> Core Network is composed of a set of relevant functional entities, called Network Functions (NFs). <NUM> System Architecture may be defined as a Service Based Architecture (SBA) for the control plane, i.e. a system architecture in which the system functionality is achieved by a set of NFs providing services to other authorized NFs to access their services. Control Plane (CP) Network Functions in the <NUM> System architecture are based on SBA.

A NF service is one type of capability which may be exposed by an NF (NF Service Producer) to another authorized NF (NF Service Consumer) through a service-based interface (SBI). A NF service may support one or more NF service operation(s).

A service-based interface represents how the set of services is provided or exposed by a given NF. This is the interface where the NF service operations are invoked, and it is currently based on HTTP/<NUM> protocol.

<FIG> illustrates a <NUM> System reference architecture showing service-based interfaces used within the Control Plane. It will be appreciated that not all NFs are depicted.

The Network Repository Function (NRF) is a key NF within the 5GC SBA Framework that provides registration and discovery capabilities among the different NFs within the 5GC. In short, when a given NF (e.g. UDM type) registers a NF profile in the NRF, other NFs may discover it automatically by simply querying NRF to find NFs of a given type (e.g. UDM type).

The NRF also acts as an authorization server within, for example, an Oauth framework, so that a consumer NF wishing to request authorization to consume (or access) a service from a producer NF, may requests an access token from NRF.

<FIG> illustrates a method for requesting an access token.

In step <NUM>, the consumer NF registers with the NRF.

In step <NUM>, the consumer NF transmits an access token request to the NRF. The access token request may comprise an indication of one or more expected services (Expected NF Service Name(s)). The access token request also comprises an indication of the NF type expected for the producer NF of the expected services. The access token request further comprises an indication of the consumer NF type and an identification of the client.

In step <NUM>, the NRF may then generate an access token. The access token may comprise an indication of the scope of authorization of the token. This scope may include the service(s) authorized by the producer NF to the consumer NF, e.g. if NRF authorizes Subscriber Data Management Service (SDM service) and User Equipment Context Management service (UECM service), it will indicate so in the access token generated.

In step <NUM> the NRF transmits the access token to the consumer NF.

<FIG> illustrates an example of a consumer NF accessing a service using an access token.

In step <NUM>, the consumer NF transmits a service request to the producer NF including the access token. The request and access token are verified by the producer NF, in step <NUM>, and if the access token allows the use of the specific service requested (e.g. SDM), the service request will be accepted and in step <NUM> the producer NF may transmit a response to the consumer NF.

Further details are defined in the dependent claims.

According to some embodiments there is provided a method in a producer network function for registering one or more services that the producer network function is capable of providing at a network repository function, NRF. The method comprises transmitting a registration request to the NRF, wherein the registration request comprises registration information comprising: an indication of the one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type.

According to some embodiments there is provided a method in a consumer network function for requesting a service from a producer network function. The method comprising: transmitting a registration request to a network repository function, NRF, wherein the registration request comprises: an indication of one or more services that are expected to be consumed; an indication of resources and operations associated with each resource of the one or more services that are expected to be consumed; and an indication of the consumer network function type.

According to some embodiments there is provided a method in a network repository function for authorising a consumer network function to access services at a producer network function. The method comprises receiving a registration request from a producer network function, wherein the registration request comprises registration information comprising: an indication of one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type; and storing the registration information associated with an identity of the producer network function; receiving a registration request from a consumer network function, wherein the registration request comprises registration information comprising: an indication of one or more services that are expected to be consumed; and an indication of resources and operations associated with each resource of the one or more services that are expected to be consumed; and an indication of the consumer network function type; and storing the registration information associated with an identity of the consumer network function.

According to some embodiments there is provided a producer network function for registering one or more services that the producer network function is capable of providing at a network repository function, NRF. The producer network function comprises processing circuitry configured to: transmit a registration request to the NRF, wherein the registration request comprises registration information comprising: an indication of the one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type.

According to some embodiments there is provided a consumer network function for requesting a service from a producer network function. The consumer network function comprises processing circuitry configured to: transmit a registration request to a network repository function, NRF, wherein the registration request comprises: an indication of one or more services that are expected to be consumed; an indication of resources and operations associated with each resource of the one or more services that are expected to be consumed; and an indication of the consumer network function type.

According to some embodiments there is provided a network repository function for authorising a consumer network function to access services at a producer network function. The network repository function comprises processing circuitry configured to: receive a registration request from a producer network function, wherein the registration request comprises registration information comprising: an indication of one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type; and store the registration information associated with an identity of the producer network function; receive a registration request from a consumer network function, wherein the registration request comprises registration information comprising: an indication of one or more services that are expected to be consumed; and an indication of resources and operations associated with each resource of the one or more services that are expected to be consumed; and an indication of the consumer network function type; and store the registration information associated with an identity of the consumer network function.

According to some embodiments there is provided a method in a consumer network function for requesting a service from a producer network function. The method comprises: transmitting an access token request to a network repository function, NRF, wherein the access token request comprises an indication of one or more expected services; receiving an access token from the NRF, wherein the access token comprises an indication of authorised resources and operations associated with each resource of the one or more expected services; and transmitting a service request to a producer network function, wherein the service request comprises: the access token; and requested operation over a requested resource.

According to some embodiments there is provided a consumer network function for requesting a service from a producer network function. The consumer network function comprising processing circuitry configured to: transmit an access token request to a network repository function, NRF, wherein the access token request comprises an indication of one or more expected services; receive an access token from the NRF, wherein the access token comprises an indication of authorised resources and operations associated with each resource of the one or more expected services; and transmit a service request to a producer network function, wherein the service request comprises: the access token; and a requested operation over a requested resource.

According to some embodiments there is provided a method in a network repository function for authorising a consumer network function to access services at a producer network function. The method comprising: receiving a registration request from a producer network function, wherein the registration request comprises registration information comprising: an indication of one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type; and storing the registration information associated with an identity of the producer network function.

According to some embodiments there is provided a network repository function for authorising a consumer network function to access services at a producer network function. The network repository function comprises processing circuitry configured to: receive a registration request from a producer network function, wherein the registration request comprises registration information comprising: an indication of one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type; and store the registration information associated with an identity of the producer network function.

For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:.

The 3GPP usage of Oauth scope only allows for authorization of specific services (e.g. SDM), which includes authorization to use all resources owned by the service (Access and Mobility data, Session Management data, etc.). There is no possibility for authorizing only part of those resources which a particular service can provide (for example only authorizing for the use of Access and Mobility data and not Session Management data). Moreover, operations for those resources cannot be authorized at present.

For example, an SDM service may allow for the use of several resources (e.g. am-data, trace-data, smf-selection-data, sm-data etc.), but it may be desirable for not all the resources to be granted to all NFs for whom the service is authorized.

For example, a Unified Data Management (UDM) NF might be required to grant the access to the Access and Mobility data (am-data) of a user (e.g. Maximum Bit-Rate) only to certain NFs (e.g. AMF).

The consumer NFs may be granted the use of the SDM service (with all associated resources), but it may be desirable for access to the types of SDM data to be more granular (for example, the access may be provided per resource, such as MSISDN and operation (read/write)). In other words, the Oauth scope of the authorization in 5GC is per service, not per resource/data type within the service and operation(s) per resource/data type.

Furthermore, 3GPP TS <NUM> includes a requirement for the UDM to authorize whether UDM consumer are authorized to retrieve specific subscription data types over e.g. Nudm_SDM_Get operation, see below:.

Description: Consumer NF gets the subscriber data indicated by the subscription data type input from UDM. The UDM shall check the requested consumer is authorized to get the specific subscription data requested. In case of NF consumer is SMF, the subscriber data may contain e.g. Allowed PDU Session Type(s), Allowed SSC mode(s), default 5QI/ARP, Subscribed S-NSSAI(s).

Inputs, Required: NF ID, Subscription data type(s), Key for each Subscription data type(s).

Outputs, Required: The consumer NF gets the requested subscription data.

There is however no mechanism defined for the UDM to perform such authorization at SDM resource level.

One option may be to transmit an access token request with the list of resources and operations that are requested to be authorised. But this is not a future-proof solution as the list of resources may be extensive, and, in the future may continue to grow. For the same reasons, the list of resources and operations may be dynamic, and this could result in all NFs requesting a new list every time it is updated.

According to embodiments described herein, when the service consumer NF (e.g. an AMF) registers in NRF (e.g. at NF startup), as part of the registration information (e.g. in an NF profile), it may include an indication of the consumer NF subtype or category (e.g. AMF subtype or AMF category) for each service(s) that the consumer NF intends to use/consume (e.g. nudm-sdm).

An additional scope information may be configured in the NF consumer as part of the operator's network configuration, and may only be configured if the operator requires different or additional treatment (e.g. for resources authorization) of one subtype of NF compared to other NFs of the same type (e.g. NF type=AMF, NF subtype=X).

It will be appreciated that the NRF cannot in any case base on the NF id when it comes to local preconfiguration, since in cloud native deployments, this NF Id might not be permanent, but auto-generated every time the NF starts up.

In some embodiments, when the producer NF (e.g. an UDM) registers in the NRF (e.g. at NF startup), as part of the registration information (for example in an NF profile), the producer NF may include an indication of resources and operations associated with each resource of one or more services that are allowed per network function consumer type (and optionally subtype). This additional scope information may be configured in the producer NF as part of the operator's network configuration.

In some embodiments, when the consumer NF requests an access token, the NRF verifies the request and generates an access token. The access token request comprises: <NUM>) the NF type of the NF consumer (e.g. AMF); <NUM>) an indication of the services expected to access (e.g. nudm-sdm); <NUM>) optionally an indication of the subtype of the consumer NF; and <NUM>) the target NF type (e.g. UDM), also known in Oauth as the "audience".

The NRF checks if there is any indication of the subtype in the access token request. If there is no additional scope information in the access token request, the NRF may generate an access token with a preconfigured allowed resources and operations associated with each resource of the expected services for the NF type received, e.g. if the NF type is AMF (Access and Mobility Management Function), the preconfigured allowed resources could be am-data (access and mobility data). Hence, the generated access token may comprise an indication of authorised resources and operations associated with each resource of the one or more expected services. The access token may only be generated if there is a proper audience i.e. if there is at least one instance of target NF type (e.g. one instance of UDM NF type) which has previously registered appropriate allowed operations and resources for the consumer NF type.

Otherwise, if an indication of a subtype is present in the access token request, the NRF, prior to the access token generation, may check that there is a suitable audience, i.e. there is at least one NF instance of target NF type (e.g. UDM) which has registered that the expected service would be allowed for the subtype present in the access token request. In this example, the NF Subtype=X identified in the producer NF (e.g. UDM) is allowed use of a set of preconfigured resources/data in the producer NF and its allowed operations (read, write). The generated access token may then include the preconfigured resources and operations for the expected services.

In some embodiments, when the NF service consumer intends to request a service from the NF service producer, it may first discover (i.e. queries NRF) which NF instance produces the requested service for a give NF type (e.g. UDM) and also supports the authorized resources and operations indicated in the access token. In this discovery, NRF may return the set of NFs of the NF type (e.g. UDM) which had previously registered the support of authorizing the authorized resources and operations for the consumer NF type and optionally NF subtype.

In some embodiments, the NF service producer may verify the access token and make use of the indication of the authorized resources and operations in the access token to authorize that the service request and the resources being requested can be accessed by the requesting consumer NF.

It will be appreciated that, in order for an NF in a system to be discoverable via the NRF, the NF may first register at the NRF. <FIG> and <FIG> illustrate registration processes with the NRF.

<FIG> illustrates an example signalling diagram for a consumer NF registering with an authorisation server (in this example an NRF).

In step <NUM>, the consumer NF <NUM> transmits a registration request to a network repository function, NRF <NUM>. The registration request comprises registration information. The registration information comprises an indication of the consumer network function type (NF type). The registration information may also comprise an identification of the consumer NF (NF Identifier). The registration information may also comprise an indication of the consumer network function subtype (NF sub-type). For example, an NF may be of a UDM type and a UDM-ARPF sub-type.

In some examples, the registration information also comprises an indication of one or more services that are expected to be consumed by the consumer NF <NUM>; and an indication of resources and operations associated with each resource of the one or more services that are expected to be consumed. This may be included in the registration information in circumstances. Including the one or more services that are expected to be consumed by the consumer in the registration information allows the NRF to revoke authorization to a service consumer NF if a given scope of authorization is not existing any more in the network.

In step <NUM>, the NRF <NUM> stores the registration information associated with an identity of the consumer NF <NUM>.

In step <NUM>, the NRF <NUM> may indicate to the consumer NF <NUM> that the registration has been made.

<FIG> is an example signalling diagram illustrating a producer NF <NUM> registering one or more services that the producer NF <NUM> is capable of providing as registered at a network repository function.

In step <NUM>, the producer NF <NUM> transmits a registration request to the NRF <NUM>, wherein the registration request comprises registration information comprising: an indication of the one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type (Additional Scope Info per NF Type).

In some examples, the indication of resources and operations associated with each resource of the one or more services that are allowed is registered per network function consumer type and subtype (NF sub-type). The consumer subtype may only be transmitted in circumstances where they may be a need to differentiate amongst different NFs of the same type for determining access authorisation for each resource and operation.

The registration information may further comprise one or more of: an indication of the NF type of the producer NF <NUM> and an identification of the producer NF <NUM>.

In step <NUM>, the NRF <NUM> stores the registration information associated with an identity of the producer NF.

In step <NUM>, the NRF <NUM> may indicate to the producer NF <NUM> that the registration has been made.

In some examples, once the consumer NF <NUM> and the producer NF <NUM> have registered with the NRF <NUM>, the consumer NF requests an access token from the NRF <NUM>.

<FIG> is an example signalling diagram illustrating how the consumer NF <NUM> requests an access token from the NRF <NUM>.

In step <NUM>, the consumer NF <NUM> transmits an access token request to the NRF <NUM>. The access token request may, in some examples, comprise an indication of one or more expected services (Expected NF Service name(s)).

In some examples, the access token request comprises an indication of a target network function type (Producer NF type) expected to provide the expected services. In some examples, the access token request comprises an indication of the consumer NF type (Consumer NF type). In some examples, the access token request comprises an indication of requested resources and operations associated with each resource of the one or more expected services ("additional scope" info).

In step <NUM>, the NRF <NUM> authorises the consumer NF and generates an access token. In other words, step <NUM> may comprise determining, based on the requesting consumer NF type and on stored indications of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type, which are the authorised resources and operations associated with each resource of the one or more expected services.

In some examples, the step of determining comprises determining the authorised resources and operations associated with each resource of the one or more expected services based on stored registered information associated with one or more producer network functions, and the access token request. In some examples, the determination is further based on stored registered information associated with the requesting consumer network function type and optionally consumer network function subtype.

For example, when the NRF <NUM> receives the access token request that indicates the expected services that the consumer NF is requesting access for, the NRF <NUM> may check the requested expected services and, if present the requested additional scope for those expected services against the stored registration information in NF profiles for producer NFs of the target NF type to ascertain whether the consumer NF type (and optionally subtype) is allowed access to those expected services, and if so which resources and operations associated with each resource of the expected services is the consumer NF type allowed access to.

It will be appreciated that the NRF may not authorise all services and additional scope requested by the consumer NF in the access token request. For example, the authorised resources and operations associated with each resource of the one or more expected services may be a subset of the requested resources and operations associated with each resource of the one or more expected services or a subset of all resources and operations associated with each resource of the one or more expected services (if for example no additional scope is specified in the access token request).

In generating the access token, the NRF <NUM> may digitally sign the access token based on a shared secret or private key.

In step <NUM> the NRF <NUM> transmits an access token to the consumer NF <NUM>, wherein the access token comprises an indication of authorised resources and operations associated with each resource of the one or more expected services.

In some examples, the access token further comprises one or more of: an indication of a target network function type, an identification of the NRF <NUM>, and identification of the consumer NF <NUM>, an expiration time for the access token.

It will be appreciated that in some examples, the consumer NF may not be authorised to access any of the expected services (or any of the requested additional scope for the expected services). In these examples, the NRF <NUM> may response with an error response.

<FIG> is a signalling diagram illustrating an example of how the consumer NF <NUM> accesses the services of the producer NF <NUM>.

In step <NUM>, the consumer NF transmits a service request to a producer network function, wherein the service request comprises: the access token; and a requested operation over a requested resource.

In step <NUM> the producer NF <NUM> may then verify the integrity of the access token. For example, the producer NF <NUM> may check that the access token was generated by the NRF <NUM>. For example, the producer NF may verify the signature in the access token using the private key or shared secret.

The producer NF <NUM> may also, responsive to the access token generated by the NRF and received in the service request, check that a target network function type in the access token is a type of the producer NF <NUM>.

As the access token comprises an indication of authorised resources and operations associated with each resource of the one or more services, the producer NF <NUM> may check that the requested operation over the requested resource falls within the authorised resources and operations associated with each resource of the one or more services.

If the requested operation over the request resource does fall within the authorised resources and operations associated with each resource of the one or more services, then the producer NF <NUM> may determine that the consumer NF is authorised to use the requested operation over the requested resource, and may execute the requested operation over the requested resource.

For example, the producer NF <NUM> may transmit a NF service response to the consumer NF <NUM> in step <NUM>.

In some examples, the producer NF <NUM> may also check that the expiration timer in the access token has not expired before executing the requested operation.

<FIG> and <FIG> are a signalling diagram illustrating an example of registration of a UDM NF <NUM> acting as a producer NF and an AMF NF <NUM> acting as a consumer NF with an NRF <NUM>.

The UDM NF <NUM> has a NF profile preconfigured. The NF profile may comprise an indication of supported additional scope information per service name list. This indication may contain the additional scope information (e.g. the resources and operations associated with each resource of the one or more services provided by the UDM that are allowed registered per network function consumer type (and optionally subtype)).

In step <NUM>, the UDM NF <NUM> is instantiated.

In step <NUM>, the UDM transmits a registration request to the NRF <NUM>. This step may be similar to step <NUM> of <FIG>. In this example, the one or more services provided by the UDM NF comprises only nudm-sdm (as an example illustrated). The indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type comprises: any operation utilising the amData for the NF type "UDM". It will be appreciated that more operations and resources may be allowed for different consumer NF types and optionally subtypes. The allowed resources and operations for NF type "UDM" is only illustrated here for simplicity.

In step <NUM>, the NRF stores the registration information similarly to as described in step <NUM> of <FIG>,.

In step <NUM>, the NRF <NUM> may indicate to the UDM <NUM> that the registration has been made (similarly to step <NUM> of <FIG>).

In step <NUM> the AMF NF <NUM> is instantiated. The AMF NF may have a NF profile preconfigured. In some examples, the NF profile may be configured with an indication of a subtype of the AMF NF. In this example, since the operator's network does not require differentiation between AMF NFs when consuming a given service, there may be no indication of the subtype of the AMF NF.

In step <NUM> the AMF NF <NUM> transmits a registration request to the NRF <NUM>. In this example, the registration request comprises registration information comprising an indication of the consumer network function type (NF type) and an identification of the consumer NF (AMF NF Identifier) (similarly to as described in step <NUM> of <FIG>).

In step <NUM>, the NRF <NUM> stores the registration information as an AMF NF profile (similarly to as described in step <NUM> of <FIG>).

In step <NUM> the NRF <NUM> may indicate to the AMF NF <NUM> that the registration has been made (similar to as described in step <NUM> of <FIG>).

<FIG> are an example signalling diagram illustrating how the AMF NF <NUM> requests authorisation and accesses specific services.

In step <NUM>, the AMF NF <NUM> transmits an access token request to the NRF <NUM> (similarly to as described in step <NUM> of <FIG>). In this example, the access token request comprises an indication of a target NF type, which in this example is "UDM". In this example, the access token request does not comprise an indication of one or more expected services (Expected NF Service name(s)). This may be because the one or more expected services requested by AMF NFs is preconfigured, for example at the NRF. The NRF may therefore already be aware of what services the AMF is requesting without it having to be specified in the access token request.

The access token request may also comprise an indication of the AMF NF identifier and the consumer NF type, which in this example is "AMF".

In step <NUM>, the NRF checks the access token request for the presence of an indication of one or more expected services (Expected NF Service name(s)), and optionally an indication of requested resources and operations associated with each resource of the one or more expected services.

In this example, as there is no indication of resources and operations associated with each resource of the one or more expected services in the access token request, the NRF may then check for a local configuration of resources and operations associated with each resource of the one or more expected services in the access token request associated with the NF type "AMF". In this example, it may be preconfigured at the NRF that NF type "AMF" is preconfigured to request access to the "amData" resource (access and management data) for the service "nudm-sdm". In other words, it may be expected that the AMF requests access to the access and management data resource.

Another NF type, for example "SMF", may be preconfigured to request access to a different resource, for example "smData" (session management data). In other words, it may be expected that an SMF NF would request access to session management data.

The NRF may also check that there is at least one registered producer NF of the target NF type (e.g. "UDM") that has associated registration information that indicates that the NF type "AMF" would be authorised to access the "amData" resource.

In step <NUM>, the NRF <NUM> then generates an access token (similarly to as described with reference to step <NUM> of <FIG>).

In step <NUM>, the NRF <NUM> transmits the access token to the AMF NF <NUM> (similarly to as described with reference to step <NUM> of <FIG>). The access token comprises an indication of authorised resources and operations associated with each resource of the one or more expected services (which in this example comprises the resource "amData").

In some examples, the access token further comprises one or more of: an indication of a target network function type, an identification of the NRF <NUM>, and identification of the AMF NF <NUM>, an expiration time for the access token.

In this example, in step <NUM>, the AMF NF <NUM> transmits, to the NRF <NUM>, a discovery request comprising an indication of the target network function type (e.g. "UDM") and an indication of authorised resources and operations associated with each resource of the one or more expected services (e.g. "amData").

In step <NUM>, the NRF <NUM> locates one or more producer network functions of the target network function type capable of providing the authorised resources and operations associated with each resource of the one or more expected services. In this example, the NRF may locate any stored NF profiles for NFs of the type "UDM" for which the resource "amData" is authorised for use by NFs of the type "AMF".

In step <NUM>, the NRF <NUM> transmits a discovery response to the AMF NF <NUM> comprising the one or more producer network functions of the target network function type capable of providing the authorised resources and operations associated with each resource of the one or more expected services.

In step <NUM>, the AMF NF <NUM> selects a producer network function from the one or more producer network functions of the discovery response.

In step <NUM>, the AMF NF <NUM> transmits a service request to a selected UDM NF <NUM>. The service request comprises: the access token; and a requested operation over a requested resource (similarly to as described in step <NUM> of <FIG>). In this example, the requested operation is "GET" and the requested resource is "amData".

In step <NUM> the UDM NF <NUM> may then verify the integrity of the access token. For example, the UDM NF <NUM> may check that the access token was generated by the NRF <NUM>. For example, the UDM NF <NUM> may verify the signature in the access token using the private key or shared secret.

The UDM NF <NUM> may also check that the target NF type in the service request is "UDM".

In step <NUM>, the UDM NF <NUM> checks that the requested operation (e.g. "GET") over the requested resource (e.g. "amData") falls within the authorised resources and operations associated with each resource of the one or more services (e.g. the authorised resources and operations indicated in the access token) (Similarly to as in step <NUM> of <FIG>).

In this example as the access token indicates that the resources "amData" are authorised, it may be assumed that all operations (e.g. "GET") utilising the resources "amData" are authorised. The UDM NF <NUM> may then grant access to the requested operation over the requested resource.

In step <NUM> the UDM NF <NUM> transmits a NF service response to the AMF NF <NUM> (similarly to as in step <NUM> of <FIG>).

<FIG> and <FIG> are a signalling diagram illustrating an example of registration of an IMS Application Server (AS) <NUM> acting as a consumer NF and a Home Subscriber Server (HSS) <NUM> acting as a producer NF with an NRF <NUM>.

The HSS <NUM> has a NF profile preconfigured. The NF profile may comprise an indication of supported additional scope information per service name list. This indication may contain the additional scope information (e.g. the resources and operations associated with each resource of the one or more services provided by the HSS that are allowed registered per network function consumer type (and optionally subtype)).

In step <NUM>, the HSS <NUM> is instantiated.

In step <NUM>, the HSS <NUM> transmits a registration request to the NRF <NUM>. This step may be similar to step <NUM> of <FIG>. In this example, the one or more services provided by the HSS <NUM> comprises for example nhss-sdm, nhss-uecm (as an example). The indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type comprises: only nhss-sdm for NF subtype "nfType1". It will be appreciated that more operations and resources may be allowed for different NF types and/or subtypes. Only the allowed resources and operations for NF subtype "nfType1" is illustrated here for simplicity.

In step <NUM>, the NRF <NUM> may indicate to the HSS <NUM> that the registration has been made (similarly to step <NUM> of <FIG>).

In step <NUM> the IMS AS <NUM> is instantiated. The IMS AS <NUM> may have a NF profile preconfigured. In some examples, the NF profile may be configured with an indication of one or more services that are expected to be consumed by the IMS AS <NUM>; and an indication of resources and operations associated with each resource of the one or more services that are expected to be consumed. In this example, since the operator's network in this example requires differentiation between AS's when consuming a given service, the NF profile comprises an indication of the subtype of the IMS AS <NUM> which in this example is given as "nfType1".

In step <NUM>, the IMS AS <NUM> transmits a registration request to the NRF <NUM>. In this example, the registration request comprises registration information comprising an indication of the consumer network function type (NF type) and an identification of the consumer NF (AS NF Identifier) (similarly to as described in step <NUM> of <FIG>). In this example, the registration information further comprises the subtype of the IMS AS <NUM> "nfType1".

In step <NUM>, the NRF <NUM> stores the registration information as an IMS AS NF profile (similarly to as described in step <NUM> of <FIG>).

In step <NUM> the NRF <NUM> may indicate to the IMS AS <NUM> that the registration has been made (similar to as described in step <NUM> of <FIG>).

<FIG> are an example signalling diagram illustrating how an IMS Application Server (AS) <NUM> requests authorisation and accesses specific services from a Home Subscriber Server (HSS) <NUM>.

In step <NUM>, the IMS AS <NUM> transmits an access token request to the NRF <NUM> (similarly to as described in step <NUM> of <FIG>). In this example, the access token request comprises an indication of a target NF type, which in this example is "HSS".

In this example, the access token request comprises an indication of one or more expected services ("nhss-sdm"). The access token request in this example also include the subtype "nfType1".

The access token request may also comprise an indication of the IMS AS identifier and the consumer NF type, which in this example is "AS".

In step <NUM>, the NRF checks the access token request for the presence of an indication of one or more expected services (Expected NF Service name(s)), and optionally an indication of requested resources and operations associated with each resource of the one or more expected services. In this example, the NRF locates the expected service "nhss-sdm".

The NRF may also check that there is at least one registered producer NF of the target NF type (e.g. "HSS") that has associated registration information that indicates that an NF of type "AS" and subtype "nfType1" would be authorised to access the service "nhss-sdm".

In step <NUM>, the NRF <NUM> transmits the access token to the IMS AS <NUM> (similarly to as described with reference to step <NUM> of <FIG>). The access token comprises an indication of authorised resources and operations associated with each resource of the one or more expected services (which in this example comprises the access to the service "nhss-sdm").

In some examples, the access token further comprises one or more of: an indication of a target network function type, an identification of the NRF <NUM>, and identification of the IMS AS <NUM>, an expiration time for the access token.

In this example, in steps <NUM> and <NUM>, the IMS AS <NUM> transmits, to the NRF <NUM>, a discovery request comprising an indication of the target network function type (e.g. "HSS") and an indication of authorised resources and operations associated with each resource of the one or more expected services (e.g. "nhss-sdm").

In step <NUM>, the NRF <NUM> locates one or more producer network functions of the target network function type capable of providing the authorised resources and operations associated with each resource of the one or more expected services. In this example, the NRF may locate any stored NF profiles for NFs of the type "HSS" for which the service "nhss-sdm" is authorised for use by NFs of the type "AS" and the subtype "nfType1".

In step <NUM>, the NRF <NUM> transmits a discovery response to the IMS AS <NUM> comprising the one or more producer network functions of the target network function type capable of providing the authorised resources and operations associated with each resource of the one or more expected services.

In step <NUM>, the IMS AS <NUM> selects a producer network function from the one or more producer network functions in the discovery response.

In step <NUM>, the IMS AS <NUM> transmits a service request to a selected HSS <NUM>. The service request comprises: the access token; and a requested operation over a requested resource (similarly to as described in step <NUM> of <FIG>). In this example, the requested operation is "GET" and the requested resource is "IMSI".

In step <NUM> the HSS <NUM> may then verify the integrity of the access token. For example, the HSS <NUM> may check that the access token was generated by the NRF <NUM>. For example, the HSS <NUM> may verify a signature in the access token using a private key or shared secret.

The HSS <NUM> may also check that the target NF type in the service request is "HSS".

In step <NUM>, the HSS <NUM> checks that the requested operation (e.g. "GET") over the requested resource (e.g. "IMSI") falls within the authorised resources and operations associated with each resource of the one or more services (e.g. the authorised resources and operations indicated in the access token) (similarly to as in step <NUM> of <FIG>).

In step <NUM> the HSS <NUM> transmits a NF service response to the IMS AS <NUM> (similarly to as in step <NUM> of <FIG>).

<FIG> illustrates a producer NF <NUM> comprising processing circuitry (or logic) <NUM>. It will be appreciated that the producer NF <NUM> may comprise one or more virtual machines running different software and/or processes. The producer NF <NUM> may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

The producer NF <NUM> may comprise the producer NF <NUM> as described above. The processing circuitry <NUM> controls the operation of the producer NF <NUM> and can implement the method described herein in relation to a producer NF <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the producer NF <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the producer NF <NUM>, HSS <NUM> or UDM NF <NUM>.

Briefly, the processing circuitry <NUM> of the producer NF <NUM> is configured to: transmit a registration request to the NRF, wherein the registration request comprises registration information comprising: an indication of the one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type.

In some embodiments, the producer NF <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the producer NF <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the producer NF <NUM> can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of producer NF <NUM> may be configured to control the communications interface <NUM> of the producer NF <NUM> to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the producer NF <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the producer NF <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the producer NF <NUM> to perform the method described herein in relation to the producer NF <NUM>, producer NF <NUM>, HSS <NUM> or UDM NF <NUM>. Alternatively or in addition, the memory <NUM> of the producer NF <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the producer NF <NUM> may be configured to control the memory <NUM> of the producer NF <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

<FIG> illustrates a consumer network function (NF) <NUM> comprising processing circuitry (or logic) <NUM>. It will be appreciated that the consumer NF <NUM> may comprise one or more virtual machines running different software and/or processes. The consumer NF <NUM> may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

The consumer NF <NUM> may comprise the consumer NF <NUM> as described above. The processing circuitry <NUM> controls the operation of the consumer NF <NUM> and can implement the method described herein in relation to a consumer NF <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the consumer NF <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the consumer NF <NUM> or consumer NF <NUM>.

Briefly, the processing circuitry <NUM> of the consumer NF <NUM> is configured to: transmit a registration request to a network repository function, NRF, wherein the registration request comprises: an indication of one or more services that are expected to be consumed; an indication of resources and operations associated with each resource of the one or more services that are expected to be consumed; and an indication of the consumer network function type.

In some embodiments, the consumer NF <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the consumer NF <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the consumer NF <NUM> can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of consumer NF <NUM> may be configured to control the communications interface <NUM> of the consumer NF <NUM> to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the consumer NF <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the consumer NF <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the consumer NF <NUM> to perform the method described herein in relation to the consumer NF <NUM> the consumer NF <NUM>, the AMF NF <NUM> or the IMS AS <NUM>. Alternatively or in addition, the memory <NUM> of the consumer NF <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the consumer NF <NUM> may be configured to control the memory <NUM> of the consumer NF <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

<FIG> illustrates a Network Repository Function (NRF) <NUM> comprising processing circuitry (or logic) <NUM>. It will be appreciated that the NRF <NUM> may comprise one or more virtual machines running different software and/or processes. The NRF <NUM> may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

The NRF <NUM> may comprise the NRF <NUM> as described above. The processing circuitry <NUM> controls the operation of the NRF <NUM> and can implement the method described herein in relation to an NRF <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NRF <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NRF <NUM> or NRF <NUM>.

Briefly, the processing circuitry <NUM> of the NRF <NUM> is configured to: receive a registration request from a producer network function, wherein the registration request comprises registration information comprising: an indication of one or more services; and an indication of resources and operations associated with each resource of the one or more services that are allowed per network function consumer type; and store the registration information associated with an identity of the producer network function. In some examples, the processing circuitry <NUM> of the NRF <NUM> may be further configured to receive a registration request from a consumer network function, wherein the registration request comprises registration information comprising: an indication of one or more services that are expected to be consumed; and an indication of resources and operations associated with each resource of the one or more services that are expected to be consumed; and an indication of the consumer network function type; and store the registration information associated with an identity of the consumer network function.

In some embodiments, the NRF <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the NRF <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the NRF <NUM> can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of NRF <NUM> may be configured to control the communications interface <NUM> of the NRF <NUM> to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the NRF <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the NRF <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the NRF <NUM> to perform the method described herein in relation to the NRF <NUM> or the NRF <NUM>. Alternatively or in addition, the memory <NUM> of the NRF <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the NRF <NUM> may be configured to control the memory <NUM> of the NRF <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

Embodiments described herein therefore provides a dynamic mechanism to authorize NFs and Applications to a specific set of resources offered by a given service without the need of explicitly including each and every resource. This mechanism may be required in 5GC SBA architecture to satisfy the existing requirements in the 3GPP core network, e.g. 3GPP TS <NUM>, section <NUM> and 3GPP TS <NUM>, section <NUM>.

Embodiments described herein also allows NFs to dynamically discover among a plurality of target NFs which resources are allowed to be accessed and which type of operation is allowed (for example, read, write, or both).

Claim 1:
A method in a producer network function for registering one or more services that the producer network function is capable of providing at a network repository function, NRF (<NUM>, <NUM>), the method comprising:
transmitting a registration request to the NRF (<NUM>, <NUM>), wherein the registration request comprises registration information comprising:
an indication of the one or more services; and
an indication of data types and operations associated with each data type of the one or more services that are allowed per network function consumer type.