Patent Description:
A network repository function (NRF) is a key component of a SBA in the fifth generation (<NUM>) network. The NRF maintains an updated repository of profiles of network functions (NFs) available in a respective core network. An NF (e.g., a network function consumer (NFc)) may fetch an access token from the NRF and send the access token to a target NF so as to use any service of the target NF (e.g., a network function producer (NFp)). Before the access token expires, the NFc may use the access token for any number of times to request services of the NFp. As the access token may be cached and reused by any NFc or service communication proxy for NFc (SCPc) before expiration, chances of misuse of the access token may be high.

In general, example aspects of the present disclosure provide a solution for restricting usage of an access token.

In a first aspect, there is provided a first network device. The first network device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first network device at least to: transmit an access token request to a second network device; receive, from the second network device, an access token associated with a first count value, the first count value indicating the number of times the access token is allowed to be used; transmit, to a third network device, a service request with the access token; and receive, from the third network device, a service response determined based on the first count value and the access token.

In a second aspect, there is provided a second network device. The second network device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the second network device at least to: receive an access token request from a first network device; determine a first count value indicating the number of times an access token is allowed to be used; and transmit, to the first network device, the access token associated with the first count value.

In a third aspect, there is provided a third network device. The third network device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the third network device at least to: receive, from a first network device, a service request with an access token, the access token being associated with a first count value, the first count value indicating the number of times the access token is allowed to be used; determine a stored count value based on the access token; determine a service response based on the stored count value; and transmit the service response to the first network device.

In a fourth aspect, there is provided a method for communication. The method comprises: transmitting, at a first network device, an access token request to a second network device; receiving, from the second network device, an access token associated with a first count value, the first count value indicating the number of times the access token is allowed to be used; transmitting, to a third network device, a service request with the access token; and receiving, from the third network device, a service response determined based on the first count value and the access token.

In a fifth aspect, there is provided a method for communication. The method comprises: receiving, at a second network device, an access token request from a first network device; determining a first count value indicating the number of times an access token is allowed to be used; and transmitting, to the first network device, the access token associated with the first count value.

In a sixth aspect, there is provided a method for communication. The method comprises: receiving, at a third network device and from a first network device, a service request with an access token, the access token being associated with a first count value, the first count value indicating the number of times the access token is allowed to be used; determining a stored count value based on the access token; determining a service response based on the stored count value; and transmitting the service response to the first network device.

In a seventh aspect, there is provided an apparatus for communication. The apparatus comprises: means for transmitting, at a first network device, an access token request to a second network device; means for receiving, from the second network device, an access token associated with a first count value, the first count value indicating the number of times the access token is allowed to be used; means for transmitting, to a third network device, a service request with the access token; and means for receiving, from the third network device, a service response determined based on the first count value and the access token.

In an eighth aspect, there is provided an apparatus for communication. The apparatus comprises: means for receiving, at a second network device, an access token request from a first network device; means for determining a first count value indicating the number of times an access token is allowed to be used; and means for transmitting, to the first network device, the access token associated with the first count value.

In a ninth aspect, there is provided an apparatus for communication. The apparatus comprises: means for receiving, at a third network device and from a first network device, a service request with an access token, the access token being associated with a first count value, the first count value indicating the number of times the access token is allowed to be used; means for determining a stored count value based on the access token; means for determining a service response based on the stored count value; and means for transmitting the service response to the first network device.

In a tenth aspect, there is provided a non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least the method according to any of the fourth to sixth aspects.

In an eleventh aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus to perform at least the method according to any of the fourth to sixth aspects.

S3-<NUM> (SBA Authorization Framework) teaches that a NF consumer may transmit a token request to a SAF. The NF consumer may receive a token from the SAF. The NF consumer may transmit a service request with the token to a NF producer. The NF consumer may receive a service response from the NF producer.

The invention relates to a first network device and a second network device as set forth in the claims. It will be understood that aspects of this disclosure falling outside the scope of the claims may not be part of the invention but may be useful to understand the invention.

Some example aspects will now be described with reference to the accompanying drawings, where:.

Principle of the present disclosure will now be described with reference to some example aspects. It is to be understood that these aspects are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure.

References in the present disclosure to "one aspect," "an aspect," "an example aspect," and the like indicate that the aspect described may include a particular feature, structure, or characteristic, but it is not necessary that every aspect includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same aspect. Further, when a particular feature, structure, or characteristic is described in connection with an aspect, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other aspects whether or not explicitly described.

For example, a first element could be termed a second element, and similarly, a second element could be termed a first element.

The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of example aspects. As used herein, "at least one of the following: <a list of two or more elements>" and "at least one of <a list of two or more elements>" and similar wording, where the list of two or more elements are joined by "and" or "or", mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

As used herein, the term "communication network" refers to a network following any suitable communication standards, such as fifth generation (<NUM>) systems, Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, communications in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (<NUM>), the second generation (<NUM>), <NUM>, <NUM>, the third generation (<NUM>), the fourth generation (<NUM>), <NUM>, the fifth generation (<NUM>), the future sixth generation (<NUM>) communication protocols, and/or any other protocols either currently known or to be developed in the future. Aspects of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied.

As used herein, the term "network device" refers to a node in a communication network via which a terminal device accesses the communication network and receives services therefrom. The communication network may be a core network (CN). The network device in CN may refer to any suitable NF such as a policy control function (PCF), an access management function (AMF), a session management function (SMF), a user plane function (UPF), unified data management (UDM), unified data repository (UDR), an authentication server function (AUSF), a network exposure function (NEF), etc..

The communication network may be a radio access network (RAN). The network device or element in RAN may refer to a base station (BS) or an access point (AP), for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), a NR next generation NodeB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology. An radio access network (RAN) split architecture comprises a gNB-CU (centralized unit, hosting radio resource control (RRC), service data adaptation protocol (SDAP) and packet data convergence protocol (PDCP) layers) controlling a plurality of gNB-DUs (distributed unit, hosting radio link control (RLC), medium access control (MAC) and physical (PHY) layers).

The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, wireless customer-premises equipment (CPE), an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.

Although functionalities described herein can be performed, in various example aspects, in a fixed and/or a wireless network node, in other example aspects, functionalities may be implemented in a user equipment apparatus (such as a cell phone or tablet computer or laptop computer or desktop computer or mobile IoT device or fixed IoT device). This user equipment apparatus can, for example, be furnished with corresponding capabilities as described in connection with the fixed and/or the wireless network node(s), as appropriate. The user equipment apparatus may be the user equipment and/or or a control device, such as a chipset or processor, configured to control the user equipment when installed therein. Examples of such functionalities include the bootstrapping server function and/or the home subscriber server, which may be implemented in the user equipment apparatus by providing the user equipment apparatus with software configured to cause the user equipment apparatus to perform from the point of view of these functions/nodes.

As discussed above, as an access token may be cached and reused by any NFc or SCPc before expiration, chances of misuse of the access token may be high. There may be a scenario where an access token is provided for a limited access, e.g., PLMN1 is providing the access token to PLMN2 for a restricted access of <NUM>-<NUM> times only. However, it is not possible in current technology, and the NRF may only reduce expiry time of the access token.

In some scenarios where a NFc is a malicious one, the NFc may bombard a NFp with service requests continuously as long as an access token is not expired and the NFp may become busy processing these particular NFc service requests. This may lead to Denial of Service to other NFcs.

Currently, there is no way to restrict a NFc, in a same PLMN or other PLMN, to use an access token for limited number of times. Secondly, a service communication proxy (SCP) or a security edge protection proxy (SEPP) or a real-time collaboration hub (RHub) may cache and reuse an issued access token. With roaming hub introduction where trust is scattered among multiple countries, limiting usage of an access token is very much required.

In view of this, aspects of the present disclosure provide a solution for restricting usage of an access token with a usage count so as to solve the above and other potential issues. In this way, chances of misuse of an access token may be reduced and an access token may be efficiently used.

Principles and implementations of the present disclosure will be described in detail below with reference to the figures.

<FIG> illustrates a schematic diagram of an example communication network <NUM> in which aspects of the present disclosure can be implemented. As shown in <FIG>, the communication network <NUM> may involve a plurality of PLMNs <NUM> and <NUM>, a plurality of devices <NUM> and <NUM>, and a data network <NUM>. The PLMN <NUM> may comprise a CN <NUM> and a RAN <NUM>, and the PLMN <NUM> may comprise a CN <NUM> and a RAN <NUM>.

As shown in <FIG>, each of the CNs <NUM> and <NUM> may comprise a plurality of CN devices. For example, the CN <NUM> may comprise NFs <NUM> and <NUM>, an NRF <NUM>, SCPs <NUM> and <NUM> and a SEPP <NUM>. Any of the NFs <NUM> and <NUM> may be a UPF, an AUSF, an AMF, a SMF, a UDM or any other suitable NFs. The CN <NUM> may comprise NFs <NUM> and <NUM>, an NRF <NUM>, SCPs <NUM> and <NUM> and a SEPP <NUM>. Any of the NFs <NUM> and <NUM> may be a UPF, an AUSF, an AMF, a SMF, a UDM or any other suitable NFs. It is to be understood that the CN devices in CNs <NUM> and <NUM> are only for the purpose of illustration without suggesting any limitations. The communication network <NUM> may include more or less CN devices adapted for implementing aspects of the present disclosure. The present disclosure does not limit the number and type of the CN devices.

The data network <NUM> may be Internet or any other suitable data networks. The RANs <NUM> and <NUM> may comprise any suitable network devices (not shown) and may adopt any suitable RAN technologies. It is to be understood that the communication network <NUM> may include any suitable number or type of the RANs, CNs and data networks adapted for implementing aspects of the present disclosure.

In this example, the devices <NUM> and <NUM> are illustrated as mobile phones. It should be noted that any of the devices <NUM> and <NUM> may be any other suitable types of terminal devices or network devices. Further, it is to be understood that the number of the devices is only for the purpose of illustration without suggesting any limitations. The communication network <NUM> may include any suitable number or type of the devices adapted for implementing aspects of the present disclosure.

In some aspects, the device <NUM> may communicate with the data network <NUM> via the RAN <NUM> and the CN <NUM>. The device <NUM> may communicate with the data network <NUM> via the RAN <NUM> and the CN <NUM>.

In some aspects, CN devices (e.g., the NFs <NUM> and <NUM>) in each of the CNs <NUM> and <NUM> may communicate with each other directly. This procedure may be called as intra-PLMN direct communication. In some aspects, CN devices (e.g., the NFs <NUM> and <NUM>) in each of the CNs <NUM> and <NUM> may communicate with each other via one or more CN devices (e.g., the SCF <NUM> or <NUM> or both). This procedure may be called as intra-PLMN indirect communication. In some aspects, a CN device (e.g., the NF <NUM> or <NUM>) in the CN <NUM> may communicate with a CN device (e.g., the NF <NUM> or <NUM>) in the CN <NUM> via CN devices (e.g., the NRF <NUM>, <NUM> and the SEPP <NUM>, <NUM>). This procedure may be called as inter-PLMN direct communication.

Communications in the communication network <NUM> may be implemented according to any proper communication protocol(s), comprising, but not limited to, cellular communication protocols of the first generation (<NUM>), the second generation (<NUM>), the third generation (<NUM>), the fourth generation (<NUM>), the fifth generation (<NUM>) or the future sixth generation (<NUM>) wireless local network communication protocols, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple-Input Multiple-Output (MIMO), Orthogonal Frequency Division Multiple (OFDM), Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.

It is to be understood that the communication network <NUM> is merely an example, and aspects of the present disclosure may also apply to any other suitable environments.

In some aspects, the NF <NUM> may obtain an access token form the NRF <NUM> and request any service from the NF <NUM> by using the access token. In this case, the NF <NUM> serves as a NFc and the NF <NUM> serves as a NFp.

In some aspects, the NF <NUM> may obtain an access token from the NRF <NUM> and request any service from the NF <NUM> or <NUM> by using the access token. In this case, the NF <NUM> serves as a NFc and the NF <NUM> or <NUM> serves as a NFp.

Conventionally, before an access token expires, a NFc may use the access token for any number of times to request services from a NFp. This may cause a high chance of misuse of the access token.

Aspects of the present disclosure provide a solution for restricting usage of an access token so as to avoid or reduce the misuse of the access token. The solution will be described in connection with <FIG>.

<FIG> illustrates a flowchart illustrating an example process <NUM> for restricting usage of an access token according to some aspects of the present disclosure. The process <NUM> may involve a first network device, a second network device and a third network device. In some aspects, the first, second and third network devices may be any suitable CN devices. In some aspects, any two of the first, second and third network devices may be in different PLMNs. In some aspects, any two of the first, second and third network devices may be in the same PLMN.

As shown in <FIG>, the first network device may transmit <NUM> an access token request to the second network device. The access token request may be used for obtaining an access token for service access to a target NF (e.g., NFp) of a specific NF type. In some aspects, the access token request may be based on an identity of the target NF (e.g., targetNFInstanceId). In some aspects, the access token request may be based on a type of the target NF (e.g., targetNFType).

In some aspects, the access token request may comprise a suggested count value. In some aspects, the suggested count value may be a suggestion for a first count value indicating the number of times an access token is allowed to be used. In the context of the present disclosure, the term "a first count value" may refer to a count value in an access token that is signed by an NRF and cannot be modified.

In some aspects, the first network device may be a NFc. In some aspects, the first network device may be a SCP for the NFc. In this case, the SCP may perform communication on behalf of the NFc, e.g., receive the access token request from the NFc and forward the access token request to the second network device. In some aspects, the second network device may be a NRF. For example, the second network device may be a NRF for the NFc (for convenience, also referred to as NRFc herein). In another example, the second network device may be a NRF for the NFp (for convenience, also referred to as NRFp herein).

Upon reception of the access token request, the second network device may determine <NUM> the first count value indicating the number of times an access token is allowed to be used. In some aspects, the second network device may check whether the NFc is authorized. If the NFc is authorized, the second network device may generate the access token and the first count value.

In some aspects where the access token request is based on the identity of the target NF (e.g., targetNFInstanceId), the access token may be based on the identity of the NFp. In this case, the access token may be used exclusively to avail the service of the NFp. In some aspects where the access token request is based on the type of the target NF (e.g., targetNFType), the access token may be based on the type of the NFp. In this case, the access token may be used to avail the services of one or more NFs with the same NF type.

In some aspects, the second network device may determine the first count value based on profile parameters associated with the NFc available at the second network device. For example, the profile parameters associated with the NFc may comprise at least one of the following: a load, a configuration, a NF type or a service/operation type of the NFc. It is to be understood that any other suitable profile parameters associated with the NFc are also feasible.

In some aspects, the second network device may determine the first count value based on profile parameters associated with the NFp available at the second network device. For example, the profile parameters associated with the NFp may comprise at least one of the following: a load, a configuration, a NF type or a service/operation type of the NFp. It is to be understood that any other suitable profile parameters associated with the NFc are also feasible.

In some aspects, the second network device may determine the first count value based on an operator policy. In some aspects where the access token request comprises the suggested count value, the second network device may determine the first count value based on the suggested count value.

It is to be understood that any combination of the above aspects and any other suitable aspects may also be applied for determination of the first count value. With the first count value, usage of the access token may be limited as needed.

Continue to refer to <FIG>, upon determination of the access token associated with the first count value, the second network device may transmit <NUM> the access token with the first count value to the first network device. In some aspects where the first network device is not the NFc itself, the first network device may forward the access token to the NFc.

The first network device may transmit <NUM> a service request with the access token to the third network device. In some aspects, the third network device may be the NFp. In some aspects, the third network device may be a SCP for the NFp (for convenience, may also referred to as SCPp herein). In this case, the SCP may perform communication on behalf of the NFp. In some aspects, the third network device may be a SEPP for the NFp (for convenience, may also referred to as SEPPp herein). In this case, the SEPPp may perform communication on behalf of the NFp. In some aspects where the first network device is not the NFc itself, the first network device may receive the service request to the NFp and forward the service request to the third network device.

In some aspects, the first network device may determine, based on the first count value, whether the service request is allowed to be transmitted. In some aspects, the first network device may store the first count value as an allowed count value. If a service request is transmitted, the first network device may decrement the allowed count value. In some aspects, if the allowed count value is larger than a threshold value (for example, <NUM> or any other suitable value), the first network device may determine that a service request is allowed to be transmitted. If the allowed count value is equal to the threshold value, the first network device may determine that a service request is not allowed to be transmitted. If the service request is allowed to be transmitted, the first network device may transmit the service request. In this way, usage of an access token may be limited.

Based on the service request, the third network device may determine <NUM> a stored count value based on the access token. In some aspects, the third network device may determine whether the access token is stored. If the access token is not stored, the third network device may store the access token.

In some aspects, if the access token is associated with the identity of the target NF, the third network device may store <NUM> the access token at the third network device. In this case, the first count value is stored as the stored count value.

In some aspects, if the access token is associated with the type of the target NF, the third network device may store <NUM> the access token at a fourth network device accessible to a set of NFs, and store the first count value as the stored count value. In some aspects, the set of NFs may have the same type of the target NF. In some aspects, the fourth network device may be a NRF. In some aspects, the fourth network device may be an unstructured data storage function (UDSF). In some aspects, the fourth network device may be any other central databases.

In some aspects, the access token may be stored in a cache. It is to be understood that the access token may be stored in any other suitable ways.

Based on the stored count value, the third network device may determine <NUM> a service response to the service request. In some aspects, if the stored count value is larger than a predetermined value, the third network device may provide, as the service response, a service requested in the service request. In some aspects where the third network device is not the NFp itself, the third network device may forward the service request to the NFp and obtain the service response from the NFp.

In some aspects, if the stored count value is equal to the predetermined value, the third network device may provide, as the service response, a rejection to the service request. In some aspects, the predetermined value may be <NUM>. It is to be understood that the predetermined value may be any other suitable values.

In some aspects, if a service is provided as the service response, the third network device may decrement <NUM> the stored count value. In some aspects where the access token is based on the identity of the target NF, every time the NFp processes the service request from the NFc, the third network device may decrement the stored count value from the associated access token. In some aspects where the access token is based on the type of the target NF, the third network device may fetch the stored count value from the fourth network device accessible to a set of NFs before providing the service. The stored count value in the fourth network device is decremented by the third network device for the respective access token after the service is rendered. Any NFc within the set of NFs may cache the access token and reuse the access token.

Upon determination of the service response, the third network device may transmit <NUM> the service response to the first network device. In some aspects where the first network device is not the NFc itself, the first network device may forward the service request to the NFc.

In some aspects, if the access token expires, the third network device may delete <NUM> the access token from the third network device. In some aspects, the access token may be associated with a period of time. If the period of time passes since reception of the access token, the third network device may determine that the access token expires.

In this way, the number of uses of the access token may be controlled. It is to be noted that the process <NUM> as shown in <FIG> is merely an example, and may have additional or less operations. For illustration, some example aspects will be described below in connection with <FIG>.

<FIG> illustrates a flowchart illustrating an example process <NUM> for restricting usage of an access token for intra-PLMN direct communication of NFs according to some aspects of the present disclosure. For the purpose of discussion, the process <NUM> will be described with reference to <FIG>. It is assumed that the NF <NUM> is a NFc and the NF <NUM> is a NFp. In this example, the first network device is the NF <NUM>, the second network device is the NRF <NUM>, and the third network device is the NF <NUM>.

With reference to <FIG>, the NF <NUM> may transmit <NUM> an access token request to the NRF <NUM>. In some aspects, the access token request may comprise a suggested count value. It is to be understood that the access token request may not comprise a suggested count value.

Upon reception of the access token request, the NRF <NUM> may determine <NUM> the first count value indicating the number of times an access token is allowed to be used. In some aspects, the NRF <NUM> may determine the first count value based on at least one of the following: profile parameters associated with the NF <NUM> available at the NRF <NUM>; profile parameters associated with the NF <NUM> available at the NRF <NUM>; an operator policy; or the suggested count value. It is to be understood that any combination of the above information and any other suitable information may also be applied for determination of the first count value. With the first count value, usage of the access token may be limited as needed.

Upon determination of the access token associated with the first count value, the NRF <NUM> may transmit <NUM> the access token with the first count value to the NF <NUM>.

The NF <NUM> may transmit <NUM> a service request with the access token to the NF <NUM>. In some aspects, the NF <NUM> may determine, based on the first count value, whether the service request is allowed to be transmitted. In some aspects, the NF <NUM> may store the first count value as an allowed count value. If a service request is transmitted, the NF <NUM> may decrement the allowed count value. In some aspects, if the allowed count value is larger than a threshold value (for example, <NUM> or any other suitable value), the NF <NUM> may determine that a service request is allowed to be transmitted. If the allowed count value is equal to the threshold value, the NF <NUM> may determine that a service request is not allowed to be transmitted. If the service request is allowed to be transmitted, the NF <NUM> may transmit the service request. In this way, usage of an access token may be limited.

Based on the service request, the NF <NUM> may determine <NUM> a stored count value based on the access token. In some aspects, the NF <NUM> may determine whether the access token is stored. If the access token is not stored, the NF <NUM> may store the access token.

In some aspects, if the access token is associated with the identity of the target NF, the NF <NUM> may store <NUM> the access token at the NF <NUM>. In this case, the first count value is stored as the stored count value.

In some aspects, if the access token is associated with the type of the target NF, the NF <NUM> may store <NUM> the access token at a fourth network device accessible to a set of NFs, and store the first count value as the stored count value. In some aspects, the set of NFs may have the same type of the target NF. In some aspects, the fourth network device may be a NRF or an UDSF or any other central databases.

Based on the stored count value, the NF <NUM> may determine <NUM> a service response. In some aspects, if the stored count value is larger than a predetermined value, the NF <NUM> may provide, as the service response, a service requested in the service request. If the stored count value is equal to the predetermined value, the NF <NUM> may provide, as the service response, a rejection to the service request. In some aspects, the predetermined value may be <NUM>. It is to be understood that the predetermined value may be any other suitable values.

In some aspects, if a service is provided as the service response, the NF <NUM> may decrement <NUM> the stored count value.

Upon determination of the service response, the NF <NUM> may transmit <NUM> the service response to the NF <NUM>. In some aspects, if the access token expires, the NF <NUM> may delete <NUM> the access token from the NF <NUM>.

In this way, usage of an access token in an intra-PLMN direct communication may be controlled. The operations of the process <NUM> substantially correspond to that of the process <NUM>, and thus other details are not repeated here for conciseness. It is to be noted that the process <NUM> as shown in <FIG> is merely an example, and may have additional or less operations.

<FIG> illustrates a flowchart illustrating an example process <NUM> for restricting usage of an access token for intra-PLMN indirect communication of NFs according to some aspects of the present disclosure. For the purpose of discussion, the process <NUM> will be described with reference to <FIG>. It is assumed that the NF <NUM> is a NFc and the NF <NUM> is a NFp. In this example, the first network device is the NF <NUM>, the second network device is the NRF <NUM>, and the third network device is the SCP <NUM>. The SCP <NUM> is used for the NF <NUM> and the SCP <NUM> is used for the NF <NUM>. In some aspects, the SCP <NUM> and the SCP <NUM> may be the same device. In some aspects, the SCP <NUM> and the SCP <NUM> may be different devices.

With reference to <FIG>, the NF <NUM> may transmit <NUM> an access token request to the SCP <NUM>, and the SCP <NUM> may forward <NUM> the access token request to the NRF <NUM>. In some aspects, the access token request may comprise a suggested count value. It is to be understood that the access token request may not comprise a suggested count value.

Upon determination of the access token associated with the first count value, the NRF <NUM> may transmit <NUM> the access token with the first count value to the SCP <NUM> and the SCP <NUM> may forward <NUM> the access token to the NF <NUM>.

The NF <NUM> may transmit <NUM> a service request with the access token to the SCP <NUM> and the SCP <NUM> may forward <NUM> the service request to the SCP <NUM>.

In some aspects, the NF <NUM> may determine, based on the first count value, whether a service request is allowed to be transmitted. In some aspects, the NF <NUM> may store the first count value as an allowed count value. If a service request is transmitted, the NF <NUM> may decrement the allowed count value. In some aspects, if the allowed count value is larger than a threshold value (for example, <NUM> or any other suitable value), the NF <NUM> may determine that a service request is allowed to be transmitted. If the allowed count value is equal to the threshold value, the NF <NUM> may determine that a service request is not allowed to be transmitted. If the service request is allowed to be transmitted, the NF <NUM> may transmit the service request. In this way, usage of an access token may be limited.

Based on the service request, the SCP <NUM> may determine <NUM> a stored count value based on the access token. In some aspects, the SCP <NUM> may determine whether the access token is stored. If the access token is not stored, the SCP <NUM> may store the access token.

In some aspects, if the access token is associated with the identity of the target NF, the SCP <NUM> may store <NUM> the access token at the SCP <NUM>. In this case, the first count value is stored as the stored count value.

In some aspects, if the access token is associated with the type of the target NF, the SCP <NUM> may store <NUM> the access token at a fourth network device accessible to a set of NFs, and store the first count value as the stored count value. In some aspects, the set of NFs may have the same type of the target NF. In some aspects, the fourth network device may be a NRF or an UDSF or any other central databases.

Based on the stored count value, the SCP <NUM> may determine a service response to the service request. In some aspects, if the stored count value is larger than a predetermined value, the SCP <NUM> may forward <NUM> the service request to the NF <NUM> and obtain <NUM>, from the NF <NUM>, a service requested in the service request. If the stored count value is equal to the predetermined value, the SCP <NUM> may determine <NUM>, as the service response, a rejection to the service request. In some aspects, the predetermined value may be <NUM>. It is to be understood that the predetermined value may be any other suitable values.

In some aspects, if a service is provided as the service response, the SCP <NUM> may decrement <NUM> the stored count value.

Upon determination of the service response, the SCP <NUM> may transmit <NUM> the service response to the SCP <NUM> and the SCP <NUM> may forward <NUM> the service response to the NF <NUM>. In some aspects, if the access token expires, the SCP <NUM> may delete <NUM> the access token.

In this way, usage of an access token in an intra-PLMN indirect communication may be controlled. The operations of the process <NUM> substantially correspond to that of the process <NUM>, and thus other details are not repeated here for conciseness. It is to be noted that the process <NUM> as shown in <FIG> is merely an example, and may have additional or less operations.

<FIG> illustrates a flowchart illustrating an example process <NUM> for restricting usage of an access token for inter-PLMN communication of NFs according to some aspects of the present disclosure. For the purpose of discussion, the process <NUM> will be described with reference to <FIG>. It is assumed that the NF <NUM> is a NFc and the NF <NUM> is a NFp. In this example, the first network device is the NF <NUM> or SEPP <NUM>, the second network device is the NRF <NUM> for the NF <NUM>, and the third network device is the SEPP <NUM>.

With reference to <FIG>, the NF <NUM> may transmit <NUM> an access token request to the NRF <NUM>, and the NRF <NUM> may forward <NUM> the access token request to the SEPP <NUM>. The SEPP <NUM> may forward <NUM> the access token request to the SEPP <NUM> and the SEPP <NUM> may forward <NUM> the access token request to the NRF <NUM>. In some aspects, the access token request may comprise a suggested count value. It is to be understood that the access token request may not comprise a suggested count value.

Upon determination of the access token associated with the first count value, the NRF <NUM> may transmit <NUM> the access token with the first count value to the SEPP <NUM> and the SEPP <NUM> may forward <NUM> the access token to the SEPP <NUM>. The SEPP <NUM> may forward <NUM> the access token to the NF <NUM>.

The NF <NUM> may transmit <NUM> a service request with the access token to the SEPP <NUM> and the SEPP <NUM> may forward <NUM> the service request to the SEPP <NUM>. In some aspects, the NF <NUM> may determine, based on the first count value, whether a service request is allowed to be transmitted. In some aspects, the NF <NUM> may store the first count value as an allowed count value. If a service request is transmitted, the NF <NUM> may decrement the allowed count value. In some aspects, if the allowed count value is larger than a threshold value (for example, <NUM> or any other suitable value), the NF <NUM> may determine that a service request is allowed to be transmitted. If the allowed count value is equal to the threshold value, the NF <NUM> may determine that a service request is not allowed to be transmitted. If the service request is allowed to be transmitted, the NF <NUM> may transmit the service request. In this way, usage of an access token may be limited.

Based on the service request, the SEPP <NUM> may determine <NUM> a stored count value based on the access token. In some aspects, the SEPP <NUM> may determine whether the access token is stored. If the access token is not stored, the SEPP <NUM> may store the access token.

In some aspects, if the access token is associated with the identity of the target NF, the SEPP <NUM> may store <NUM> the access token at the SEPP <NUM>. In this case, the first count value is stored as the stored count value.

In some aspects, if the access token is associated with the type of the target NF, the SEPP <NUM> may store <NUM> the access token at a fourth network device accessible to a set of NFs, and store the first count value as the stored count value. In some aspects, the set of NFs may have the same type of the target NF. In some aspects, the fourth network device may be a NRF or an UDSF or any other central databases.

In some aspects, if the stored count value is larger than a predetermined value, the SEPP <NUM> may forward <NUM> the service request to the NF <NUM> and obtain <NUM>, from the NF <NUM>, a service requested in the service request. If the stored count value is equal to the predetermined value, the SEPP <NUM> may determine <NUM>, as the service response, a rejection to the service request. In some aspects, the predetermined value may be <NUM>. It is to be understood that the predetermined value may be any other suitable values.

In some aspects, if a service is provided as the service response, the SEPP <NUM> may decrement <NUM> the stored count value.

Upon determination of the service response, the SEPP <NUM> may transmit <NUM> the service response to the SEPP <NUM>, and the SEPP <NUM> may forward <NUM> the service response to the NF <NUM>. In some aspects, if the access token expires, the SEPP <NUM> may delete <NUM> the access token.

In this way, usage of an access token in an inter-PLMN communication may be controlled. The operations of the process <NUM> substantially correspond to that of the process <NUM>, and thus other details are not repeated here for conciseness. It is to be noted that the process <NUM> as shown in <FIG> is merely an example, and may have additional or less operations.

Corresponding to the above processes, example aspects of the present disclosure also provide methods of communication. <FIG> illustrates a flowchart of an example method <NUM> implemented at a first network device according to some aspects of the present disclosure. For the purpose of discussion, the method <NUM> will be described with reference to <FIG>.

At block <NUM>, a first network device transmits an access token request to a second network device. In some aspects, the first network device may be a NFc, and the second network device may be a NRF. In some aspects, the first network device may be a SCP for a NFc, and the second network device may be a NRF. In some aspects, the first network device may be a NFc, and the second network device may be a NRF for a NFp.

In some aspects, the access token request may comprise a suggested count value. In some aspects, the access token request may not comprise a suggested count value. It is to be understood that the access token request may comprise any suitable information.

At block <NUM>, the first network device receives, from the second network device, an access token associated with a first count value, the first count value indicating the number of times the access token is allowed to be used.

At block <NUM>, the first network device transmits, to a third network device, a service request with the access token. In some aspects, the first network device may determine, based on the first count value, whether the service request is allowed to be transmitted. If the service request is allowed to be transmitted, the first network device may transmit the service request.

In some aspects where the first network device is a NFc and the second network device is a NRF, the third network device may be a NFp, e.g., as described in the process <NUM>. In some aspects where the first network device is a NFc or a SCP for a NFc and the second network device is a NRF, the third network device may be a SCP for a NFp, e.g., as described in the process <NUM>. In some aspects where the first network device is a NFc in a first PLMN and the second network device is a NRF for a NFp in a second PLMN, the third network device may be a SEPP for the NFp, e.g., as described in the process <NUM>.

At block <NUM>, the first network device receives, from the third network device, a service response determined based on the first count value and the access token. In some aspects, the first network device may receive a service requested in the service request. In some aspects, the first network device may receive a rejection to the service request.

In this way, a behavior at a NFc for restricting usage of an access token is specified.

<FIG> illustrates a flowchart of an example method <NUM> implemented at a second network device according to some aspects of the present disclosure. For the purpose of discussion, the method <NUM> will be described with reference to <FIG>.

At block <NUM>, a second network device receives an access token request from a first network device. In some aspects, the first network device may be a NFc, and the second network device may be a NRF. In some aspects, the first network device may be a SCP for a NFc, and the second network device may be a NRF. In some aspects, the first network device may be a NFc, and the second network device may be a NRF for a NFp.

At block <NUM>, the second network device determines a first count value indicating the number of times an access token is allowed to be used. In some aspects, the second network device may determine the first count value based on at least one of the following: the suggested count value, profile parameters associated with the NFc available at the second network device, profile parameters associated with the NFp available at the second network device, or an operator policy.

At block <NUM>, the second network device transmits, to the first network device, the access token associated with the first count value.

In this way, a behavior at a NRF for restricting usage of an access token is specified.

<FIG> illustrates a flowchart of an example method <NUM> implemented at a third network device according to some aspects of the present disclosure. For the purpose of discussion, the method <NUM> will be described with reference to <FIG>.

At block <NUM>, a third network device receives, from a first network device, a service request with an access token, the access token being associated with a first count value, the first count value indicating the number of times the access token is allowed to be used.

In some aspects, the first network device may be a NFc and the third network device may be a NFp. In some aspects, the first network device may be a NFc or a SCP for a NFc, and the third network device may be a SCP for a NFp. In some aspects, the first network device may be a NFc in a first PLMN, and the third network device may be a SEPP for the NFp.

At block <NUM>, the third network device determines a stored count value based on the access token. In some aspects where the access token is associated with an identity of a target NF, if the access token is not stored, the third network device may store the access token at the third network device. In some aspects where the access token is associated with a type of a target NF, if the access token is not stored, the third network device may store the access token at a fourth network device accessible to a set of NFs. In some aspects, the fourth network device may be a NRF, an UDSF, or a central database. In these aspects, the first count value is stored as the stored count value.

In some aspects, if a service is provided, the third network device may decrement the stored count value. That is, the stored count value may decrease as service access increases. Upon reception of the service request, the third network device may obtain the stored count value from the third network device or the fourth network device based on the access token.

At block <NUM>, the third network device determines a service response based on the stored count value. In some aspects, if the stored count value is larger than a predetermined value, the third network device may provide, as the service response, a service requested in the service request. In some aspects, if the stored count value is equal to the predetermined value, the third network device may provide, as the service response, a rejection to the service request.

At block <NUM>, the third network device transmits the service response to the first network device. In some aspects, if the access token expires, the third network device may delete the access token from the third network device or the fourth network device.

In this way, a behavior at a NFp for restricting usage of an access token is specified.

Example aspects of the present disclosure also provide the corresponding apparatus. In some aspects, an apparatus (for example, the first network device) capable of performing the method <NUM> may comprise means for performing the respective steps of the method <NUM>. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some aspects, the apparatus comprises: means for transmitting, at a first network device, an access token request to a second network device; means for receiving, from the second network device, an access token associated with a first count value, the first count value indicating the number of times the access token is allowed to be used; means for transmitting, to a third network device, a service request with the access token; and means for receiving, from the third network device, a service response determined based on the first count value and the access token.

In some aspects, the means for transmitting the access token request comprises means for transmitting, to the second network device, the access token request comprising a suggested count value.

In some aspects, the means for transmitting the service request comprises: means for determining, based on the first count value, that the service request is allowed to be transmitted.

In some aspects, the means for receiving the service response comprises: means for receiving a service requested in the service request; or means for receiving a rejection to the service request.

In some aspects, an apparatus (for example, the second network device) capable of performing the method <NUM> may comprise means for performing the respective steps of the method <NUM>. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some aspects, the apparatus comprises: means for receiving an access token request from a first network device; means for determining a first count value indicating the number of times an access token is allowed to be used; and means for transmitting, to the first network device, the access token associated with the first count value.

In some aspects, the means for receiving the access token request comprises: means for receiving, from the first network device, the access token request comprising a suggested count value.

In some aspects, the means for determining the first count value comprises: means for determining the first count value based on at least one of the following: the suggested count value, profile parameters associated with a NFc available at the second network device, profile parameters associated with a NFp available at the second network device, or an operator policy.

In some aspects, an apparatus (for example, the third network device) capable of performing the method <NUM> may comprise means for performing the respective steps of the method <NUM>. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some aspects, the apparatus comprises: means for receiving, from a first network device, a service request with an access token, the access token being associated with a first count value, the first count value indicating the number of times the access token is allowed to be used; means for determining a stored count value based on the access token; means for determining a service response based on the stored count value; and means for transmitting the service response to the first network device.

In some aspects, the means for determining the service response comprises: means for, in accordance with a determination that the stored count value is larger than a predetermined value, providing, as the service response, a service requested in the service request; and means for, in accordance with a determination that the stored count value is equal to the predetermined value, providing, as the service response, a rejection to the service request.

In some aspects where the access token is associated with an identity of a target NF, the apparatus may further comprise: means for, in accordance with a determination that the access token is not stored, storing the access token at the third network device, the first count value being stored as the stored count value; means for, in accordance with a determination that a service is provided, decrementing the stored count value; or means for, in accordance with a determination that the access token expires, deleting the access token from the third network device.

In some aspects where the access token is associated with a type of a target NF, the apparatus may further comprise: means for, in accordance with a determination that the access token is not stored, storing the access token at a fourth network device accessible to a set of NFs, the first count value being stored as the stored count value; means for, in accordance with a determination that a service is provided, decrementing the stored count value; or means for, in accordance with a determination that the access token expires, deleting the access token from the fourth network device. In some aspects, the fourth network device is a NRF, an UDSF, or a central database.

For the above apparatuses, in some aspects, the first network device is a NFc, the second network device is a NRF, and the third network device is a NFp. In some aspects, the first network device is a NFc or a SCP for the NFc, the second network device is a NRF, and the third network device is a SCP for a NFp. In some aspects, the first network device is a NFc in a first PLMN, the second network device is a NRF for a NFp in a second PLMN, and the third network device is a SEPP for the NFp.

<FIG> is a simplified block diagram of a device <NUM> that is suitable for implementing aspects of the present disclosure. The device <NUM> may be provided to implement any of network devices, for example, as shown in <FIG>. As shown, the device <NUM> includes one or more processors <NUM>, one or more memories <NUM> coupled to the processor <NUM>, and one or more communication modules <NUM> coupled to the processor <NUM>.

The aspects of the present disclosure may be implemented by means of the program <NUM> so that the device <NUM> may perform any process of the disclosure as discussed with reference to <FIG>. The aspects of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

In some aspects, the program <NUM> may be tangibly contained in a computer readable medium which may be included in the device <NUM> (such as in the memory <NUM>) or other storage devices that are accessible by the device <NUM>.

Generally, various aspects of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. While various aspects of aspects of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the method <NUM> or <NUM> or <NUM> as described above with reference to <FIG>. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various aspects. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

The term "non-transitory," as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations, but rather as descriptions of features that may be specific to particular aspects. Certain features that are described in the context of separate aspects may also be implemented in combination in a single aspect. Conversely, various features that are described in the context of a single aspect may also be implemented in multiple aspects separately or in any suitable sub-combination.

Claim 1:
A first network device comprising:
at least one processor; and
at least one memory storing instructions that, when executed by the at least one processor, cause the first network device at least to:
transmit (<NUM>), to a second network device, an access token request comprising a suggestion for a first count value;
receive (<NUM>), from the second network device, an access token associated with a first count value, the first count value determined by the second network device based on the suggestion for the first count value, the first count value indicating the number of times the access token is allowed to be used;
transmit (<NUM>), to a third network device, a service request with the access token; and
receive (<NUM>), from the third network device, a service response determined based on the first count value and the access token.