TECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to methods, apparatuses and computer readable storage media for authorizing access.

BACKGROUND

[0002] Using the fifth generation (5G) network, not only more humans are getting connected for their private and/or public uses, but also machines, robots, cars and/or devices will used the 5G network for their critical communications. To meet all of the requirements, the 5G core network (5GC) is designed to be extremely secure. For devices registered to the 5GC, secure communications among them will be facilitated. It would be desired that this inbuilt security features could be reused by an external application connected to the 5GC to obtain authorization from the 5GC (in terms of access tokens) to access terminal devices registered to the 5GC. It would be also desired that this inbuilt security features could be reused by a terminal device registered to the 5GC (in terms of access tokens) to access applications that are using the 5GC.

[0003] Access tokens from the 5GC can provide an additional mechanism for scoping permissions of the applications or terminal devices. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented. Therefore, it would be desired that the 5GC can provide a service for generating an access token upon request from an application or a terminal device and providing the generated access token to the application or the terminal device securely. However, there is no such service in the 5GC currently.

SUMMARY

[0004] In general, example embodiments of the present disclosure provide methods, apparatuses and computer readable storage media for authorizing access.

[0005] In a first aspect, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to transmit, from an application to an authorization server, a first request for a first access token to be used by the application to access a terminal device; in response to the first request being determined as valid by the authorization server, receive a first response to the first request from the authorization server, the first response comprising the first access token and information about the first access token; transmit, based on the information and to the terminal device, a second request for accessing the terminal device, the second request comprising the first access token; and receive a second response to the second request from the terminal device.

[0006] In a second aspect, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to receive, at an authorization server and from an application, a first request for a first access token to be used by the application to access a terminal device; verify validity of the first request; in response to the first request being valid, generate the first access token and information about the first access token; and transmit, to the application, a first response to the first request, the first response comprising the first access token and the information about the first access token.

[0007] In a third aspect, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to receive, at a terminal device and from an application, a second request for accessing the terminal device, the second request comprising a first access token for accessing the terminal device; verify validity of the first access token; and transmit, to the application, a second response to the second request based on a result of the verification.

[0008] In a fourth aspect, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to transmit, from a terminal device to an authorization server, a fourth request for a second access token to be used by the terminal device to access an application; in response to the fourth request being determined as valid by the authorization server, receive a fourth response to the fourth request from the authorization server, the fourth response comprising the second access token and information about the second access token; transmit, based on the information and to the application, a fifth request for accessing the application, the fifth request comprising the second access token; and receive a fifth response to the fifth request from the application.

[0009] In a fifth aspect, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to receive, at an authorization server and from a terminal device, a fourth request for a second access token to be used by the terminal device to access an application; verify validity of the fourth request; in response to the fourth request being valid, generate the second access token and information about the second access token; and transmit, to the terminal device, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.

[0010] In a sixth aspect, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to receive, at an application and from a terminal device, a fifth request for accessing the application, the fifth request comprising a second access token for accessing the application; verify validity of the second access token; and transmit, to the terminal device, a fifth response to the fifth request based on a result of the verification.

[0011] In a seventh aspect, there is provided a method. The method comprises transmitting, from an application to an authorization server, a first request for a first access token to be used by the application to access a terminal device; in response to the first request being determined as valid by the authorization server, receiving a first response to the first request from the authorization server, the first response comprising the first access token and information about the first access token; transmitting, based on the information and to the terminal device, a second request for accessing the terminal device, the second request comprising the first access token; and receiving a second response to the second request from the terminal device.

[0012] In an eighth aspect, there is provided a method. The method comprises receiving, at an authorization server and from an application, a first request for a first access token to be used by the application to access a terminal device; verifying validity of the first request; in response to the first request being valid, generating the first access token and information about the first access token; and transmitting, to the application, a first response to the first request, the first response comprising the first access token and the information about the first access token.

[0013] In a ninth aspect, there is provided a method. The method comprises receiving, at a terminal device and from an application, a second request for accessing the terminal device, the second request comprising a first access token for accessing the terminal device; verifying validity of the first access token; and transmitting, to the application, a second response to the second request based on a result of the verification.

[0014] In a tenth aspect, there is provided a method. The method comprises transmitting, from a terminal device to an authorization server, a fourth request for a second access token to be used by the terminal device to access an application; in response to the fourth request being determined as valid by the authorization server, receiving a fourth response to the fourth request from the authorization server, the fourth response comprising the second access token and information about the second access token; transmitting, based on the information and to the application, a fifth request for accessing the application, the fifth request comprising the second access token; and receiving a fifth response to the fifth request from the application.

[0015] In an eleventh aspect, there is provided a method. The method comprises receiving, at an authorization server and from a terminal device, a fourth request for a second access token to be used by the terminal device to access an application; verifying validity of the fourth request; in response to the fourth request being valid, generating the second access token and information about the second access token; and transmitting, to the terminal device, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.

[0016] In an twelfth aspect, there is provided a method. The method comprises receiving, at an application and from a terminal device, a fifth request for accessing the application, the fifth request comprising a second access token for accessing the application; verifying validity of the second access token; and transmitting, to the terminal device, a fifth response to the fifth request based on a result of the verification.

[0017] In a thirteenth aspect, there is provided an apparatus. The apparatus comprises means for transmitting, from an application to an authorization server, a first request for a first access token to be used by the application to access a terminal device; means for in response to the first request being determined as valid by the authorization server, receiving a first response to the first request from the authorization server, the first response comprising the first access token and information about the first access token; means for transmitting, based on the information and to the terminal device, a second request for accessing the terminal device, the second request comprising the first access token; and means for receiving a second response to the second request from the terminal device.

[0018] In a fourteenth aspect, there is provided an apparatus. The apparatus comprises means for receiving, at an authorization server and from an application, a first request for a first access token to be used by the application to access a terminal device; means for verifying validity of the first request; means for in response to the first request being valid, generating the first access token and information about the first access token; and means for transmitting, to the application, a first response to the first request, the first response comprising the first access token and the information about the first access token.

[0019] In a fifteenth aspect, there is provided an apparatus. The apparatus comprises means for receiving, at a terminal device and from an application, a second request for accessing the terminal device, the second request comprising a first access token for accessing the terminal device; means for verifying validity of the first access token; and means for transmitting, to the application, a second response to the second request based on a result of the verification.

[0020] In a sixteenth aspect, there is provided an apparatus. The apparatus comprises means for transmitting, from a terminal device to an authorization server, a fourth request for a second access token to be used by the terminal device to access an application; means for in response to the fourth request being determined as valid by the authorization server, receiving a fourth response to the fourth request from the authorization server, the fourth response comprising the second access token and information about the second access token; means for transmitting, based on the information and to the application, a fifth request for accessing the application, the fifth request comprising the second access token; and means for receiving a fifth response to the fifth request from the application.

[0021] In a seventeenth aspect, there is provided an apparatus. The apparatus comprises means for receiving, at an authorization server and from a terminal device, a fourth request for a second access token to be used by the terminal device to access an application; means for verifying validity of the fourth request; means for in response to the fourth request being valid, generating the second access token and information about the second access token; and means for transmitting, to the terminal device, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.

[0022] In an eighteenth aspect, there is provided an apparatus. The apparatus comprises means for receiving, at an application and from a terminal device, a fifth request for accessing the application, the fifth request comprising a second access token for accessing the application; means for verifying validity of the second access token; and means for transmitting, to the terminal device, a fifth response to the fifth request based on a result of the verification. [0023] In a nineteenth aspect, there is a computer readable storage medium comprising program instructions stored thereon. The instructions, when executed by an apparatus, cause the apparatus to perform the method according to any of the seventh to twelfth aspects.

[0024] It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Through the more detailed description of some example embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein:

[0026] Fig. 1 illustrates a block diagram of an example environment according to some example embodiments of the present disclosure;

[0027] Fig. 2 is a diagram illustrating an application registering to an authorization server according to some example embodiments of the present disclosure;

[0028] Fig. 3A illustrates an interaction diagram of an example process for authorizing an application to access a terminal device according to some example embodiments of the present disclosure;

[0029] Fig. 3B illustrates an interaction diagram of an example process for an application to access a terminal device by presenting an access token according to some example embodiments of the present disclosure; [0030] Fig. 3C illustrates an interaction diagram of an example process for verifying an access token by means of an authorization server generating the access token according to some example embodiments of the present disclosure;

[0031] Fig. 4A illustrates an interaction diagram of an example process for authorizing a terminal device to access an application according to some example embodiments of the present disclosure;

[0032] Fig. 4B illustrates an interaction diagram of an example process for authorizing a terminal device to access an application according to some example embodiments of the present disclosure; [0033] Fig. 4C illustrates an interaction diagram of an example process for a terminal device to access an application by presenting an access token according to some example embodiments of the present disclosure;

[0034] Fig. 4D is a diagram illustrating an authorization server providing a token verification service to an application according to some example embodiments of the present disclosure;

[0035] Fig. 4E illustrates an interaction diagram of an example process for verifying an access token by means of an authorization server generating the access token according to some example embodiments of the present disclosure;

[0036] Fig. 5 shows a flowchart of an example method according to some example embodiments of the present disclosure;

[0037] Fig. 6 shows a flowchart of an example method according to some example embodiments of the present disclosure;

[0038] Fig. 7 shows a flowchart of an example method according to some example embodiments of the present disclosure; [0039] Fig. 8 shows a flowchart of an example method according to some example embodiments of the present disclosure;

[0040] Fig. 9 shows a flowchart of an example method according to some example embodiments of the present disclosure;

[0041] Fig. 10 shows a flowchart of an example method according to some example embodiments of the present disclosure; [0042] Fig. 11 illustrates a simplified block diagram of an apparatus that is suitable for implementing embodiments of the present disclosure; and

[0043] Fig. 12 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure. [0044] Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

[0045] Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below. [0046] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0047] References in the present disclosure to “one embodiment,” “an embodiment,” “an example embodiment,” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an example embodiment, 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 embodiments whether or not explicitly described.

[0048] It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

[0049] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and/or “including”, when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/ or combinations thereof.

[0050] As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable):

(i) a combination of analog and/or digital hardware circuit(s) with software/firmware and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0051] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0052] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as 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), New Radio (NR) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G), the second generation (2G), 2.5G, 2.75G, the third generation (3G), the fourth generation (4G), 4.5G, the future fifth generation (5G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments 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. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0053] As described above, using the 5G network, not only more humans are getting connected for their private and/or public uses, but also machines, robots, cars and/or devices will used the 5G network for their critical communications. To meet all of the requirements, the 5GC is designed to be extremely secure. For devices registered to the 5GC, secure communications among them will be facilitated. It would be desired that this inbuilt security features could be reused by an external application connected to the 5GC to obtain authorization from the 5GC (in terms of access tokens) to access terminal devices registered to the 5GC. It would be also desired that this inbuilt security features could be reused by a terminal device registered to the 5GC (in terms of access tokens) to access applications that are using the 5GC.

[0054] Access tokens from the 5GC can provide an additional mechanism for scoping permissions of the applications or terminal devices. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented. Therefore, it would be desired that the 5GC can provide a service for generating an access token upon request from an application or a terminal device and providing the generated access token to the application or the terminal device securely. However, there is no such service in the 5GC at present.

[0055] Currently, OAuth 2.0 authorization framework has been proposed to enable a third- party application to obtain limited access to a web service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the web service, or by allowing the third-party application to obtain access on its own behalf. In OAuth 2.0 authorization framework, the client may request access to resources controlled by a resource owner and hosted by a resource server and may be issued a different set of credentials from those of the resource owner. Instead of using the credentials of the resource owner to access protected resources, the client may obtain an access token, that is, a string denoting a specific scope, lifetime, and other access attributes. The access token may be issued to the client by an authorization server with the approval of the resource owner. The client may use the access token to access the protected resources hosted by the resource server.

[0056] The 5GC comprises a lot of network entities, which provide different network functions. For example, the Network Function (NF) Repository Function (NRF) is the network entity in the 5GC which maintains NF profiles and available NF instances. It also provides service registration and discovery function so that NFs can discover each other. In addition, the NRF can provide an OAuth 2.0 authorization service to other NFs. It exposes a "Token Endpoint", where a NF service consumer can request an access token to access a NF service producer. The NRF may act as the OAuth 2.0 authorization server, the NF service consumer may act as the OAuth 2.0 client and the NF service producer may act as the OAuth 2.0 resource server. Examples of the NF service consumer may include, but not limited to, Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Network Exposure Function (NEF), Network Slice Selection Function (NSSF), Short Message Service Function (SMSF) and Authentication Server Function (AUSF).

[0057] In the 5G network, NFs securely expose capabilities and events to third-party Application Functions (AFs) via the NEF. The NEF also enables secure provision of information on authenticated and authorized AFs. The NEF shall authorize requests from AFs using the OAuth-based authorization mechanism. In a scenario, the NRF (that is, the authorization server) is configured to grant an AF (which is the client of the NRF) to access northbound Application Programming Interfaces (APIs) of the NEF.

[0058] Within the 5GC, the Unified Data Repository (UDM) provides unified data management services to other NFs, such as, AMF, SMF, SMSF, NEF, Gateway Mobile Focation Center (GMFC) and AUSF via the UDM service based interfaces (also referred to as “Nudm interfaces” in the following). For example, the UDM can provide a subscriber data management service, a UE context management service, a UE authentication service, an event exposure service, a parameter provision service and a Non-IP Data Delivery (NIDD) authorization service via the Nudm interfaces. [0059] Embodiments of the present disclosure provide a solution for authorizing access. In this solution, an external application connected to the 5GC can obtain an access token from the 5GC to access a terminal device registered to the 5GC. In addition, a terminal device connected to the 5GC can obtain an access token from the 5GC to access an application connected to the 5GC. Moreover, this solution enables verification of an access tokens by means of the authorization server which generates the access token.

[0060] Embodiments of the present disclosure can enable the ability to generate access tokens by the 5GC. This will enhance the functionality of the 5GC to perform third-party authorization. This will also create opportunities for government bodies to monitor activities of applications or devices using inbuilt 5GC functionalities like lawful interception gateway. Another advantage with respect to the 5GC doing authorization on behalf of a terminal device is that the terminal device does not need to know authentication credentials of the application. In the event of change in login details of the application, there is no need for the terminal device to reconfigure them in the terminal device, since the 5GC will do authorization on behalf of the terminal device. Likewise, another advantage with respect to the 5GC doing authorization on behalf of a third-party application is that the third-party application needs not change the authentication credentials in the case of change in device credentials. Access tokens from the 5GC can provide an additional mechanism for scoping permissions of applications or devices. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented, thereby improving security during communications.

[0061] Reference is now made to Fig. 1, which illustrates a block diagram of an environment 100 according to some example embodiments of the present disclosure. As shown in Fig. 1, for example, the environment 100 may include an application 110, a terminal device 120 and an authorization server 130. It is to be understood that the structure of the environment 100 is shown only for purpose of illustration, without suggesting any limitation to the scope of the present disclosure. Embodiments of the present disclosure may also be applied to an environment with a different structure.

[0062] The terminal device 120 may refer to any end device that is capable of wireless communication. By way of example rather than limitation, the terminal device 120 may also be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device 120 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 (loT) 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 the terminal device 120 is shown in Fig. 1 as a vehicle, it is to be understood that embodiments of the present disclosure are also applicable to other terminal devices than vehicles, such as mobile phones, sensors or so on. In the following description, the terms “terminal device”, “communication device”, “terminal”, “user equipment” and “UE” may be used interchangeably.

[0063] The application 110 can be any type of application, which may be deployed on any physical computer, server or virtual machine. For example, the application 110 may be a Land Mobile Network (PLMN) registered third-party AF. The authorization server 130 can be implemented in a single device or across a plurality of devices. In some example embodiments, the authorization server 130 can be implemented as a new NF. For example, the authorization server 130 can be implemented as a standalone NF or co-located with another NF in the 5GC, as will be described in the following. The authorization server 130 can provide an authorization service to the terminal device 120 and/or the application 110. For example, the authorization server 130 can generate an access token for accessing the terminal device 120 and share it with the application 110 per request from the application 110. The authorization server 130 can also generate an access tokens for accessing the application 110 and share it with the terminal device 120 per request from the terminal device 120. In addition, the authorization server 130 can also provide a verification service to the terminal device 120 and/or the application 110. For example, the authorization server 130 can verify validity of an access token per request from the terminal device 120 and/or the application 110.

[0064] In the environment 100, the application 110 may request, from the authorization server 130, an access token (also referred to as “first access token” in the following) for accessing the terminal device 120. In response to receiving the first access token from the authorization server 130, the application 110 may request access to the terminal device 120 using the first access token. The terminal device 120 may verify validity of the first access token by itself or by means of the authorization server 130. In response to the first access token being valid, the terminal device 120 may serve the request from the application 110. Otherwise, the terminal device 120 may discard the request the request from the application 110.

[0065] On the other hand, the terminal device 120 may request, from the authorization server 130, an access token (also referred to as “second access token” in the following) for accessing the application 110. In response to receiving the second access token from the authorization server 130, the terminal device 120 may request access to the application 110 using the second access token. The application 110 may verify validity of the second access token by itself or by means of the authorization server 130. In response to the second access token being valid, the application 110 may serve the request from the terminal device 120. Otherwise, the application 110 may discard the request the request from the terminal device 120.

[0066] In some example embodiments, in order to provide an authorization service to the application 110 for accessing the terminal device 120 registered to the 5GC, the NEF within the 5GC may expose new OAuth based APIs for the application 110 to invoke when it needs an access token. The APIs exposed by the NEF may comprise at least APIs for the application 110 to register with the authorization server 130 and APIs for the application 110 to request an access token from the authorization server 130. The application 110 may register to the authorization server 130 securely using RESTful APIs via the NEF.

[0067] Fig. 2 is a diagram illustrating an application registering to an authorization server via the NEF according to some example embodiments of the present disclosure. Fig. 2 shows the application 110, the NEF 210 and the authorization server 130. The NEF 210 may provide API(s) 201 to be invoked by the application 110. The NEF 210 may also comprise a plug-in 202, which can implement OAuth related functionality.

[0068] As shown in Fig. 2, the application 110 may send a registration request to the NEF 210 by invoking the API(s) 201. The registration request may arrive at the plug-in 202 in the NEF 210. The plug-in 202 may forward the registration request to the authorization server 130 on behalf of the application 110. In response to receiving the registration request from the application 110, the authorization server 130 may allocate a client identifier (ID) and a client secret for the application 110 and transmit a registration response including the client ID and the client secret to the plug-in 202 located in the NEF 210. The NEF 210 will in turn provide the registration response to the application 110 on behalf of the authorization server 130 securely. Once the application 110 is registered to the authorization server 130, subsequent request and response dialogues between the application 110 and the authorization server 130 will be translated by the NEF 210 (such as, the plug-in 202) which acts as an intermediate point between the application 110 and the authorization server 130.

[0069] In some example embodiments, the authorization server 130 may be implemented as a NF co-located with the NRF. That is, the NRF in the 5GC may be enhanced to support generation of the access token for accessing the terminal device connected to the 5GC and provision of the access token to the application via the NEF. To achieve this, the authorization server 130 co-located with the NRF may interact with the UDM via Nudm service based interfaces. For example, the NRF (the authorization server 130) may subscribe to Event Exposure Service in the UDM to get notified when a terminal device is registered to the UDM or when the terminal device is deregistered from the UDM. Once a terminal device (such as, the terminal device 120) is registered to the UDM, the authorization server 130 will be authorized to generate an access token for accessing the terminal device and share it with an application (such as, the application 110) per request from the application. Once the terminal device is deregistered from the UDM, subsequent request from the application for access tokens targeted to the terminal device will be discarded.

[0070] Alternatively, in some embodiments, the authorization server 130 may be implemented as a NF co-located with the UDM. That is, the UDM in the 5GC may be enhanced to incorporate the functionality of the authorization server 130. If a terminal device (such as, the terminal device 120) is registered to the UDM, the authorization server 130 in the UDM can service an authorization request from an application (such as, the application 110) via the NEF.

[0071] Fig. 3 A illustrates an interaction diagram of an example process 310 for authorizing an application to access a terminal device according to some example embodiments of the present disclosure. The process 310 may involve the application 110 and the authorization server 130 as shown in Fig. 1. The process 310 may also involve the NEF 210 as shown in Fig. 2 and a UDM 301. [0072] In the example as shown in Fig. 3 A, it is assumed that the application 110 registered to the 5GC is trying to do a software update to the terminal device 120 (for example, a car using the 5G network) connected to the 5G network. The application 110 may receive a software update request for the terminal device 120 from an application server (not shown in Fig. 3 A) connected to the application 110. The application 110 may then initiate a request for an access token to the authorization server 130.

[0073] As shown in Fig. 3 A, initially, the application 110 may register to the authorization server 130 securely using RESTful APIs via the NEF 210, as shown by 311 in Fig. 3A and as described above with reference to Fig. 2. The application 110 may transmit 312, to the NEF 210, a request (also referred to as “first request”) for a first access token to be used by the application 110 to access the terminal device 120. The NEF 210 (such as, the plug-in 202) may receive the first request from the application 110 and forward 313 the first request to the authorization server 130 on behalf of the application 110.

[0074] In response to receiving the first request from the application 110, the authorization server 130 may verify 315 validity of the first request. For example, the authorization server 130 may extract, from the first request, the client ID (also referred to as “first identifier” in the following) of the application 110 and determine, based on the first ID, whether the application 110 has been registered to the authorization server 130. The authorization server 130 may also extract an ID of the terminal device 120 for which the first access token is required. For example, the ID of the terminal device 120 can be a Mobile Station International Subscriber Directory Number (MSISDN) or an external ID. The authorization server 130 may obtain device registration information from the UDM 301, as shown by 314 in Fig. 3 A. The authorization server 130 may determine, based on the second ID and the device registration information obtained from the UDM 301 , whether the terminal device 120 has been registered to the UDM 301.

[0075] In response to the first request being valid, the authorizations server 130 may generate the first access token and information about the first access token, and transmit 316 a first response which includes the first access token and the information about the first access token to the NEF 210. The authorization server 130 may digitally sign the generated first access token based on a shared secret or private key. In some example embodiments, the first access token may be a JSON Web Token (JWT) and a derivative of long-term secret key K stored in the 5GC Authentication credential Repository and Processing Function (ARPF) can be used to sign the JWT, since the 5GC and the terminal device 120 are sharing the same key. It is to be understood that the terminal device 120 should be able to handle the JWT. Alternatively, in some example embodiments, the first access token may be an opaque token. The generated information about the first access token may include metadata of the first access token, such as, expiration date, a scope of the token, or so on. [0076] The NEF 210 (such as, the plug-in 202) may receive 316 the first response from the authorization server 130 and forward 317 the first response to the application 110 on behalf of the authorization server 130.

[0077] Fig. 3B illustrates an interaction diagram of an example process 320 for an application to access a terminal device by presenting an access token according to some example embodiments of the present disclosure. For example, the process 320 may be executed subsequent to the process 310. The process 320 may involve the application 110 and the terminal device 120 as shown in Fig. 1.

[0078] As shown in Fig. 3B, in response to receiving the first access token as well as related information from the authorization server 130, the application 110 may transmit 321, based on the information (such as, the expiration date, the allowed access scope, or so on) and to the terminal device 120, a second request for accessing the terminal device 120. For example, the second request may comprise the first access token received from the authorization server 130.

[0079] In response to receiving the second request from the application 110, the terminal device 120 may verify 322 validity of the first access token. In some example embodiments, for example, the first access token may be a self-contained JWT. In this case, the terminal device 120 may verify validity of the first access token by itself. Alternatively, in other example embodiments, for example, the first access token may be an opaque token. The opaque token is a random sequence of alphanumeric characters that contains no inherent meaning. In this case, the terminal device 120 may verify validity of the first access token by means of the authorizations server 130, as will be described below with reference to Fig. 3C.

[0080] The terminal device 120 may transmit 323, to the application 110, a second response to the second request based on a result of the verification. In some example embodiments, in response to the first access token being valid, the terminal device 120 may transmit the second response to the application 110 for enabling the application 110 to access the terminal device 120. In some example embodiments, in response to the first access token being invalid, the terminal device 120 may transmit the second response to the application 110 for disabling the application 110 to access the terminal device 120.

[0081] In some example embodiments, in order to provide a token verification service to the terminal device 120, the authorization server 130 can be enhanced with a software functionality to determine the active state of an access token and to determine the metadata of the token. The metadata may include, for example, the expiration time of the token (indicating whether the access token is currently active), the scope of the token, or so on. This token verification ability of the authorization server 130 can be used by the terminal device 120 to query, verify and get information about the access token regardless of whether or not the information is carried by the access token itself.

[0082] Fig. 3C illustrates an interaction diagram of an example process 322 for verifying an access token by means of an authorization server generating the access token according to some example embodiments of the present disclosure. The process 322 can be considered as an example implementation of the action 322 as shown in Fig, 3B. For example, the process 322 may involve the terminal device 120, the authorization server 130 and an AMF 302 within the 5GC.

[0083] As shown in Fig. 3C, for example, in response to receiving from the application 110 the second request (which may comprise the first access token to be verified), the terminal device 120 may transmit 331, to the AMF 302, a third request for verifying the first access token. For example, in this case, the terminal device 120 may have been registered to the 5G network. The terminal device 120 may incorporate the third request into a service request and transmit the service request to Radio Access Network (RAN). The RAN may forward the third request to the AMF 302 in N2 message. In response to receiving the third request, the AMF 302 may have a connection to the authorization server 130 and may forward 332 the third request to the authorization server 130. In response to receiving the third request from the terminal device 120, the authorization server 130 may verify 333 validity of the first access token and transmit 334, to the AMF 302, a third response to the third request. The third response may include the metadata of the first access token, such as, the expiration date, the scope of the token, or so on. The AMF 302 may forward 335 the third response to the terminal device 120. For example, the AMF 302 may transmit the third response to the RAN in N2 message. The RAN may incorporate the third response in a service accept message and forward the service accept message to the terminal device 120. [0084] In response to receiving the third response from the authorization server 130, the terminal device 120 may verify 336, based on the third response, validity of the first access token. In some example embodiments, the terminal device 120 may extract, from the second request, first information about the first access token, such as, the date of requested access, the scope of the requested access, or so on. The terminal device 120 may also extract, from the third response, second information about the first access token, such as, the expiration data, the scope of the token, or so on. Then, the terminal device 120 may determine whether the first information matches the second information. In response to the first information matching the second information, the terminal device 120 may determine the first access token as valid. Otherwise, the terminal device 120 may determine the first access token as invalid.

[0085] It can be seen that, embodiments of the present disclosure enable the ability to generate and verify access tokens by the 5GC. This will enhance the functionality of the 5GC to perform third-party authorization. This will also create opportunity for government bodies to monitor activities of a third-party application using inbuilt 5GC functionalities like lawful interception gateway. Another advantage with respect to the 5GC doing authorization on behalf of a third-party application is that the third-party application needs not change the authentication credentials in the case of change in device credentials. Access tokens from the 5GC can provide an additional mechanism for scoping permissions of the terminal device. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented, thereby improving security during communications. In the case of defining the authorization server as a new NF would allow such a case that the new service is provided by a third party instead of the network operator. For example, the authorization server could be from a company which will then handle authorization of terminal devices of that company and authorization would not be controlled by the network operator. In addition, the token verification ability of the authorization server can be used by the terminal device to query, verify and get information about the access token regardless of whether or not the information is carried by the access token itself.

[0086] As described above with reference to Fig. 1, in some example embodiments, the terminal device 120 may also request, from the authorization server 130, a second access token for accessing the application 110. In response to receiving the second access token from the authorization server 130, the terminal device 120 may request access to the application 110 using the second access token. The application 110 may verify validity of the second access token by itself or by means of the authorization server 130. In response to the second access token being valid, the application 110 may serve the request from the terminal device 120. Otherwise, the application 110 may discard the request the request from the terminal device 120.

[0087] In some example embodiments, during device registration with the 5GC, the terminal device 120 may request the second access token from the authorization server 130. For example, the application 110 may be a Land Mobile Network (PLMN) registered third- party AF. The second access token may be generated and included in the registration accept message. In some example embodiments, the generated access token can be targeted to one or more AFs, as will be described below with reference to Fig. 4A. In this case, for example, the AMF may interact with the authorization server 130 using well-defined APIs to obtain the generated access token.

[0088] Fig. 4A illustrates an interaction diagram of an example process 410 for authorizing a terminal device to access an application according to some example embodiments of the present disclosure. The process 410 may involve the terminal device 120 and the authorization server 130 as shown in Fig. 1. The process 410 may also involve the NEF 210 as shown in Fig. 2, the UDM 301 as shown in Fig. 3A and the AMF 302 as shown in Fig. 3C. In addition, the process 410 may also involve an AUSF 401 and a PCF 402 within the 5GC.

[0089] In the example as shown in Fig. 4A, it is assumed that the terminal device 120 (for example, a car using the 5G network) is trying to report a software bug and ask for software update from the application 110 connected to the 5G network. The terminal device 120 may initiate a request for an access token to the authorization server 130.

[0090] As shown in Fig. 4A, the terminal device 120 may incorporate a request (also referred to as “fourth request” in the following) for an access token (such as, the second access token) to be used by the terminal device 120 to access one or more applications (such as, the application 110) into a registration request to be transmitted to the AMF 302. For example, the terminal device 120 may incorporate a new parameter for requesting the second access token in its registration request message towards the AMF 302. The terminal device 120 may transmit 411, to the AMF 302, the registration request.

[0091] Then, identity (such as, Subscriber Concealed Identifier (SUCI)) exchange may be performed 412 between the terminal device 120 and the AMF 302. The AMF 302 may select 413 an associated AUSF 401. Once the AUSF 401 is selected, the AUSF 401 may execute 414 authentication of the terminal device 120. The AUSF 401 may select a UDM

301 and get the authentication data from the UDM 301. Once the authentication is completed, the AMF 302 may select 415 a UDM 301 and register 416 to the UDM 301. At this stage, the UDM 301 may notify 417 the authorization server 130 of an event that the terminal device 120 is registered to the UDM 301.

[0092] Once a response indicating successful registration reaches the AMF 302, the AMF

302 may retrieve 418 the Access and Mobility Subscription data from the UDM 301. The subscription data for the terminal device 120 will include a list of applications (such as, the application 110) for which the terminal device 120 is authorized to get the access token. It is to be understood that, for each terminal device, which has signed up for the PLMN based authorization service, is provisioned with a list of AFs that they are authorized to access in the UDM. The UDM may return this list to the AMF, as shown by 418 in Fig. 4A.

[0093] Subsequently, the AMF 302 may transmit 420, to the authorization server 130, a request for getting an access token (such as, the second access token) to access the applications (such as, the application 110) to which the terminal device 120 is interested to communicate. For example, the request may include the list of AFs obtained 418 from the UDM 301. The authorization server 130 may optionally verify validity of the request. For example, the authorization server 130 may check whether the terminal device 120 has been authenticated to the network. This can be done based on a notification that the authorization server 130 received 417 from the UDM 301 when the terminal device 120 is authenticated. If the terminal device 120 is authenticated, the authorization server 130 (for example, co located with the NRF) may further check availability of the application 110 based on application registration information obtained 419 from the NEF 210. It is to be understood that, the interaction between the authorization server 130 and the NEF 210 have been described above with reference to Fig. 2.

[0094] In response to the request being valid, the authorizations server 130 may generate an access token (such as, the second access token) and related information, and transmit a fourth response which includes the second access token and the information about the second access token to the AMF 302, as shown by 420 in Fig. 4A. The authorization server 130 may include the list of AFs (such as, the application 110) in the generated second access token, which determines the scope of access for the terminal device 120. The authorization server 130 may digitally sign the generated second access token based on a shared secret or private key. In some embodiments, the second access token may be a JSON Web Token (JWT) and a common shared secret between the application 110 and the 5GC can be used to sign the JWT. It is to be understood that the application 110 should be able to handle the JWT. Alternatively, in some example embodiments, the second access token may be an opaque token. The generated information about the second access token may include metadata of the second access token, such as, expiration date, a scope of the token, or so on.

[0095] The AMF 302 may select 421 an associated PCF 402. Then, a procedure of access and mobility policy association may be performed between the AMF 302 and the PCF 402, as shown by 422 in Fig. 4A. The AMF 302 may include the second access token as well as related information as part of a registration accept message and transmit 423 the registration accept message to the terminal device 120. When the terminal device 120 gets the second access token, the terminal device 120 can use the second access token to access the application 110 if necessary. The list of AFs in the access token will determine which AFs the terminal device 120 is authorized to access. [0096] Alternatively, in some example embodiments, the terminal device 120 may request the second access token as part of a session establishment procedure. This mechanism enables the terminal device 120 to obtain the second access token for accessing the application 110. In some example embodiments, the generated access token can be targeted to one or more AFs. For example, the terminal device 120 may include intended applications in the request, such that the generated access token is targeted to those intended applications. In this case, for example, the SMF may interact with the authorization server 130 to obtain the second access token specific to the application 110 and provide it to the terminal device 120.

[0097] Fig. 4B illustrates an interaction diagram of an example process 430 for authorizing a terminal device to access an application according to some example embodiments of the present disclosure. The process 430 may involve the terminal device 120 and the authorization server 130 as shown in Fig. 1. The process 430 may also involve the NEF 210 as shown in Fig. 2 and the UDM 301 as shown in Fig. 3. In addition, the process 410 may also involve the AMF 302, a SMF 403, a UPF 404 an AUSF 401 and a PCF 402 within the 5GC.

[0098] In the example as shown in Fig. 4B, it is assumed that the terminal device 120 (for example, a car using the 5G network) is trying to report a software bug and ask for software update from the application 110 connected to the 5G network. The terminal device 120 may initiate a request for an access token to the authorization server 130.

[0099] As shown in Fig. 4B, the terminal device 120 may incorporate a request (also referred to as “fourth request” in the following) for an access token (such as, the second access token) to be used by the terminal device 120 to access one or more applications (such as, the application 110) into a session establishment request to be transmitted to the AMF 302. For example, the terminal device 120 may incorporate a new parameter for the second access token in its Packet Data Unit (PDU) session establishment Non-Access Stratum (NAS) message towards the AMF 302. The terminal device 120 may transmit 431, to the AMF 302, the PDU session establishment request.

[00100] The AMF 302 may select 432 an associated SMF 403. In a subsequent session management (SM) context request transmitted from the AMF 302 to the SMF 403, the fourth request to obtain the second access token is forwarded by the AMF 302 to the SMF 403, as shown by 433 in Fig. 4B. When the SMF 403 receives the SM context request, the SMF 403 may register subscriber (for example, identity of the terminal device 120 and identity of the PDU session) to the UDM 301 and retrieve the subscription data for the terminal device 120, as shown by 435 in Fig. 4B. Then, the SMF 403 may inform 436 successful creation of SM context for the PDU session to the AMF 302. The SMF 403 may select the Data Network Name (DNN) corresponding to the terminal device which initiates the PDU session. Based on DNN settings in the SMF 403, the SMF 403 may connect with the authorization server 130 to obtain the second access token.

[00101] Then, the SMF 403 may forward 437 the fourth request for the second access token to the authorization server 130. The authorization server 130 may optionally verify validity of the fourth request. For example, the authorization server 130 may check if the terminal device 120 has been registered with the UDM 301. In addition, the authorization server 130 may also check, based on application registration information obtained 434 from the NEF 210, if the application 110 which the terminal device 120 requests to access has been registered with the NEF 210. It is to be understood that, the interaction between the authorization server 130 and the NEF 210 have been described above with reference to Fig. 2.

[00102] In response to the fourth request being valid, the authorizations server 130 may generate an access token (such as, the second access token) and related information, and transmit a fourth response which includes the second access token and the information about the second access token to the SMF 403, as shown by 437 in Fig. 4B. The authorization server 130 may include the list of AFs (such as, the application 110) in the generated second access token, which determines the scope of access for the terminal device 120. The authorization server 130 may digitally sign the generated second access token based on a shared secret or private key. The second access token can be a JSON Web Token (JWT) and a common shared secret between the application 110 and the 5GC can be used to sign the JWT. It is to be understood that the application 110 should be able to handle the JWT. Alternatively, in some example embodiments, the second access token may be an opaque token. The generated information about the second access token may include metadata of the second access token, such as, expiration date, a scope of the token, or so on.

[00103] The SMF 403 may select 438 an associated PCF 402, and then a procedure of SM policy association may be performed between the AMF 302 and the PCF 402, as shown by 439 in Fig. 4B. Alternatively, or in addition, the SMF 403 may select 440 an associated UPF 404, and then a procedure of SM policy association modification may be performed between the AMF 302 and the PCF 402, as shown by 441 in Fig. 4B. Configurations may be forwarded from the SMF 403 to the UPF 404, as shown by 442 in Fig. 4B.

[00104] At this stage, the SMF 403 is ready to reply back the required information to the terminal device 120. The SMF 403 may forward 443 the second access token and the related information to the AMF 302 in Nl, N2 SM message transfer and the AMF 302 may forward 444 the second access token and the related information to the terminal device 120. When the terminal device 120 gets the second access token, the terminal device 120 can use the access token to access the application 110 if necessary. The list of AFs in the access token will determine which AFs the terminal device 120 is authorized to access.

[00105] Fig. 4C illustrates an interaction diagram of an example process 450 for a terminal device to access an application by presenting an access token according to some example embodiments of the present disclosure. For example, the process 450 may be executed subsequent to the process 410 or 430. The process 450 may involve the application 110 and the terminal device 120 as shown in Fig. 1.

[00106] As shown in Fig. 4C, in response to receiving the second access token as well as related information from the authorization server 130, the terminal device 120 may transmit 451, based on the information (such as, the expiration date, the allowed access scope, or so on) and to the application 110, a fifth request for access the application 110. For example, the fifth request may comprise the second access token received from the authorization server 130.

[00107] In response to receiving the fifth request from the terminal device 120, the application 110 may verify 452 validity of the second access token. In some example embodiments, for example, the second access token may be a self-contained JWT. In this case, the application 110 may verify validity of the second access token by itself. Alternatively, in other example embodiments, for example, the second access token may be an opaque token. In this case, the application 110 may verify validity of the second access token by means of the authorizations server 130, as will be described below with reference to Figs. 4D and 4E.

[00108] The application 110 may transmit 453, to the terminal device 120, a fifth response to the fifth request based on a result of the verification. In some example embodiments, in response to the second access token being valid, the application 110 may transmit the fifth response to the terminal device 120 for enabling the terminal device 120 to access the application 110. In some example embodiments, in response to the second access token being invalid, the application 110 may transmit the fifth response to the terminal device 120 for disabling the terminal device 120 to access the application 110.

[00109] In some example embodiments, in order to provide a token verification service to the application 110, the authorization server 130 can be enhanced with a software functionality to determine the active state of an access token and to determine the metadata of the token. The metadata may include, for example, the expiration time of the token (indicating whether the access token is currently active), the scope of the token, or so on. This token verification ability of the authorization server 130 can be used by the application 110 to query, verify and get information about the access token regardless of whether or not the information is carried by the access token itself. For example, new APIs can be introduced in the authorization server 130 that provides the token authorization service. The application 110 may use the new APIs for token verification via the NEF. In addition, the NEF also need to be enhanced with equivalent northbound APIs. [00110] Fig. 4D is a diagram illustrating an authorization server providing a token verification service to an application via the NEF according to some example embodiments of the present disclosure. Fig. 4D shows the application 110, the NEF 210 and the authorization server 130. The NEF 210 may provide API(s) 203 for providing a token verification service to the application 110. The NEF 210 may also comprise a plug-in 204, which can implement token verification functionality.

[00111] As shown in Fig. 4D, in response to receiving the fifth request from the terminal device 120 (for example, the fifth request comprises the second access token to be verified), the application 110 may transmit a sixth request for verifying the second access token to the NEF 210 by invoking the API(s) 203. The sixth request may arrive at the plug-in 204 in the NEF 210. The plug-in 204 may forward the sixth request to the authorization server 130 on behalf of the application 110. In response to receiving the sixth request from the application 110, the authorization server 130 may verify validity of the second access token and transmit, to the plug-in 204 located in the NEF 210, a sixth response to the sixth request. The sixth response may include the metadata of the second access token, such as, the expiration date, the scope of the token, or so on. The NEF 210 will in turn provide the sixth response to the application 110 on behalf of the authorization server 130 securely.

[00112] Fig. 4E illustrates an interaction diagram of an example process 452 for verifying an access token by means of an authorization server generating the access token according to some example embodiments of the present disclosure. The process 452 can be considered as an example implementation of the action 452 as shown in Fig. 4C. For example, the process 452 may involve the application 110, the authorization server 130 and the NEF 210 as shown in Fig. 4D.

[00113] As shown in Fig. 4E, , for example, in response to receiving from the terminal device 120 the fifth request (which may comprise the second access token to be verified), the application 110 may transmit 461 a sixth request for verifying the second access token to the NEF 210. For example, in this case, the application 110 may have been registered to the NEF 210. The NEF 210 (such as, the plug-in 204) may receive the sixth request from the application 110 and forward 462 the sixth request to the authorization server 130 on behalf of the application 110. In response to receiving the sixth request from the application 110, the authorization server 130 may verify 463 validity of the second access token and transmit 464, to the NEF 210, a sixth response to the sixth request. The sixth response may include the metadata of the second access token, such as, the expiration date, the scope of the token, or so on. The NEF 210 may forward 465 the sixth response to the application 110 on behalf of the authorization server 130 securely. [00114] In response to receiving the sixth response from the authorization server 130, the application 110 may verify 466, based on the sixth response, validity of the second access token. In some example embodiments, the application 110 may extract, from the fifth request, third information about the second access token, such as, the date of requested access, the scope of the requested access, or so on. The application 110 may also extract, from the sixth response, fourth information about the second access token, such as, the expiration data, the scope of the token, or so on. Then, the application 110 may determine whether the third information matches the fourth information. In response to the third information matching the fourth information, the application 110 may determine the second access token as valid. Otherwise, the application 110 may determine the second access token as invalid.

[00115] It can be seen that, embodiments of the present disclosure enable the ability to generate access token by the 5GC. This will enhance the functionality of the 5GC to perform third-party authorization. This will also create opportunity for government bodies to monitor activities of a terminal device using inbuilt 5GC functionalities like lawful interception gateway. Another advantage with respect to the 5GC doing authorization on behalf of a terminal device is that the terminal device does not need to know authentication credentials of the application. In the event of change in login details of the application, there is no need for the terminal device to reconfigure them in the terminal device, since the 5GC will do authorization on behalf of the terminal device. Access tokens from the 5GC can provide an additional mechanism for scoping permissions of the application. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented, thereby improving security during communications. In addition, the token verification ability of the authorization server can be used by the application to query, verify and get information about the access token regardless of whether or not the information is carried by the access token itself.

[00116] Fig. 5 shows a flowchart of an example method 500 according to some example embodiments of the present disclosure. The method 500 can be implemented at the application 110 as shown in Fig. 1. It is to be understood that the method 500 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[00117] At block 510, the application 110 transmits, to the authorization server 130, a first request for a first access token to be used by the application 110 to access the terminal device 120. [00118] At block 520, in response to the first request being determined as valid by the authorization server 130, the application 110 receives a first response to the first request from the authorization server 130, the first response comprising the first access token and information about the first access token.

[00119] At block 530, the application 110 transmits, based on the information and to the terminal device 120, a second request for accessing the terminal device 120, the second request comprising the first access token.

[00120] At block 540, the application 110 receives a second response to the second request from the terminal device 120.

[00121] In some example embodiments, transmitting the first request comprises transmitting, via a NEF, the first request to the authorization server 130. In some example embodiments, receiving the first response comprises receiving, via the NEF, the first response from the authorization server 130.

[00122] In some example embodiments, the method 500 further comprises prior to transmitting the first request, registering the application 110 to the authorization server 130 via a NEF.

[00123] Fig. 6 shows a flowchart of an example method 600 according to some example embodiments of the present disclosure. The method 600 can be implemented at the authorization server 130 as shown in Fig. 1. It is to be understood that the method 600 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[00124] At block 610, the authorization server 130 receives, from the application 110, a first request for a first access token to be used by the application 110 to access the terminal device 120.

[00125] At block 620, the authorization server 130 verifies validity of the first request.

[00126] At block 630, in response to the first request being valid, the authorization server 130 generates the first access token and information about the first access token.

[00127] At block 640, the authorization server 130 transmits, to the application 110, a first response to the first request, the first response comprising the first access token and the information about the first access token.

[00128] In some example embodiments, receiving the first request comprises receiving, via a NEF, the first request from the application 110. In some example embodiments, transmitting the first response comprises transmitting, via the NEF, the first response to the application 110.

[00129] In some example embodiments, verifying validity of the first request comprises extracting, from the first request, a first identifier of the application 110 and a second identifier of the terminal device 120; determining, based on the first identifier, whether the application 110 has been registered to the authorization server 130; determining, based on the second identifier and device registration information obtained from a UDM, whether the terminal device 120 has been registered to the UDM; in response to determining that the application 110 has been registered to the authorization server 130 and the terminal device 120 has been registered to the UDM, determining the first request as valid; and in response to determining that the application 110 has not been registered to the authorization server 130 or the terminal device 120 has not been registered to the UDM, determining the first request as invalid.

[00130] In some example embodiments, the method 600 further comprises receiving, from the terminal device 120, a third request for verifying the first access token; and transmitting, to the terminal device 120, a third response to the third request, the third response comprising the information about the first access token.

[00131] In some example embodiments, receiving the third request comprises receiving, via an AMF, the third request from the terminal device 120. In some example embodiments, transmitting the third response comprises transmitting, via the AMF, the third response to the terminal device 120.

[00132] Fig. 7 shows a flowchart of an example method 700 according to some example embodiments of the present disclosure. The method 700 can be implemented at the terminal device 120 as shown in Fig. 1. It is to be understood that the method 700 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[00133] At block 710, the terminal device 120 receives, from the application 110, a second request for accessing the terminal device 120, the second request comprising a first access token for accessing the terminal device 120.

[00134] At block 720, the terminal device 120 verifies validity of the first access token. [00135] At block 730, the terminal device 120 transmits, to the application 110, a second response to the second request based on a result of the verification.

[00136] In some example embodiments, verifying validity of the first access token comprises transmitting, to the authorizations server 130 generating the first access token, a third request for verifying the first access token; receiving, from the authorization server 130, a third response to the third request; and verifying validity of the first access token based on the third response.

[00137] In some example embodiments, transmitting the third request comprises incorporating the third request into a service request to be transmitted to an AMF; and transmitting, via RAN, the service request to the AMF, such that the AMF forwards the third request to the authorization server 130. In some example embodiments, receiving the third response comprises in response to the AMF receiving the third response from the authorization server 130, receiving, via the RAN and from the AMF, a service accept message comprising the third response.

[00138] In some example embodiments, verifying validity of the first access token based on the third response comprises extracting, from the second request, first information about the first access token; extracting, from the third response, second information about the first access token; in response to the first information matching the second information, determining the first access token as valid; and in response to the first information not matching the second information, determining the first access token as invalid.

[00139] In some example embodiments, transmitting the second response comprises in response to the first access token being valid, transmitting the second response for enabling the application 110 to access the terminal device 120; and in response to the first access token being invalid, transmitting the second response for disabling the application 110 to access the terminal device 120.

[00140] Fig. 8 shows a flowchart of an example method 800 according to some example embodiments of the present disclosure. The method 800 can be implemented at the terminal device 120 as shown in Fig. 1. It is to be understood that the method 800 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[00141] At block 810, the terminal device 120 transmits, to the authorization server 130, a fourth request for a second access token to be used by the terminal device 120 to access the application 110. [00142] At block 820, the terminal device 120 receives a fourth response to the fourth request from the authorization server 130, the fourth response comprising the second access token and information about the second access token.

[00143] At block 830, the terminal device 120 transmits, based on the information and to the application 110, a fifth request for accessing the application 110, the fifth request comprising the second access token.

[00144] At block 840, the terminal device 120 receives a fifth response to the fifth request from the application 110.

[00145] In some example embodiments, transmitting the fourth request comprises incorporating the fourth request into a registration request to be transmitted to an AMF; and transmitting the registration request to the AMF, such that the AMF registers the terminal device 120 to a UDM and forwards the fourth request to the authorization server 130.

[00146] In some example embodiments, receiving the fourth response comprises in response to the AMF receiving the fourth response from the authorization server 130, receiving a registration response to the registration request from the AMF, the registration response comprising the fourth response.

[00147] In some example embodiments, transmitting the fourth request comprises incorporating the fourth request into a session establishment request to be transmitted to an AMF; and transmitting the session establishment request to the AMF, such that the AMF forwards the fourth request to the authorization server 130 via a SMF.

[00148] In some example embodiments, receiving the fourth response comprises in response to the AMF receiving the fourth response from the authorization server 130 via the SMF, receiving a session establishment response to the session establishment request from the AMF, the session establishment response comprising the fourth response.

[00149] Fig. 9 shows a flowchart of an example method 900 according to some example embodiments of the present disclosure. The method 900 can be implemented at the authorization server 130 as shown in Fig. 1. It is to be understood that the method 900 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[00150] At block 910, the authorization server 130 receives, from the terminal device 120, a fourth request for a second access token to be used by the terminal device 120 to access the application 110.

[00151] At block 920, the authorization server 130 verifies validity of the fourth request.

[00152] At block 930, in response to the fourth request being valid, the authorization server 130 generates the second access token and information about the second access token.

[00153] At block 940, the authorization server 130 transmits, to the terminal device 120, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.

[00154] In some example embodiments, receiving the fourth request comprises receiving, via an AMF, the fourth request from the terminal device 120. In some example embodiments, transmitting the fourth response comprises transmitting, via the AMF, the fourth response to the terminal device 120.

[00155] In some example embodiments, receiving the fourth request comprises receiving, via a SMF, the fourth request from the terminal device 120. In some example embodiments, transmitting the fourth response comprises transmitting, via the SMF, the fourth response to the terminal device 120.

[00156] In some example embodiments, verifying validity of the fourth request comprises extracting, from the fourth request, a first identifier of the application 110 and a second identifier of the terminal device 120; determining, based on the first identifier and application registration information obtained from a NEF, whether the application 110 has been registered to the NEF; determining, based on the second identifier and device registration information obtained from a UDM, whether the terminal device 120 has been registered to the UDM; in response to determining that the application 110 has been registered to the NEF and the terminal device 120 has been registered to the UDM, determining the fourth request as valid; and in response to determining that the application 110 has not been registered to the NEF or the terminal device 120 has not been registered to the UDM, determining the fourth request as invalid.

[00157] In some example embodiments, the method 900 further comprises receiving, from the application 110, a sixth request for verifying the second access token; and transmitting, to the application 110, a sixth response to the sixth request, the sixth response comprising the information about the second access token.

[00158] In some example embodiments, receiving the sixth request comprises receiving, via a NEF, the third request from the application 110. In some example embodiments, transmitting the sixth response comprises transmitting, via the NEF, the sixth response to the application 110.

[00159] Fig. 10 shows a flowchart of an example method 1000 according to some example embodiments of the present disclosure. The method 1000 can be implemented at the application 110 as shown in Fig. 1. It is to be understood that the method 1000 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[00160] At block 1010, the application 110 receives, from the terminal device 120, a fifth request for accessing the application 110, the fifth request comprising a second access token for accessing the application 110.

[00161] At block 1020, the application 110 verifies validity of the second access token

[00162] At block 1030, the application 110 transmits, to the terminal device 120, a fifth response to the fifth request based on a result of the verification.

[00163] In some example embodiments, verifying validity of the second access token comprises transmitting, to the authorizations server 130 generating the second access token, a sixth request for verifying the second access token; receiving, from the authorization server 130, a sixth response to the sixth request; and verifying validity of the second access token based on the sixth response.

[00164] In some example embodiments, transmitting the sixth request comprises transmitting, via a NEF, the sixth request to the authorization server 130. In some example embodiments, receiving the sixth response comprises receiving, via the NEF, the sixth response from the authorization server 130.

[00165] In some example embodiments, verifying validity of the second access token based on the sixth response comprises extracting, from the fifth request, third information about the second access token; extracting, from the sixth response, fourth information about the second access token; in response to the third information matching the fourth information, determining the second access token as valid; and in response to the third information not matching the fourth information, determining the second access token as invalid.

[00166] In some example embodiments, transmitting the fifth response comprises in response to the second access token being valid, transmitting the fifth response for enabling the terminal device 120 to access the application 110; and in response to the second access token being invalid, transmitting the fifth response for disabling the terminal device 120 to access the application 110.

[00167] In some example embodiments, an apparatus capable of performing the method 500 may comprise means for performing the respective steps of the method 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00168] In some example embodiments, the apparatus capable of performing the method 500 (for example, an apparatus for running the application 110) comprises: means for transmitting, from an application to an authorization server, a first request for a first access token to be used by the application to access a terminal device; means for in response to the first request being determined as valid by the authorization server, receiving a first response to the first request from the authorization server, the first response comprising the first access token and information about the first access token; means for transmitting, based on the information and to the terminal device, a second request for accessing the terminal device, the second request comprising the first access token; and means for receiving a second response to the second request from the terminal device.

[00169] In some example embodiments, the means for transmitting the first request comprises means for transmitting, via a Network Exposure Function, the first request to the authorization server.

[00170] In some example embodiments, the means for receiving the first response comprises means for receiving, via the Network Exposure Function, the first response from the authorization server.

[00171] In some example embodiments, the apparatus capable of performing the method 500 further comprises means for prior to transmitting the first request, registering the application to the authorization server via a Network Exposure Function.

[00172] In some example embodiments, an apparatus capable of performing the method 600 may comprise means for performing the respective steps of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00173] In some example embodiments, the apparatus capable of performing the method 600 (for example, the authorization server 130) comprises: means for receiving, at an authorization server and from an application, a first request for a first access token to be used by the application to access a terminal device; means for verifying validity of the first request; means for in response to the first request being valid, generating the first access token and information about the first access token; and means for transmitting, to the application, a first response to the first request, the first response comprising the first access token and the information about the first access token.

[00174] In some example embodiments, the means for receiving the first request comprises: means for receiving, via a Network Exposure Function, the first request from the application. In some example embodiments, the means for transmitting the first response comprises means for transmitting, via the Network Exposure Function, the first response to the application.

[00175] In some example embodiments, the means for verifying validity of the first request comprises: means for extracting, from the first request, a first identifier of the application and a second identifier of the terminal device; means for determining, based on the first identifier, whether the application has been registered to the authorization server; means for determining, based on the second identifier and device registration information obtained from a Unified Data Repository, whether the terminal device has been registered to the Unified Data Repository; means for in response to determining that the application has been registered to the authorization server and the terminal device has been registered to the Unified Data Repository, determining the first request as valid; and means for in response to determining that the application has not been registered to the authorization server or the terminal device has not been registered to the Unified Data Repository, determining the first request as invalid.

[00176] In some example embodiments, the apparatus capable of performing the method 600 further comprises: means for receiving, from the terminal device, a third request for verifying the first access token; and means for transmitting, to the terminal device, a third response to the third request, the third response comprising the information about the first access token.

[00177] In some example embodiments, the means for receiving the third request comprises: means for receiving, via an Access and Mobility Management Function, the third request from the terminal device. In some example embodiments, the means for transmitting the third response comprises: means for transmitting, via the Access and Mobility Management Function, the third response to the terminal device.

[00178] In some example embodiments, an apparatus capable of performing the method 700 may comprise means for performing the respective steps of the method 700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00179] In some example embodiments, the apparatus capable of performing the method 700 (for example, the terminal device 120) comprises: means for receiving, at a terminal device and from an application, a second request for accessing the terminal device, the second request comprising a first access token for accessing the terminal device; means for verifying validity of the first access token; and means for transmitting, to the application, a second response to the second request based on a result of the verification.

[00180] In some example embodiments, the means for verifying validity of the first access token comprises: means for transmitting, to an authorizations server generating the first access token, a third request for verifying the first access token; means for receiving, from the authorization server, a third response to the third request; and means for verifying validity of the first access token based on the third response.

[00181] In some example embodiments, the means for transmitting the third request comprises: means for incorporating the third request into a service request to be transmitted to an Access and Mobility Management Function; and means for transmitting, via Radio Access Network, the service request to the Access and Mobility Management Function, such that the Access and Mobility Management Function forwards the third request to the authorization server. In some example embodiments, the means for receiving the third response comprises: means for in response to the Access and Mobility Management Function receiving the third response from the authorization server, receiving, via the Radio Access Network and from the Access and Mobility Management Function, a service accept message comprising the third response.

[00182] In some example embodiments, the means for verifying validity of the first access token based on the third response: means for extracting, from the second request, first information about the first access token; means for extracting, from the third response, second information about the first access token; means for in response to the first information matching the second information, determining the first access token as valid; and means for in response to the first information not matching the second information, determining the first access token as invalid.

[00183] In some example embodiments, the means for transmitting the second response comprises: means for in response to the first access token being valid, transmitting the second response for enabling the application to access the terminal device; and means for in response to the first access token being invalid, transmitting the second response for disabling the application to access the terminal device.

[00184] In some example embodiments, an apparatus capable of performing the method 800 may comprise means for performing the respective steps of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00185] In some example embodiments, the apparatus capable of performing the method 800 (for example, the terminal device 120) comprises: means for transmitting, from a terminal device to an authorization server, a fourth request for a second access token to be used by the terminal device to access an application; means for in response to the fourth request being determined as valid by the authorization server, receiving a fourth response to the fourth request from the authorization server, the fourth response comprising the second access token and information about the second access token; means for transmitting, based on the information and to the application, a fifth request for accessing the application, the fifth request comprising the second access token; and means for receiving a fifth response to the fifth request from the application.

[00186] In some example embodiments, the means for transmitting the fourth request comprises: means for incorporating the fourth request into a registration request to be transmitted to an Access and Mobility Management Function; and means for transmitting the registration request to the Access and Mobility Management Function, such that the Access and Mobility Management Function registers the terminal device to a Unified Data Repository and forwards the fourth request to the authorization server.

[00187] In some example embodiments, the means for receiving the fourth response comprises: means for in response to the Access and Mobility Management Function receiving the fourth response from the authorization server, receiving a registration response to the registration request from the Access and Mobility Management Function, the registration response comprising the fourth response.

[00188] In some example embodiments, the means for transmitting the fourth request comprises: means for incorporating the fourth request into a session establishment request to be transmitted to an Access and Mobility Management Function; and means for transmitting the session establishment request to the Access and Mobility Management Function, such that the Access and Mobility Management Function forwards the fourth request to the authorization server via a Session Management Function. In some example embodiments, the means for receiving the fourth response comprises: means for in response to the Access and Mobility Management Function receiving the fourth response from the authorization server via the Session Management Function, receiving a session establishment response to the session establishment request from the Access and Mobility Management Function, the session establishment response comprising the fourth response.

[00189] In some example embodiments, an apparatus capable of performing the method 900 may comprise means for performing the respective steps of the method 900. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00190] In some example embodiments, the apparatus capable of performing the method 900 (for example, the authorization server 130) comprises: means for receiving, at an authorization server and from a terminal device, a fourth request for a second access token to be used by the terminal device to access an application; means for verifying validity of the fourth request; means for in response to the fourth request being valid, generating the second access token and information about the second access token; and means for transmitting, to the terminal device, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.

[00191] In some example embodiments, the means for receiving the fourth request comprises: means for receiving, via an Access and Mobility Management Function, the fourth request from the terminal device. In some example embodiments, the means for transmitting the fourth response comprises: means for transmitting, via the Access and Mobility Management Function, the fourth response to the terminal device.

[00192] In some example embodiments, the means for receiving the fourth request comprises: means for receiving, via a Session Management Function, the fourth request from the terminal device. In some example embodiments, the means for transmitting the fourth response comprises: means for transmitting, via the Session Management Function, the fourth response to the terminal device.

[00193] In some embodiments, the means for verifying validity of the fourth request comprises: means for extracting, from the fourth request, a first identifier of the application and a second identifier of the terminal device; means for determining, based on the first identifier and application registration information obtained from a Network Exposure Function, whether the application has been registered to the Network Exposure Function; means for determining, based on the second identifier and device registration information obtained from a Unified Data Repository, whether the terminal device has been registered to the Unified Data Repository; means for in response to determining that the application has been registered to the Network Exposure Function and the terminal device has been registered to the Unified Data Repository, determining the fourth request as valid; and means for in response to determining that the application has not been registered to the Network Exposure Function or the terminal device has not been registered to the Unified Data Repository, determining the fourth request as invalid.

[00194] In some example embodiments, the apparatus capable of performing the method 900 further comprises: means for receiving, from the application, a sixth request for verifying the second access token; and means for transmitting, to the application, a sixth response to the sixth request, the sixth response comprising the information about the second access token.

[00195] In some example embodiments, the means for receiving the sixth request comprises: means for receiving, via a Network Exposure Function, the third request from the application. In some example embodiments, the means for transmitting the sixth response comprises: means for transmitting, via the Network Exposure Function, the sixth response to the application.

[00196] In some example embodiments, an apparatus capable of performing the method 1000 may comprise means for performing the respective steps of the method 1000. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00197] In some example embodiments, the apparatus capable of performing the method 1000 (for example, for example, an apparatus for running the application 110) comprises: means for receiving, at an application and from a terminal device, a fifth request for accessing the application, the fifth request comprising a second access token for accessing the application; means for verifying validity of the second access token; and means for transmitting, to the terminal device, a fifth response to the fifth request based on a result of the verification.

[00198] In some example embodiments, the means for verifying validity of the second access token comprises: means for transmitting, to an authorizations server generating the second access token, a sixth request for verifying the second access token; means for receiving, from the authorization server, a sixth response to the sixth request; and means for verifying validity of the second access token based on the sixth response.

[00199] In some example embodiments, the means for transmitting the sixth request comprises: means for transmitting, via a Network Exposure Function, the sixth request to the authorization server. In some example embodiments, the means for receiving the sixth response comprises: means for receiving, via the Network Exposure Function, the sixth response from the authorization server.

[00200] In some example embodiments, the means for verifying validity of the second access token based on the sixth response comprises: means for extracting, from the fifth request, third information about the second access token; means for extracting, from the sixth response, fourth information about the second access token; means for in response to the third information matching the fourth information, determining the second access token as valid; and means for in response to the third information not matching the fourth information, determining the second access token as invalid.

[00201] In some example embodiments, the means for transmitting the fifth response comprises: means for in response to the second access token being valid, transmitting the fifth response for enabling the terminal device to access the application; and means for in response to the second access token being invalid, transmitting the fifth response for disabling the terminal device to access the application.

[00202] Fig. 11 is a simplified block diagram of a device 1100 that is suitable for implementing embodiments of the present disclosure. For example, the terminal device 120 and/or the authorization server 130 as shown in Fig. 1 can be implemented by the device 1100. For example, the application 110 as shown in Fig. 1 can be implemented at the device 1100. As shown, the device 1100 includes one or more processors 1110, one or more memories 1120 coupled to the processor 1110, and one or more communication modules 1140 coupled to the processor 1110.

[00203] The communication module 1140 is for bidirectional communications. The communication module 1140 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements. [00204] The processor 1110 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non- limiting examples. The device 1100 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[00205] The memory 1120 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1124, an electrically programmable read only memory (EPROM), a flash memory, a hard disk, a compact disc (CD), a digital video disk (DVD), and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 1122 and other volatile memories that will not last in the power-down duration.

[00206] A computer program 1130 includes computer executable instructions that are executed by the associated processor 1110. The program 1130 may be stored in the ROM 1124. The processor 1110 may perform any suitable actions and processing by loading the program 1130 into the RAM 1122.

[00207] The embodiments of the present disclosure may be implemented by means of the program 1130 so that the device 1100 may perform any process of the disclosure as discussed with reference to Figs. 5-10. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[00208] In some example embodiments, the program 1130 may be tangibly contained in a computer readable medium which may be included in the device 1100 (such as in the memory 1120) or other storage devices that are accessible by the device 1100. The device 1100 may load the program 1130 from the computer readable medium to the RAM 1122 for execution. The computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. Fig. 12 shows an example of the computer readable medium 1200 in form of CD or DVD. The computer readable medium has the program 1130 stored thereon.

[00209] It should be appreciated that future networks may utilize network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into “building blocks” or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications, this may mean node operations to be carried out, at least partly, in a central/centralized unit, CU, (e.g. server, host or node) operationally coupled to distributed unit, DU, (e.g. a radio head/node). It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of labour between core network operations and base station operations may vary depending on implementation.

[00210] In an embodiment, the server may generate a virtual network through which the server communicates with the distributed unit. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Such virtual network may provide flexible distribution of operations between the server and the radio head/node. In practice, any digital signal processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation.

[00211] Therefore, in an embodiment, a CU-DU architecture is implemented. In such case the apparatus 1100 may be comprised in a central unit (e.g. a control unit, an edge cloud server, a server) operatively coupled (e.g. via a wireless or wired network) to a distributed unit (e.g. a remote radio head/node). That is, the central unit (e.g. an edge cloud server) and the distributed unit may be stand-alone apparatuses communicating with each other via a radio path or via a wired connection. Alternatively, they may be in a same entity communicating via a wired connection, etc. The edge cloud or edge cloud server may serve a plurality of distributed units or a radio access networks. In an embodiment, at least some of the described processes may be performed by the central unit. In another embodiment, the apparatus 1100 may be instead comprised in the distributed unit, and at least some of the described processes may be performed by the distributed unit.

[00212] In an embodiment, the execution of at least some of the functionalities of the apparatus 1100 may be shared between two physically separate devices (DU and CU) forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes. In an embodiment, such CU-DU architecture may provide flexible distribution of operations between the CU and the DU. In practice, any digital signal processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation. In an embodiment, the apparatus 1100 controls the execution of the processes, regardless of the location of the apparatus and regardless of where the processes/functions are carried out.

[00213] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments 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.

[00214] 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 methods 500, 600, 700, 800, 900 and/or 1000 as described above with reference to Figs. 5- 10. 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 embodiments. 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.

[00215] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[00216] In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[00217] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD- ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[00218] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[00219] Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.