Dynamic access token generation for visitor consumers within 5G networks

Abstract

The invention relates to dynamic access token generation for visitor consumers within 5G networks. Various embodiments of the present technology generally relate to systems and methods for providing an access token engine for dynamically generating access tokens for visiting consumers within a 5G network. In an example, an access token engine, which may be part of a first network, may receive a service request from a visitor consumer network function (NF), which is part of a second network. The access token engine may determine that the service request lacks an access token for receiving a service from the first network and retrieve an access token for a visitor consumer NF based on the service request. The access token engine may then generate an updated service request including the service request and the access token. The updated service request may be transmitted to a producer NF within the first network for providing the service request for the visitor consumer NF based on the access token.

Description

Technical Field

[0001] Various embodiments of this technology generally relate to network function communications within a 5G network. More specifically, embodiments of this technology relate to systems and methods for providing an access token engine for dynamically generating access tokens for visiting consumers within a 5G network. Background Technology

[0002] Roaming within 5G networks enables seamless connectivity for client devices as they move from their home network to a visitor network, ensuring uninterrupted access to mobile services. This advanced capability allows users to maintain high-speed data transmission, low latency, and reliable network performance even when client devices move across different geographic areas or network boundaries. By fully leveraging enhanced technologies and protocols, 5G roaming supports a wide range of applications, from everyday smartphone use to critical IoT deployments, delivering a consistent and superior user experience wherever you are.

[0003] When a client device visits a new network, it often requires an access token (such as an Open Authorization (OAuth) token) to authenticate and receive services. This token acts as a security credential verifying the user's identity and authorization within the new network. The visiting network (e.g., the home network of a roaming device) typically issues the token, which the new network verifies before granting access to its services. This process ensures that only authorized devices can connect to and use network resources, thus maintaining security and privacy. By using standardized tokens, 5G networks can efficiently manage user authentication and authorization across different network operators, thereby facilitating a seamless and secure roaming experience.

[0004] In some cases, service requests from visiting client devices may not include the required access token due to various network processes, network outages, or user authentication issues. Without this token, the new network cannot verify the device's identity and authorization, leading to a denial of service. While security protocols are crucial for preventing unauthorized access and potential security threats, this stringent approach can also have negative consequences. Denying service to legitimate users can result in poor user experience, frustration, and reduced satisfaction. It can also hinder the adoption and perceived reliability of 5G roaming services.

[0005] Accordingly, there is a need for improved systems and technologies for generating dynamic access tokens for roaming client devices. Specifically, there is a need for an access token engine that can request access tokens on behalf of the visiting client device within the visited network. As will be described in more detail below, the access token engine described herein strikes a balance between security measures and user accessibility to ensure seamless and satisfactory service delivery while maintaining network integrity.

[0006] The information provided in this section is presented as background information and is intended only to aid in understanding this disclosure. No determination or assertion has been made regarding whether any of the foregoing items can be considered prior art applicable to this disclosure. Summary of the Invention

[0007] This document discloses techniques and systems for providing an access token engine that dynamically determines an access token for a visitor network in a 5G environment that lacks the token necessary to request service. As will be described in more detail below, the access token engine may be part of, or operationally communicate with, the Security Edge Protection Agent (SEPP) of the home network. Therefore, when a service request is received from a visitor network (such as from a Visitor Consumer Network Function (NF) within the visitor network), the access token engine can determine that the service request lacks an access token required to receive service from the home network.

[0008] In response to determining that a service request lacks an access token for receiving services within the home network, the access token engine can determine an access token for the visitor consumer NF. As will be described in more detail below, this may include retrieving an access token for the visitor consumer NF from another NF within the home network (such as a Network Functions Storehouse (NRF)) based on attributes of the service request. In other cases, the access token engine can determine a currently generated access token for the visitor consumer NF based on attributes of the service request.

[0009] Once an access token is determined for the visitor / consumer NF, the access token engine can generate an updated request that includes the service request and the access token. The access token engine can then provide the updated request to the producer NF within the home network to provide the service. Upon receiving the updated request, the producer NF can verify the updated request and provide the requested service.

[0010] This summary is provided to introduce selected concepts in a simplified form, which will be further described in the detailed embodiments below. It is understood that this summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate one or more specific aspects and, together with the description of examples, serve to explain the principles and implementation methods of particular examples.

[0012] Figure 1 The illustration shows an example operating environment for a 5G network according to embodiments of this document, wherein one or more features of the access token engine can be implemented;

[0013] Figure 2 The illustration shows an example operation flow of a visitor network requesting services from a home network according to embodiments of this document;

[0014] Figure 3 The figure illustrates an operating environment 300 according to an embodiment of this document, wherein an access token engine provides access tokens to a visitor network;

[0015] Figure 4 Example access token engine processing according to the embodiments herein is provided;

[0016] Figure 5 The illustration shows an example operation flow for providing an access token engine according to embodiments of this document;

[0017] Figure 6 The illustration shows another example operation flow for providing an access token engine according to embodiments of this document; and

[0018] Figure 7 An example computing device suitable for providing an access token engine and related functionalities according to embodiments herein is shown.

[0019] For the purpose of discussing some embodiments of this technology, some components or operations may be divided into different blocks or combined into a single block. Furthermore, while this technology can be modified in various ways and alternatives, specific embodiments have been shown by way of example in the accompanying drawings and are described in detail below. However, it is not intended to limit the technology to the specific embodiments described. Rather, this technology is intended to cover all modifications, equivalents, and alternatives falling within the scope of the technology defined by the appended claims. Detailed Implementation

[0020] 5G networks are rapidly becoming ubiquitous and indispensable in modern society. With its ultra-high speed, low latency, and massive connectivity, 5G technology is transforming the way we communicate, work, and live. From streaming high-definition content on mobile devices to autonomous vehicles and smart cities, the potential applications of 5G are virtually limitless. Businesses are leveraging 5G networks to enable remote work, enhance productivity, and drive innovation across industries. Furthermore, the proliferation of Internet of Things (IoT) devices, coupled with 5G's ability to support massive numbers of connected devices, is driving the development of smart homes, healthcare systems, and industrial automation. As 5G networks continue to expand and evolve, people are increasingly relying on them to deliver seamless connectivity and enable the next wave of technological advancements, profoundly shaping the future of society.

[0021] Roaming (the ability for client devices to move between networks without affecting service) is an increasingly important feature of 5G. This seamless connectivity ensures users experience consistent high-speed data, low latency, and uninterrupted service, wherever they are. 5G's advanced infrastructure supports advanced roaming capabilities, allowing devices to transition smoothly between different network operators and regions. This is particularly beneficial for international travelers, remote workers, and IoT applications that require continuous connectivity. Enhanced roaming capabilities also enable innovative services such as real-time language translation and global telemedicine, further highlighting the importance of ubiquitous and reliable network access in our interconnected world.

[0022] To maintain secure and seamless connectivity between visiting client devices and new visited networks, access tokens, such as Open Authorization (OAuth) tokens, can be used. Access tokens serve as digital credentials for authentication and authorization when client devices move between different networks. Issued by the visiting network and verified by the new network visited by the roaming device, access tokens confirm the device's identity and authorization. In other words, access tokens enable visiting devices to maintain consistent access to services and resources without compromising security. By fully leveraging standardized access tokens, 5G networks can efficiently manage authentication and authorization across various network operators, thereby promoting a smooth and secure roaming experience for users worldwide.

[0023] While access tokens like OAuth are commonly used to manage authentication and authorization in 5G roaming, some networks may not use them, opting instead for different processes or protocols. These alternatives can include SIM card-based authentication, agreements between network operators, or proprietary security measures tailored to specific network infrastructures. Networks may choose these alternatives due to legacy systems, regional regulations, or unique operational needs. However, this diversity of authentication methods can lead to compatibility issues, complicating roaming processes for users. In particular, these different methods can cause visiting client devices to request services without the access token required by the network being visited.

[0024] Several negative consequences can arise when a visiting client device requests services from a network without the required access token. The network's inability to authenticate the device can lead to a denial-of-service condition, preventing the user from connecting and accessing necessary resources. This disruption can cause frustration and reduced user satisfaction, especially when the device is in an emergency or requires immediate access. Furthermore, a lack of proper authorization can compromise network security, potentially exposing vulnerabilities or leading to unauthorized access attempts. These issues not only affect individual users but also the overall reputation and reliability of the network, highlighting the importance of robust and consistent authentication mechanisms for maintaining a smooth roaming experience.

[0025] To at least address these issues, this paper provides a sample access token engine and its related functionality. As described in more detail below, the access token engine can operate on behalf of visiting client devices within the home network to provide access tokens for visiting service requests. The network on which the access token engine retrieves access tokens on behalf of the visiting client device may be referred to herein as the home network, while the network on which the visiting client device initially registered and authenticated may be referred to as the visitor network.

[0026] When a visiting client device travels into the home network and requests a service, the home network can receive the service request from the visiting network. For example, a Visitor Consumer Network Function (NF) within the visiting network can transmit the service request to the Security Edge Protection Agent (SEPP) within the home network, sometimes via the SEPP within the visiting network. The SEPP and / or access control engine can determine that the security request lacks the access token required by the home network to service the request. In some cases, the access token engine may be hosted and executed as part of the SEPP, while in others, it may be hosted as part of another network function within the home network or otherwise executed.

[0027] In response to determining that a service request lacks the necessary access token to receive the service within its home network, the access token engine can determine an access token on behalf of the visitor network (e.g., on behalf of the visitor consumer NF). As will be described in more detail below, the access token engine can generate an access token request for the visitor network based on the service request. For example, the access token engine can generate a unique identifier for the visitor consumer NF based on attributes of the service request. These attributes may include nfinstanceID, nftype, targetnftype, the scope of the request, the requester PLMN, etc., and can be used to generate the access token request.

[0028] Once generated, the access token engine can transmit the access token request to a network function (such as a Network Function Storehouse (NRF)) within the home network to retrieve the corresponding access token. In response to receiving the access token request, the NRF can generate or otherwise provide the requested access token to the access token engine. The access token engine can then generate an updated service request including the access token and provide it to the appropriate producer NF within the home network. Since the updated service request includes the required access token, the producer NF can verify the access token and provide the service request. Therefore, the producer NF can generate and send a success response to the visiting network, which may include the requested service.

[0029] By providing access tokens and verifying service requests from visiting client devices, the access token engine presented in this paper offers several significant benefits compared to existing methods. First, regardless of whether the client includes the necessary access token, the access token engine enhances the user experience by enabling seamless connectivity when clients move across geographical regions or network boundaries, thereby ensuring uninterrupted service and consistent performance. By generating a unique identifier based on the service request, the access token engine allows the home network to perform authentication processing, thus maintaining security at the edge of the home network. Furthermore, the access token engine optimizes network performance and reduces congestion by allowing operators to dynamically manage and balance traffic loads to support efficient network resource utilization. In summary, by enabling the home network to authenticate and allow roaming access across 5G networks (with or without access tokens), the access token engine contributes to a more flexible, secure, and user-centric mobile communications ecosystem.

[0030] Now turn to the attached image. Figure 1 The illustration depicts an example operating environment for a 5G network 100 according to embodiments of this document, wherein one or more features of the access token engine can be implemented. The example 5G network 100 is a 5G core (5GC) cellular network implementing the 3GPP (3rd Generation Partnership Project) communication standard, but this disclosure can be applied to other communication networks.

[0031] The 5G network 100, its components, and sub-components can be implemented via computers, servers, hardware and software modules, or other system components. The components and sub-components of the 5G network 100, or the physical devices implementing them, can be co-located, remotely distributed, or any combination thereof. Elements of the 5G network 100 may include components hosted in or located in the cloud and implemented as software modules that may be distributed across one or more server devices or other physical components.

[0032] The 5G network 100 is divided into two basic planes: the control plane 101 and the user plane 102, each with its own unique but interdependent role. The control plane 101 manages the signaling and control information necessary to establish, modify, and terminate communication sessions. It handles tasks such as authentication, policy enforcement, and mobility management. Therefore, the control plane 101 is crucial for orchestrating and controlling network layers (NFs) to ensure efficient and secure connections. On the other hand, the user plane 102 handles the actual data transmission—the movement of user data between devices and applications. It is optimized for high-throughput, low-latency data delivery and designed to efficiently transport user traffic. The separation of the control plane 101 and user plane 102 in the 5G network 100 enhances scalability, flexibility, and enables network slicing, allowing for customized configurations to meet diverse service requirements. Together, these planes 101 and 102 form a cohesive architecture that enables the 5G network 100 to deliver unprecedented speed, reliability, and versatility for a wide range of applications and services.

[0033] As described above, the user plane 102 of the 5G network 100 works in conjunction with the control plane 101 to deliver efficient and seamless data transmission. For example, as shown, when a user equipment (UE) 104 (which may be a smartphone or any other device) initiates communication, the user plane 102 handles the actual user data traffic. When the UE 104 initiates communication, the radio access network (RAN) 106 comes into play, managing the radio connection between the UE 104 and the network 100, particularly the radio connection between the UE 104 and the Access and Mobility Management Function (AMF) 112. The RAN 106 acts as a bridge between the user plane 102 and the control plane 101, facilitating the establishment of communication sessions. As data travels through the RAN 106, it encounters the User Data Function (UDF) 108, which plays a crucial role in processing and optimizing user data. The UDF 108 is responsible for tasks such as traffic optimization, content caching, and data transformation, thereby enhancing the efficiency of data delivery.

[0034] UDF 108 provides data to data network (DN) 110, which may represent the broader Internet or a specific network service. DN 110 processes user data and delivers it to its intended destination, thus completing the journey initiated by UE 104. The coordinated operation of user plane 102, UE 104, RAN 106, UDF 108, and DN 110 ensures reliable and efficient data transmission, meeting the high-performance expectations of 5G networks. As will be readily recognized by those skilled in the art, the separation of user plane 102 from control plane 101 allows for flexible network configuration and optimization, thereby contributing to the enhanced capabilities of the 5G ecosystem.

[0035] As described above, when UE 104 initiates communication within the 5G network 100, the AMF 112 coordinates the interaction. For example, when UE 104 initiates communication or mobility within the 5G network 100, it sends signaling messages to the AMF 112. The AMF 112 is responsible for tasks such as authentication, authorization, and mobility management. Upon receiving a signaling message from UE 104, the AMF 112 verifies the user's identity, checks necessary permissions, and establishes the necessary context for the session. The AMF 112 coordinates with other network functions, such as the Session Management Function (SMF) 114 and the User Plane Function (UPF) 116, to ensure seamless setup and management of communication sessions. Interaction with the control plane 101 enables UE 104 to access network services, adhere to established policies, and maintain continuous connectivity, while benefiting from the advanced capabilities and optimizations offered by the 5G network architecture.

[0036] Control plane 101 includes example components, nodes, or NFs. As shown, control plane 101 includes AMF 112, SMF 114, UPF 116, Authentication Server Function (AUSF) 118, Authentication and Authorization Function (AAF) 120, Service Communication Proxy (SCP) 122, Network Slice Selection Function (NSSF) 124, Network Exposure Function (NEF) 126, Network Repository Function or NF Repository Function (NRF) 128, Packet Core Function (PCF) 130, Unified Data Management (UDM) 132, Application Function (AF) 134, and Security Edge Protection Proxy (SEPP) 136. The selection of NFs 112-136 depicted in the 5G network 100 is exemplary, and some of NFs 112-136 may be excluded or other NFs may be added to the set without departing from the scope of this disclosure. Various NFs 112-136 perform various operations to provide communication services to UEs (such as UE 104) connected to the 5G network 100. The network node or NF providing the service is referred to herein as an NF producer, while the network node or NF consuming the service is referred to herein as an NF consumer. A network function can be either an NF producer or an NF consumer, depending on whether it is consuming or providing a service.

[0037] NFs 112-136 of the 5G network 100 exchange various communications during the provision of network services. These communications can include messaging for establishing or terminating secure communication channels, such as Transport Layer Security (TLS) handshakes, and Service-Based Interface (SBI) communications. As used herein, SBI is the term given to Application Programming Interface (API) based communications that can occur between two NFs within a 5G SBA. A given NF can invoke a specific service or service operation using API calls on the SBI. Communication between NFs 112-136 can be performed through the network links and communication channels of the 5G network 100. Figure 1 It is not explicitly described in the text.

[0038] When UE 104 initiates communication within the 5G network 100, various network functions often operate in pairs. One NF acts as a producer (“NF producer”), generating or providing specific services or information, while the other NF acts as a consumer (“NF consumer”), utilizing or consuming the generated services or information to fulfill service requests. For example, consider the interaction between SMF 114 and Packet Core Function (PCF) 130. As an NF consumer, SMF 114 initiates service requests related to session establishment, modification, or termination with a UE session (such as for UE 104). SMF 114 relays these requests to PCF 130, which acts as an NF producer, performing functions related to session management, Quality of Service (QoS) enforcement, and access control. PCF 130 processes requests from SMF 114, enforces QoS policies, manages session establishment and modification, and ensures appropriate access control based on network policies and conditions. Through this producer-consumer interaction, SMF 114 and PCF 130 work together to deliver efficient and reliable services within the 5G network architecture.

[0039] As will be readily recognized by those skilled in the art, various NFs can act as NF producers and NF consumers. For example, an NF producer may be or may include a PCF 130, SMF 114, Unified Data Repository (UDR) (not shown), Charging Function (CHF), Bonding Support Function (BSF) (not shown), or Network Data Analysis Function (NWDAF) (not shown), depending on the operation and service request. An NF consumer may be or may include a UE 104, Service Capability Function (SCF) (not shown), SCP 122, SMF 114, AMF 112, NEF 126, Security Edge Protection Agent (SEPP) 136, AF 134, UDR, or Charging Function (CHF), depending on the operation and service request.

[0040] As described above, the 5G network 100 includes SEPP 136. SEPP 136 plays a crucial role in enhancing the security framework of the 5G network 100. For example, SEPP 136 can act as a gateway between the 5G core network 100 and external networks (such as visitor networks or service providers), thereby ensuring that all data exchanges are secure and compliant with the latest security protocols. It prevents unauthorized access and potential threats by encrypting and decrypting signaling messages, thus guaranteeing the integrity and confidentiality of communications. By monitoring and filtering traffic at the network edge, SEPP 136 also helps detect and mitigate various network threats, thereby ensuring robust protection for the expansion and dynamic infrastructure of the 5G network 100.

[0041] SEPP 136 also plays an integral role in the security architecture of 5G Network 100 by interacting with other network functions to verify access tokens (such as OAuth tokens) used for roaming or visiting devices. When a visiting device roams to a new network (such as 5G Network 100), SEPP 136 forwards the service request to AAF 120 or a similar network function responsible for token verification. AAF 120 verifies the legitimacy and validity of the token, checking factors such as expiration and access scope. Once the token is authenticated, AAF 120 sends the result back to SEPP 136, which then ensures that only authorized devices can access the services of 5G Network 100. This collaborative processing helps maintain stringent security standards and enables secure, seamless connectivity for roaming devices within 5G Network 100.

[0042] Now for reference Figure 2 According to embodiments herein, an example operation flow 200 is illustrated for a visitor network 205A requesting services from a home network 205B. Specifically, operation flow 200 illustrates a visitor network 205A, which includes a visitor consumer NF 238 and a visitor SEPP (vSEPP) 236V. The consumer NF can be or can include any component described with respect to the 5G network 100. For example, the visitor consumer NF 238 can be an AMF (such as AMF 112), an SMF (such as SMF 114), etc.

[0043] In the example shown, a client device associated with visitor network 205A can roam into home network 205B. Therefore, visitor network 205A can initiate service request 242 on behalf of the roaming device. For example, visitor consumer NF 238 can provide service request 242 to vSEPP 236B, which can then transmit service request 242 to home SEPP (hSEPP) 236H. Upon receiving service request 242, hSEPP 236H can pass service request 242 to producer NF 240 within home network 205B. Producer NF 240 (which can be an AAF, such as AAF 120) can check whether an access token (such as an OAuth token) is present in service request 242. Here, producer NF 240 can determine 244 that service request 242 lacks the access token necessary to receive service from home network 205B. Therefore, producer NF 240 can generate 246 an error response 248. Error response 248 can reject service request 242. Once generated, home network 205B can transmit error response 248 to visitor network 205A.

[0044] When a device roams into home network 205B, a service request 242 from visitor network 205A may not include an access token for various reasons, such as different protocols or processes. For example, visitor network 205A may follow a unique authentication framework or security standard that does not involve access tokens, or it may use alternative methods to manage user credentials and access permissions. Therefore, when a visitor device from visitor network 205A attempts to access services in home network 205B, it may be unable to present an access token, which is essential for authentication and authorization processing by home network 205B. This inconsistency in protocols may result in the visitor device being denied service by home network 205B, negatively impacting the client experience.

[0045] To address situations where visitor devices lack access tokens within their home network (such as Home Network 205B), this article provides a sample access token engine. Refer to [link / reference] now. Figure 3 The figure illustrates an operating environment 300 in which an access token engine 350 provides access tokens to a visitor network according to an embodiment of this document. As shown, the access token engine 350 can communicate operationally with visitor consumer NF 338 (which may be the same as or similar to visitor consumer NF 238) and home producer NF 340 (which may be the same as or similar to home producer NF 240).

[0046] For ease of explanation, combined with Figure 4 To describe Figure 3 , Figure 4Example access token engine processing according to embodiments herein is provided, particularly processing 400 for providing access token engine 350 and one or more of its functionalities. In other words, Figure 4 The illustration shows a process 400 for dynamically determining an access token for a visitor consumer NF according to an embodiment of this document. Although Figure 4 It is relative to Figure 3 The description is provided, but it should be recognized that the components, elements, and steps in any other figures described herein are equally applicable.

[0047] like Figure 3 As shown, access token engine 350 can receive service request 342 (470) from visitor consumer NF 338. In some embodiments, access token engine 350 may be part of or operationally communicate with hSEPP 236H within the home network, such as hSEPP 236H within the home network 205B. Therefore, when hSEPP receives service request 342, the service request 342 may also be routed to access token engine 350. In response to receiving service request 342, access token engine 350 may determine whether service request 342 includes an access token necessary to receive service from the home network.

[0048] Access tokens typically include information about the requesting NF (e.g., visitor-consumer NF 338) or visitor network to ensure secure and authorized access within the home network. Therefore, access tokens often include the identity of the requesting entity, such as its unique identifier or network address, and details about its role or permissions within the network. In some embodiments, the access token may be an Open Authorization (OAuth) token, which includes the visitor device's identity, the scope of access, and the token's validity period. By embedding this contextual information within the access token, the home network can effectively authenticate and authorize requests, ensuring that only authorized NFs or visitor networks can access specific resources or services. As those skilled in the art will readily recognize, access tokens allow the home network to maintain robust security and control interactions with visitor networks, thereby facilitating seamless and secure communication across different components and domains.

[0049] In the example shown, access token engine 350 can determine that service request 342 lacks an access token (472) required to receive the requested service within the home network. For example, access token engine 350 may include access token module 352 that determines whether service request 342 includes a valid access token or does not include any access token at all. That is, in some embodiments, service request 342 may not include any access token, while in other embodiments, service request 342 may include a current access token 354 that is no longer valid. As will be described in more detail below, access token module 352 can identify the current access token 354 (474) for visitor consumer NF 338 and, based on the current access token 354, determine that the expiration time 356 (476) associated with the current access token 354 has expired. Therefore, the current access token 354 may no longer be valid.

[0050] Once the access token engine 350 determines that the service request 342 lacks the access token required to receive service from the home network, the access token engine 350 can determine the access token (478) for the visiting consumer NF 338 based on the service request 342. That is, the access token engine 350 can generate or retrieve an appropriate access token for the visiting consumer NF 338 so that the home network can provide service to the service request 342. To determine the access token for the visiting consumer NF 338, the access token engine 350 may include an access token request generator 362. The access token request generator 362 can generate an access token request 360 (480) based on the service request 342. Specifically, the access token request generator 362 can parse the service request 342 to generate a unique identifier for the visiting consumer NF 338 and / or various attributes required to receive the access token.

[0051] As mentioned above, access tokens typically include the identity of the requesting entity, such as its unique identifier or network address, and details about its role or permissions within its home network. However, since service request 342 is provided from the visitor network and does not include an access token, the identification, role, and permission information may not be provided as part of service request 342. Therefore, access token request generator 362 can parse service request 342 to generate a unique identifier for the visitor consumer NF338, as well as other attributes of service request 342 that can be used for access tokens. For example, access token request generator 362 can parse service request 342 to obtain the following attributes used to request an access token:

[0052] nfinstanceID: This property can be set to the nfinstance of visitor consumer NF 338, but if the nfinstance of visitor consumer NF 338 is not available, then this property can be set to the nfInstance of hSEPP;

[0053] nftype: This attribute can be inferred from service request 342, such as from the User-Agent header (if it exists in service request 342, then it will contain nftype);

[0054] targetnftype: This attribute can be inferred from service request 342;

[0055] Scope of service: This attribute can be inferred from service request 342; and / or

[0056] requesterPLMN: This attribute can be inferred from 3gpp-sbi-Originating-Network-id or from the vSEPP remote SEPP set.

[0057] Based on one or more of the attributes described above, the access token request generator 362 can generate a unique identifier for the visitor consumer NF 338, as well as any additional information required by the home network to obtain an access token (e.g., role, permission, scope of service). It should be recognized that the attributes described above are not a complete list of attributes that can be parsed from the service request 342. In some embodiments, other attributes parsed from the service request 342 (and in some cases, from the transport visitor network) may be used to generate the unique identifier and / or the information required for the access token for the visitor consumer NF 338.

[0058] Once the access token request generator 362 generates an access token request 360, the access token engine 350 can use the access token request 360 to retrieve an access token 364 (482) from the corresponding network function within the home network. For example, the access token engine 350 can provide the access token request 360 to the home NRF 328. The home NRF 328 may be the same as or similar to NRF 128 and is responsible for generating and / or distributing access tokens within the home network. As will be readily recognized by those skilled in the art, the home NRF 328 plays a crucial role in managing network functions and ensuring efficient communication and service delivery. One of the responsibilities of the home NRF 328 includes generating access tokens to facilitate secure interaction between network entities. When an access token is requested, the home NRF 328 generates a corresponding access token by combining basic information such as the identity of the requesting entity, the scope of access, and the expiration time 356 of the access token (e.g., the duration of the token's validity). In some cases, the token generation process may include cryptographic techniques to ensure the integrity and security of the access token.

[0059] Once generated by the corresponding NF (here, the Home NRF 328), the access token 364 can be provided back to hSEPP, specifically to the access token engine 350. Upon receiving the access token 364, the access token engine 350 can store the access token 364, along with the corresponding attributes and / or unique identifier generated for the visitor consumer NF 338, in the visitor access token table 358. For example, the access token module 352 can associate the identified attributes of the service request 342 (e.g., nftype, targetnftype, scope of service, nfinstance) with the access token 364 and store them in the visitor access token table 358.

[0060] The access token module 352 can also store the corresponding expiration time 356 of the access token 364 in association with the access token 364 in the visitor access token table 358. As described above, in some scenarios, the service request 342 may include the current access token 354 or its association. For example, based on the unique identifier and / or attributes present in the service request 342, the access token module 352 can perform a lookup in the visitor access token table 358 to determine whether the access token has been previously associated with the visitor consumer NF 338. If the access token module 352 determines that an access token has been previously generated and associated with the visitor consumer NF 338, then the access token module 352 can identify the current access token 354. Based on the expiration time 356 associated with the current access token 354, the access token module 352 can determine whether the current access token 354 is valid. If the expiration time 356 has expired, then the access token engine 350 can generate a subsequent access token request 360 to request a new valid access token 364 for the visitor consumer NF 338. However, if the current access token 354 is still valid (e.g., unsatisfied or expired 356), then the access token engine 350 can use the current access token 354 to request the services listed in the service request 342.

[0061] Once a valid access token is obtained (either an unexpired current access token 354 or an access token 364 retrieved from the home NRF 328), the access token engine 350 can generate an updated request 368 (484) for the services listed in service request 342. That is, the access token engine 350 may include an updated request generator 366 that generates the updated request 368. The updated request 368 may include service request 342 and access token 364 (or the current access token 354, if valid). Once generated, the access token engine 350 can provide the updated request 368 to the home producer NF 340 to provide service request 342 (486). If service request 342 is otherwise valid (e.g., contains appropriate content for the requested service), then the home producer NF 340 can service the request based on the valid access token. In some embodiments, the attributable producer NF 340 may be or may include a UDM (such as UDM 132), a PCF (such as PCF 130), a UDR, an AUSF (such as AUSF 118), etc.

[0062] Now for reference Figure 5The illustration depicts an example operation flow 500 for providing an access token engine 550 according to embodiments of this document. The access token engine 550 may be the same as or similar to access token engine 350, and thus can dynamically generate / retrieve access tokens for visiting devices lacking the token necessary to receive service within the requested network. As shown, the operation flow 500 is shown between a visitor network 505A and a home network 505B, which may be the same as or similar to visitor network 205A and home network 205B, respectively. Therefore, visitor network 505A may include visitor consumer NF 538 and visitor SEPP (vSEPP) 536V, which may be the same as or similar to visitor consumer NF 238 and vSEPP 236V, respectively.

[0063] Visitor consumer NF 538 can correspond to a client device requesting services within home network 505B. Therefore, consumer NF 538 can submit a service request 542 to home network 505B, such as via vSEPP 536V. vSEPP 536V can transmit service request 542 to hSEPP 536H of home network 505B. As shown, hSEPP 536H may include access token engine 550. Therefore, in response to receiving service request 542, access token engine 550 can determine that service request 542 lacks an access token (544) for the requested service. As described above, access token engine 550 can determine the lack of an access token by determining that a valid access token for visitor consumer NF 538 does not exist. For example, based on the attributes of service request 542, access token engine 550 can perform a lookup in the visitor access token table (such as table 358) and determine whether a previously generated access token exists, or, if a current access token exists for visitor consumer NF 538, determine that the current access token is invalid based on the token's expiration time.

[0064] Based on the lack of an access token for visitor consumer NF 538, access token engine 550 can generate an access token request (456), such as generating access token request 560. Access token request 560, which may be the same as or similar to access token request 360, can be transmitted to home NRF (hNRF) 528, which may be the same as or similar to home NRF 328. In response to receiving access token request 560, hNRF 528 can generate access token 564 (582). Along with access token 564, hNRF 528 can also generate a corresponding expiration time for access token 564. The expiration time can specify the duration for which access token 564 is valid. Once the expiration time is met or exceeded, access token 564 may no longer be valid and therefore may not be allowed to use services within home network 505B after the expiration time. As those skilled in the art will recognize, the expiration time can range from minutes, hours to even days, depending on the requested application and service.

[0065] Access token 564 can be provided back to hSEPP 536H and / or access token engine 550, which can then generate an updated request 568 (566) based on access token 564 and service request 542. The updated request 568, which may include both access token 564 and service request 542, can be provided to producer NF 540 within home network 505B, which may be the same as or similar to producer NF 240 and / or 340. Producer NF 540 can verify the updated request 568 (586) to generate a success response 588. The success response 588 may include notification that the service requested by service request 542 can be provided by home network 505B, and / or the success response 588 may include the requested service. As shown, the success response 588 can be provided to visitor consumer NF 538 via hSEPP 536H and vSEPP 536V.

[0066] Now for reference Figure 6The illustration shows another example operation flow 600 for providing an access token engine 650 according to embodiments of this document. The access token engine 650 may be the same as or similar to access token engines 350 and / or 550, and thus can dynamically generate / retrieve access tokens for visiting devices that lack the token necessary to receive service within the requested network. Similar to operation flow 500, a visitor consumer NF 538 may correspond to a client device requesting service within a home network 605B, which may be the same as or similar to home network 505B. Therefore, visitor consumer NF 638 may submit a service request 642 to home network 605B, such as via vSEPP 636V from visitor network 605A, which may be the same as or similar to visitor network 505A.

[0067] vSEPP 636V can transmit service request 642 to hSEPP 636H of the home network 605B, which may be the same as or similar to hSEPP 536H. As shown, hSEPP 636H may include or communicate with access token engine 650. Therefore, in response to receiving service request 642, access token engine 650 may determine whether a valid access token exists for visitor consumer NF 638. As shown, this determination may include performing a lookup (673) on a visitor access token table (such as table 357). For example, access token engine 650 may determine a unique identifier for visitor consumer NF 638 based on service request 642 (such as based on the attributes of service request 642) and use that unique identifier to search the visitor access token table. Based on the lookup, access token engine 650 may identify the current access token associated with visitor consumer NF 638 (674). In some cases, the access token engine 650 can also determine the validity of the current access token based on the expiration time associated with the current access token.

[0068] In response to recognizing the current access token, access token engine 650 can generate an updated request 668 (666). Once generated, access token engine 650 can transmit the updated request 668 to producer NF 640 via hSEPP 636H, which may be the same as or similar to producer NF 540. Similar to flow 500, in response to receiving the updated request 668, producer NF 640 can verify the updated request 568 (686), thereby generating a success response 688. Success response 688 may include notification that the service requested by service request 642 can be provided by home network 605B, and / or success response 688 may include the requested service. As shown, success response 688 can be provided to visitor consumer NF 638 via hSEPP 636H and vSEPP 636V.

[0069] For reference Figure 7 This figure is a diagram of a system 700 configured to implement an access token engine according to embodiments of this document. System 700 may be an example of a device including a computing device 791, which represents any system or collection of systems in which the various processes, systems, programs, services, and scenarios disclosed herein can be implemented. For example, computing device 791 may be an example access token engine (such as access token engine 350 / 550 / 650), a producer NF or consumer NF (such as any visitor consumer NF or attribution producer NF discussed herein), a SEPP (such as vSEPP and hSEPP discussed herein), or respectively in Figures 1-6 Any sub-component depicted in the 5G network 100, operation flow 200, 500, or 600, or operation environment 300. Examples of computing device 791 include, but are not limited to, server computers, desktop computers, laptop computers, routers, switches, web servers, cloud computing platforms, and data center equipment, as well as any other type of physical or virtual server machine, physical or virtual router, container, and any variations or combinations thereof.

[0070] The computing device 791 can be implemented as a single device, system, or apparatus, or it can be implemented as multiple devices, systems, or apparatuses in a distributed manner. The computing device 791 may include, but is not limited to, a processing system 796, a storage system 793, software 795, a communication interface system 797, and a user interface system 799. The processing system 796 can be operatively coupled to the storage system 793, the communication interface system 797, and the user interface system 799.

[0071] Processing system 796 can load and execute software 795 from storage system 793. Software 795 may include access token engine 792, which may represent any operation for providing access token engine or any related functionality thereof, as discussed with respect to the preceding figures. When executed by processing system 796, software 795 may instruct processing system 796 to operate as described herein for at least various processes, such as process 400 or any of the operation flows 500-600, operation scenarios, and sequences discussed in the foregoing embodiments. Computing device 791 may optionally include additional devices, features, or functionalities not discussed for brevity.

[0072] In some embodiments, processing system 796 may include a microprocessor and other circuitry for retrieving and executing software 795 from storage system 793. Processing system 796 may be implemented within a single processing device, but may also be distributed across multiple processing devices or subsystems that collaboratively execute program instructions. Examples of processing system 796 may include a general-purpose central processing unit, a graphics processing unit, a dedicated processor and logic devices, and any other type of processing device, combination of such devices, or variations thereof.

[0073] Storage system 793 may include any memory device or computer-readable storage medium that can be read by processing system 796 and is capable of storing software 795. Storage system 793 may include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Examples of storage media include random access memory, read-only memory, magnetic disks, optical disks, optical media, flash memory, virtual and non-virtual memory, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other suitable storage medium. In any case, computer-readable storage media are not for transmitting signals.

[0074] In addition to a computer-readable storage medium, in some embodiments, the storage system 793 may also include a computer-readable communication medium on which at least some of the software 795 can be transmitted internally or externally. The storage system 793 may be implemented as a single storage device, but may also be implemented across multiple storage devices or subsystems that are co-located or distributed relative to each other. The storage system 793 may include additional elements, such as a controller, capable of communicating with the processing system 796 or potentially other systems.

[0075] Software 795 (including access token engine 792 among other functions) can be implemented using program instructions that, when executed by processing system 796, can instruct processing system 796 to operate as described herein with respect to the various operating scenarios, sequences and processes.

[0076] Specifically, program instructions may include various components or modules that cooperate or otherwise interact to perform the various processing and operational scenarios described herein. These components or modules may be implemented in compiled or interpreted instructions, or in some other variation or combination of instructions. They may be executed synchronously or asynchronously, serially or in parallel, in a single-threaded or multi-threaded environment, or according to any other suitable execution paradigm, variation, or combination thereof. Software 795 may include additional processing, programs, or components, such as operating system software, virtualization software, or other application software. Software 795 may also include firmware or some other form of machine-readable processing instructions executable by processing system 796.

[0077] Generally, when loaded into and executed by the processing system 796, the software 795 can transform the appropriate apparatus, system, or device (represented by the computing device 791) from a general-purpose computing system to a special-purpose computing system as described herein. In practice, the coded software 795 on the storage system 793 can transform the physical structure of the storage system 793. The specific transformation of the physical structure can depend on various factors in the different embodiments described herein. Examples of these factors may include, but are not limited to, the technology of the storage medium used to implement the storage system 793 and whether the computer storage medium is characterized as a primary or secondary storage device, among other factors.

[0078] For example, if the computer-readable storage medium is implemented as a semiconductor-based memory, then the software 795 can transform the physical state of the semiconductor memory as program instructions are encoded therein, such as by transforming the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. Similar transformations can occur for magnetic or optical media. Other transformations of the physical medium are possible without departing from the scope of this specification; the foregoing examples are provided merely for the convenience of this discussion.

[0079] The communication interface system 797 may include communication connections and devices that allow communication with other computing systems (not shown) via a communication network (not shown). Examples of connections and devices that together allow inter-system communication may include network interface cards, antennas, power amplifiers, radio frequency (RF) circuitry systems, transceivers, and other communication circuitry systems. The connections and devices may communicate via a communication medium to exchange communication with other computing systems or networks of systems, such as metal, glass, air, or any other suitable communication medium.

[0080] Communication between computing device 791 and other computing systems (not shown) can occur on one or more communication networks and according to various communication protocols, combinations of protocols, or variations thereof. Examples include intranets, the Internet, local area networks, wide area networks, wireless networks, wired networks, virtual networks, software-defined networks, data center buses and backplanes, or any other type of network, combination of networks, or variations thereof. The communication networks and protocols mentioned above are well known and do not need to be discussed in detail here.

[0081] While some examples of the methods and systems described herein are based on software executed on various machines, these methods and systems can also be implemented as specially configured hardware, such as field-programmable gate arrays (FPGAs) specifically designed to perform the various methods according to this disclosure. For example, examples can be implemented in digital electronic circuit systems, or in computer hardware, firmware, software, or a combination thereof. In one example, the device may include one or more processors. The processor includes computer-readable media, such as random access memory (RAM) coupled to the processor. The processor executes computer-executable program instructions stored in the memory, such as executing one or more computer programs. Such processors may include microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and state machines. Such processors may also include programmable electronic devices, such as PLCs, programmable interrupt controllers (PICs), programmable logic devices (PLDs), programmable read-only memory (PROMs), electrically programmable read-only memory (EPROMs or EEPROMs), or other similar devices.

[0082] Such processors may include or be able to communicate with media, such as one or more non-transitory computer-readable media that may store processor-executable instructions, which, when executed by the processor, cause the processor to perform or assist in the methods according to this disclosure. Examples of non-transitory computer-readable media may include, but are not limited to, electronic, optical, magnetic, or other storage devices capable of providing processor-executable instructions to a processor (such as a processor in a web server). Other examples of non-transitory computer-readable media include, but are not limited to, floppy disks, CD-ROMs, magnetic disks, memory chips, ROMs, RAMs, ASICs, configured processors, all optical media, all magnetic tapes or other magnetic media, or any other media that a computer processor can read. The described processor and processing may reside in one or more structures and may be distributed across one or more structures. The processor may include code that performs (or portions thereof) the methods according to this disclosure.

[0083] As those skilled in the art will recognize, aspects of the invention can be implemented as systems, methods, computer program products, and other configurable systems. Thus, aspects of the invention can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which can generally be referred to herein as “circuit,” “module,” or “system.” Furthermore, aspects of the invention can take the form of computer program products embodied in one or more memory devices or (one or more) computer-readable media having computer-readable program code embodied thereon.

[0084] The foregoing examples and descriptions are described herein in the context of systems and methods for providing access token engines or one or more of their related functionalities. Those skilled in the art will recognize that these descriptions are merely illustrative and not intended to be limiting in any way. Refer in detail to the embodiments illustrated in the accompanying drawings. The same reference numerals are used throughout the drawings and description to refer to the same or similar items.

[0085] For clarity, not all conventional features of the examples described herein are shown or described. It will be appreciated that in the development of any such practical implementation, many implementation-specific decisions must be made to achieve the developer's specific goals (such as compliance with constraints related to the application and business), and these specific goals will vary from implementation to implementation and from developer to developer. That is, the presentation of the foregoing descriptions of some examples is for illustrative and descriptive purposes only and is not intended to be exhaustive or to limit this disclosure to the precise forms disclosed. Numerous modifications and adaptations to this disclosure will be apparent to those skilled in the art without departing from the spirit and scope of this disclosure.

[0086] References to examples or embodiments herein mean that a particular feature, structure, operation, or other characteristic described in connection with that example may be included in at least one embodiment of this disclosure. This disclosure is not limited to the particular examples or embodiments described as such. The phrases “in one example,” “in an example,” “in an embodiment,” or “in an embodiment,” or variations thereof, appearing throughout the specification, do not necessarily refer to the same example or embodiment. Any particular feature, structure, operation, or other characteristic described in this specification with respect to one example or embodiment may be combined with other features, structures, operations, or other characteristics described with respect to any other example or embodiment.

[0087] The use of the word "or" in this article is intended to cover both inclusive and exclusive OR conditions. In other words, A or B or C includes any or all of the following alternative combinations that are suitable for a particular purpose: A only; B only; C only; A and B only; A and C only; B and C only; and A and B and C.

[0088] Unless the context explicitly requires otherwise, throughout the specification and claims, the terms “comprising,” “including,” etc., shall be interpreted in an inclusive sense, not in an exclusive or exhaustive sense; that is, in the sense of “including but not limited to.” As used herein, the terms “connection,” “coupling,” or any variation thereof mean any direct or indirect connection or coupling between two or more elements; the coupling or connection between elements may be physical, logical, or a combination thereof. Furthermore, when used in this application, the terms “this article,” “above,” “below,” and similar terms refer to the entire application, and not any particular part of this application. Where the context permits, singular or plural terms used in the above specific embodiments may also include plural or singular, respectively. When referring to a list of two or more items, the word “or” covers all of the following interpretations: any item in the list, all items in the list, and any combination of items in the list.

[0089] The specific embodiments of this technology described above are not intended to be exhaustive or to limit the technology to the precise forms disclosed above. While specific examples of the technology have been described above for illustrative purposes, various equivalent modifications are possible within the scope of this technology, as will be recognized by those skilled in the art. For example, although processes or blocks are presented in a given order, alternative embodiments may perform routines with steps in a different order, or employ systems with blocks in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and / or modified to provide alternatives or sub-combinations. Each of these processes or blocks can be implemented in a variety of different ways. Moreover, although processes or blocks are sometimes shown to be executed serially, these processes or blocks may instead be executed or implemented in parallel, or may be executed at different times. Any other specific figures mentioned herein are merely examples: alternative embodiments may employ different values ​​or ranges.

[0090] The teachings of the techniques provided herein can be applied to other systems, not necessarily those described above. Elements and actions from the various examples described above can be combined to provide further implementations of the technique. Some alternative implementations of the technique may include not only additional elements of those implementations described above, but may also include fewer elements.

[0091] To reduce the number of claims, certain aspects of the technology are presented below in certain claim forms, but the applicant may consider all aspects of the technology in any number of claim forms. For example, while only one aspect of the technology may be recited as a computer-readable medium claim, other aspects may also be implemented as computer-readable medium claims, or in other forms, such as as a component plus function claim. Any claim intended to be treated under 35 U.S.SC §112(f) will begin with the phrase “for a component of…”, but the use of the term “for” in any other context is not intended to invoke treatment under 35 U.S.SC §112(f). Therefore, the applicant reserves the right to file supplementary claims in this application or subsequent applications after the filing of this application to pursue the form of such supplementary claims.

[0092] Example

[0093] These illustrative examples are not intended to limit or restrict the scope of this disclosure, but rather to provide examples to aid in understanding it. The illustrative examples have been discussed in the detailed embodiments further described above. The advantages of these examples can be further understood by reading this specification.

[0094] As used below, any reference to a series of examples should be understood as a separate reference to each of the examples (e.g., "Examples 1-4" should be understood as "Examples 1, 2, 3 or 4").

[0095] Example 1 is a computing device comprising: a computer-readable storage medium; processor-executable instructions stored on the computer-readable storage medium; and one or more processors coupled to the computer-readable storage medium and configured to execute the processor-executable instructions to operate a first network function (NF) within a first network, wherein the first NF function includes an access token engine such that the processor-executable instructions, when executed by the one or more processors, instruct the computing device to perform at least the following operations: receiving a service request from a visitor consumer NF, wherein the visitor consumer NF is located in a second network different from the first network; determining that the service request lacks an access token for receiving services from the first network; determining an access token for the visitor consumer NF based on the service request; generating an updated service request including the service request and the access token; and transmitting the updated service request to a producer NF within the first network, wherein the producer NF provides the service request to the visitor consumer NF based on the access token.

[0096] Example 2 is a computing device of any previous or subsequent example, wherein processor-executable instructions for determining an access token for a visitor-consumer NF based on a service request, when executed by the one or more processors, further instruct the computing device to: generate an access token request based on the service request, wherein the access token request includes one or more attributes associated with the visitor-consumer NF and the service request; and transmit the access token request to a second NF within a first network, wherein the second NF generates an access token in response to receiving the access token request.

[0097] Example 3 is a computing device of any previous or subsequent example, wherein the processor-executable instructions for determining an access token for a visitor-consumer NF based on a service request, when executed by the one or more processors, further instruct the computing device to: determine a unique identifier for the visitor-consumer NF based on the service request; perform a lookup in a visitor access token table based on the unique identifier; and determine, within the visitor access token table, an access token for the visitor-consumer NF, wherein the access token was previously generated for the visitor-consumer NF by a second NF function within the first network.

[0098] Example 4 is a computing device of any previous or subsequent example, wherein the processor-executable instructions for determining that a service request lacks an access token for receiving services from a first network, when executed by the one or more processors, also instruct the computing device to: identify the current access token for the visitor consumer NF within a visitor access token table; and determine that the expiration time associated with the current access token has expired.

[0099] Example 5 is a computing device of any previous or subsequent example, wherein processor-executable instructions, when executed by the one or more processors, further instruct the computing device to: determine a unique identifier for a visitor consumer NF based on a service request; determine an expiration time associated with an access token; and update a visitor access token table with the access token, the expiration time, and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF and the expiration time in the visitor access token table.

[0100] Example 6 is a computing device of any previous or subsequent example, wherein the first NF includes a Security Edge Protection Agent (SEPP) within the first network.

[0101] Example 7 is a computing device of any previous or subsequent example, wherein processor-executable instructions for determining an access token for a visitor consumer NF based on a service request, when executed by the one or more processors, further instruct the computing device to: determine one or more access token attributes based on the service request; generate an access token request including the one or more access token attributes; and retrieve an access token from a second NF within a first network using the access token request, wherein the second NF generates an access token in response to receiving the access token request.

[0102] Example 8 is a method comprising: determining a service request from a visitor-consumer NF by a first network function (NF), wherein the first NF is located in a first network and the visitor-consumer NF is located in a second network; determining, by an access token engine of the first NF, that the service request lacks an access token for receiving services from the first network; determining, by the access token engine, an access token for the visitor-consumer NF based on the service request; generating, by the access token engine, an updated service request including the service request and the access token; and transmitting, by the first NF, the updated service request to a producer NF within the first network, wherein the producer NF provides the service request to the visitor-consumer NF based on the access token.

[0103] Example 9 is a method of any previous or subsequent example, wherein determining the access token for the service request by the access token engine includes: generating an access token request based on the service request by the access token engine; transmitting the access token request to a second NF within a first network by the access token engine, wherein the second NF generates an access token in response to receiving the access token request; and receiving the access token from the second NF by the access token engine.

[0104] Example 10 is a method of any previous or subsequent example, wherein: determining that a service request lacks an access token for receiving services from a first network by the access token engine includes: identifying a current access token for a visitor consumer NF within a visitor access token table by the access token engine; determining that the current access token is invalid based on an expiration time associated with the current access token; and determining that an access token for a visitor consumer NF based on a service request by the access token engine includes: retrieving an access token for a visitor consumer NF from a second NF within the first network by the access token engine.

[0105] Example 11 is a method of any previous or subsequent example, wherein the access token engine determines the access token for the visitor consumer NF based on the service request by: performing a lookup of the visitor access token table by the access token engine based on the service request; and identifying the access token for the visitor consumer NF within the visitor access token table by the access token engine, wherein the access token was previously generated for the visitor consumer NF by a second NF function within the first network.

[0106] Example 12 is a method of any previous or subsequent example, wherein the access token engine determines the access token for the visitor consumer NF based on the service request by: the access token engine identifying the current access token for the visitor consumer NF in the visitor access token table; the access token engine generating a first updated service request including the current access token and the service request; the access token engine receiving an error response from the producer NF in response to transmitting the first updated service request to the producer NF; and the access token engine retrieving the access token from a second NF within the first network based on the service request.

[0107] Example 13 is a method of any previous or subsequent example, wherein the method further includes: determining a unique identifier for the visitor consumer NF based on the service request by the access token engine; and updating the visitor access token table by the access token engine with the access token and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF.

[0108] Example 14 is a method from any previous or subsequent example where the access token includes an open authorization token.

[0109] Example 15 is the approach of any previous or subsequent example, where the first NF includes a Security Edge Protection Proxy (SEPP) within the first network.

[0110] Example 16 is a computer-readable storage medium including processor-executable instructions, wherein the processor-executable instructions partially operate a first network function (NF) within a first network to cause one or more processors to: receive a service request from a visitor-consumer NF, wherein the first NF is located in a first network and the visitor-consumer NF is located in a second network; determine, by an access token engine of the first NF, that the service request lacks an access token for receiving services from the first network; determine, by the access token engine, an access token for the visitor-consumer NF based on the service request; generate, by the access token engine, an updated service request including the service request and the access token; and transmit the updated service request from the first NF to a producer NF within the first network, wherein the producer NF provides the service request to the visitor-consumer NF based on the access token.

[0111] Example 17 is a computer-readable storage medium of any previous or subsequent example, wherein processor-executable instructions determined by the access token engine for an access token for a visitor consumer NF cause the one or more processors to also execute processor-executable instructions stored in the computer-readable storage medium to perform the following operations: generating an access token request by the access token engine based on a service request, wherein the access token request includes one or more of the following: nfstanceID; nftype; targetnftype; scope of service; or requestorPLMN; and retrieving an access token from a second NF within a first network using the access token request, wherein the second NF generates an access token in response to receiving the access token request.

[0112] Example 18 is a computer-readable storage medium of any previous or subsequent example, wherein processor-executable instructions determined by the access token engine for an access token for a visitor-consumer NF cause the one or more processors to also execute processor-executable instructions stored in the computer-readable storage medium to perform the following operations: performing a lookup of the visitor access token table by the access token engine based on a service request; identifying, by the access token engine, an access token for a visitor-consumer NF within the visitor access token table, wherein the access token was previously generated for the visitor-consumer NF by a second NF function within the first network; and determining the validity of the access token by the access token engine based on the corresponding expiration time of the access token.

[0113] Example 19 is a computer-readable storage medium of any previous or subsequent example, wherein processor-executable instructions cause the one or more processors to also execute processor-executable instructions stored in the computer-readable storage medium to perform the following operations: determining the expiration time of an access token by an access token engine; associating the access token with a unique identifier of a visitor consumer NF by an access token engine; and storing the access token, expiration time, and unique identifier in a visitor access token table by an access token engine.

[0114] Example 20 is a computer-readable storage medium of any previous or subsequent example, wherein processor-executable instructions determined by the access token engine for an access token for a visitor consumer NF cause the one or more processors to also execute processor-executable instructions stored in the computer-readable storage medium to perform the following operations: retrieving an access token from a second NF within a first network using an access token request, wherein the second NF: includes a Network Functions Storehouse Function (NRF) within the first network; and generating an access token in response to receiving the access token request.

Claims

1. A computing device comprising: a computer-readable storage medium; processor-executable instructions stored on the computer-readable storage medium; and one or more processors coupled to the computer-readable storage medium and configured to execute the processor-executable instructions to operate a first network function (NF) within a first network, wherein the first NF function comprises an access token engine, such that the processor-executable instructions, when executed by the one or more processors, direct the computing device to at least: receive a service request from a visitor consumer NF, wherein the visitor consumer NF is located in a second network different from the first network; determine that the service request lacks an access token for receiving the service from the first network; determine an access token for the visitor consumer NF based on the service request; generate an updated service request comprising the service request and the access token; and transmit the updated service request to a producer NF within the first network, wherein the producer NF provides the service request for the visitor consumer NF based on the access token.

2. The computing device of claim 1, wherein the processor-executable instructions that determine the access token for the visitor consumer NF based on the service request, when executed by the one or more processors, further direct the computing device to: generate an access token request based on the service request, wherein the access token request comprises one or more attributes associated with the visitor consumer NF and the service request; and transmit the access token request to a second NF within the first network, wherein the second NF generates the access token in response to receiving the access token request.

3. The computing device of claim 1, wherein the processor-executable instructions that determine the access token for the visitor consumer NF based on the service request, when executed by the one or more processors, further direct the computing device to: determine a unique identifier for the visitor consumer NF based on the service request; perform a lookup of a visitor access token table based on the unique identifier; and determine the access token for the visitor consumer NF within the visitor access token table, wherein the access token was previously generated for the visitor consumer NF by a second NF function within the first network.

4. The computing device of claim 1, wherein the processor-executable instructions that determine that the service request lacks an access token for receiving the service from the first network, when executed by the one or more processors, further direct the computing device to: identify a current access token for the visitor consumer NF within a visitor access token table; and determine that an expiration time associated with the current access token has been exceeded.

5. The computing device of claim 1, wherein the processor-executable instructions, when executed by the one or more processors, further direct the computing device to: determine a unique identifier for the visitor consumer NF based on the service request; determine an expiration time associated with the access token; and update a visitor access token table with the access token, the expiration time, and the unique identifier, wherein the access token is associated with the unique identifier for the visitor consumer NF and the expiration time within the visitor access token table. ​ ​ 6. The computing device of claim 1, wherein the first NF comprises a Security Edge Protection Proxy (SEPP) within the first network.

7. The computing device of claim 1, wherein the processor-executable instructions that, when executed by the one or more processors, direct the computing device to, based on the service request, determine an access token for the visitor consumer NF: determine one or more access token attributes based on the service request; generate an access token request comprising the one or more access token attributes; and retrieve the access token from a second NF within the first network using the access token request, wherein the second NF generates the access token in response to receiving the access token request.

8. A method comprising: determining, by a first network function (NF), a service request from a visitor consumer NF, wherein the first NF is located in a first network and the visitor consumer NF is located in a second network; determining, by an access token engine of the first NF, that the service request is missing an access token for receiving a service from the first network; determining, by the access token engine based on the service request, an access token for the visitor consumer NF; generating, by the access token engine, an updated service request comprising the service request and the access token; and transmitting, by the first NF, the updated service request to a producer NF within the first network, wherein the producer NF provides the service request for the visitor consumer NF based on the access token.

9. The method of claim 8, wherein determining, by the access token engine, the access token for the service request comprises: generating, by the access token engine, an access token request based on the service request; transmitting, by the access token engine, the access token request to a second NF within the first network, wherein the second NF generates the access token in response to receiving the access token request; and receiving, by the access token engine, the access token from the second NF.

10. The method of claim 8, wherein: determining, by the access token engine, that the service request is missing an access token for receiving a service from the first network comprises: identifying, by the access token engine, a current access token for the visitor consumer NF within a visitor access token table; and determining, by the access token engine, that the current access token is invalid based on an expiration time associated with the current access token; and determining, by the access token engine based on the service request, an access token for the visitor consumer NF comprises: retrieving, by the access token engine, the access token for the visitor consumer NF from a second NF within the first network.

11. The method of claim 8, wherein determining, by the access token engine based on the service request, an access token for the visitor consumer NF comprises: performing, by the access token engine, a lookup of a visitor access token table based on the service request; and identifying, by the access token engine, an access token for the visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF within the first network for the visitor consumer NF.

12. The method of claim 8, wherein determining, by the access token engine based on the service request, an access token for the visitor consumer NF comprises: ​ ​ ​ ​ The access token engine identifies the current access token used for the visitor consumer NF within the visitor access token table; The access token engine generates a first updated service request, which includes the current access token and the service request. The access token engine receives an error response from the producer NF in response to transmitting the first updated service request to the producer NF. as well as The access token engine retrieves the access token from the second NF within the first network based on the service request.

13. The method of claim 8, wherein the method further comprises: The access token engine determines the unique identifier of the visitor consumer NF based on the service request; as well as The visitor access token table is updated by the access token engine with an access token and a unique identifier, where the access token is associated with the unique identifier of the visitor consumer NF.

14. The method of claim 8, wherein the access token includes an open authorization token.

15. The method of claim 8, wherein the first NF includes a Security Edge Protection Proxy (SEPP) within the first network.

16. A computer-readable storage medium including processor-executable instructions, wherein the processor-executable instructions partially operate a first network function (NF) within a first network to cause one or more processors to: Receive service requests from visitor consumer NF, where the first NF is located in the first network and the visitor consumer NF is located in the second network; The access token engine of the first NF determines that the service request lacks an access token for receiving services from the first network; The access token engine determines the access token for the visitor consumer NF based on the service request; The access token engine generates an updated service request that includes the service request and the access token. as well as The first NF transmits the updated service request to the producer NF within the first network, where the producer NF provides the service request to the visitor consumer NF based on the access token.

17. The computer-readable storage medium of claim 16, wherein processor-executable instructions determined by the access token engine for the access token of the visitor consumer NF cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to perform the following operations: The access token engine generates an access token request based on the service request, wherein the access token request includes one or more of the following: nfstanceID; nftype; targetnftype; Scope of service; or requestorPLMN; as well as The access token engine retrieves an access token from a second NF within the first network using an access token request, wherein the second NF generates an access token in response to receiving the access token request.

18. The computer-readable storage medium of claim 16, wherein processor-executable instructions determined by the access token engine for the access token of the visitor consumer NF cause the one or more processors to also execute processor-executable instructions stored in the computer-readable storage medium to perform the following operations: The access token engine performs a lookup in the visitor's access token table based on the service request; The access token engine identifies the access token for the visitor consumer NF in the visitor access token table, where the access token was previously generated for the visitor consumer NF by the second NF function within the first network; as well as The access token engine determines the validity of the access token based on its corresponding expiration time.

19. The computer-readable storage medium of claim 16, wherein the processor-executable instructions cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to perform the following operations: The access token engine determines the expiration time of the access token; The access token engine associates the access token with a unique identifier of the visitor consumer NF; as well as The access token engine stores the access token, expiration time, and unique identifier in the visitor access token table.

20. The computer-readable storage medium of claim 16, wherein processor-executable instructions determined by the access token engine for the access token of the visitor consumer NF cause the one or more processors to also execute processor-executable instructions stored in the computer-readable storage medium to perform the following operations: The access token engine uses an access token request to retrieve an access token from a second NF within the first network, where the second NF is: Including the Network Functions Store (NRF) function within the first network; and An access token is generated in response to receiving an access token request.

Images