WO2019035106A1

WO2019035106A1 - Efficient signalling multiplexing in a web-technology based network

Info

Publication number: WO2019035106A1
Application number: PCT/IB2018/056289
Authority: WO
Inventors: Jari Arkko
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-08-18
Filing date: 2018-08-20
Publication date: 2019-02-21

Abstract

Methods and systems providing optimization and flexibility in the authentication, AA, and resource authorization transactions between a AA server and a AA client or device are provided. According to one aspect, a method of operation in an AA device (client) comprises: initiating by the AA device an AA transaction for a user equipment with a first AA server (110) for establishing a first AA session. The AA device receives an instruction to simultaneously establish at least one second AA session with at least one second AA server and the AA device initiating a resource request for receiving an initial resource from the at least one second AA server while completing the AA transaction with the first AA server. The AA device may subsequently receive multiple streams of independent resource components pushed by the first AA server and/or the one or more second AA servers.

Description

Efficient Signalling Multiplexing in a Web-technology based network

Related Application

This application claims the benefit of US application serial number 62/547233, filed August 18^th, 2017, the disclosure of which is hereby incorporated herein by reference in its entirety.

Technical Field

[0001 ] Authentication, Authorization, and Accounting (AAA), DIAMETER, RADIUS, Service-Based Architecture (SBA), Fifth Generation (5G), core network, Server Push.

Background

[0002] The Third Generation Partnership Project (3GPP) is working on 5G, and one of the planned changes it to implement a so-called SBA. This is currently being specified in 3GPP SA2 group, in the 5G core network architecture document 23.501 (see overall 5G architecture: 3GPP Technical Specification (TS) 23.501 V1 .0.0: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 15) and overall 5G procedures: 3GPP TS 23.502 V0.4.0: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System; Stage 2 (Release 15)). The idea behind SBA is that a number of the interfaces and protocols within the core network (including roaming interfaces) are changed from legacy protocols such as Diameter to more modern, web-based tools that can be used to build what 3GPP calls "service-based architecture". Nevertheless, the same functions reside in these networks, no matter what protocols are used. The details of these protocols are being worked on, and these details matter as different ways of using web technology will result in large differences in how flexible, easy to secure, future-proof, or efficient 5G core systems will be.

Summary

[0003] Current Core networks such as the Evolved Packet Core, EPC, IP Multimedia Services, IMS, fixed access networks, that are point to point etc. rely on AAA

infrastructure which are based on DIAMETER or RADIUS to provide the Authentication, Authorization & Accounting for a user equipment, UE. The DIAMETER protocol is currently used over various interfaces in 3GPP networks and Internet Service provider networks for authenticating users and authorizing resources for the user equipment to be used. Typically, authorization of resources takes place following a successful authentication, where resources such for example IP address, authorized QoS, service profile, authorized applications and policies, etc. are provided as AAA attributes in AAA authorization response messages in response to AA authorization request messages.

[0004] With a web-based architecture, embodiments are described to optimize the above procedure where the network server, referred to as Authentication &

Authorization server, AA server, provides or initiates the push of the authorized resources for the user or user equipment to the network device while authentication is being executed. To further optimize the procedure, embodiments are provided where the resources are provided or pushed by other AA servers referenced by the AA server performing the authentication. To further optimize the procedure, embodiments are included where each independent resource component is pushed over on its own transport stream. Therefore, if more than one independent resource component is to be authorized and provided to the network device for the user, they are pushed in parallel streams instead of including all the independent resource components in a single stream. Consequently, the authorization procedure is faster and efficient. An embodiment is also included describing that as pushing of the resource components occurs while authentication of the user or user equipment is ongoing with the AA server performing authentication, and if authentication fails, the network device should purge all the received resources from the other AA servers.

[0005] In accordance with one aspect, a method of operation of a network device or entity of performing authorization of resources is provided. The method comprises initiating an Authentication and Authorization, AA, transaction for a user equipment with a first AA server for establishing a first AA session, and as a result receiving an instruction to simultaneously establish at least one second AA session with at least one second AA server and initiating a resource request for receiving an initial resource from the at least one second AA server while completing the AA transaction with the first AA server.

[0006] In accordance with another aspect, the method further comprises the network device receiving the initial resource from the at least one second AA server; and receiving one or more subsequent server push of one or more independent additional resource for the user equipment over one or more parallel transport streams from at least one of the first AA server and the at least one second AA server and where each independent additional resource is pushed over its own transport stream.

[0007] In accordance with another aspect, the instruction provided by the first AA server comprises at least one reference to the at least one second AA server, such as a Uniform Resource Identifier, URI, that would be used by the network device to branch to a separate transaction with the at least one second AA server for requesting initial resource and receiving subsequent push streams for the additional resources.

[0008] In accordance with another aspect, receiving the instruction from the first AA server further comprises receiving an indication that multiple responses to a single resource request is allowed from either of the first AA server or the at least one second AA server or both.

[0009] In another aspect, the method in the network device comprises storing the received initial and additional resources until the AA transaction with the first AA server is successfully completed, else received resources should be purged.

[0010] In accordance with another aspect, the network device is at least one of an Access Mobility Function, AMF, and a Session Mobility management, SMF, in a Fifth Generation, 5G, core network and the network device may be in a visited network or a radio access network and the AA server is in a home network where the AA server may also correspond to an Authentication Server Function, AUSF, and/or a Unified Data Management, UDM, in a 5G core network.

[0011 ] In accordance with one aspect, a method of operation of a network server, i.e., a AA server for providing the enhanced authentication and authorization procedure in a service based architecture that is similar to a web-based architecture is provided. The method comprises: receiving from a network device an Authentication and

Authorization, AA, request for establishing an AA session for a user equipment, UE. Then, if the resources governing authorization and policy for the UE are available within the same network server, initiating one or more simultaneous streams to push one or more independent resource components within the AA session wherein each independent resource component of the AA session is pushed over a corresponding transport stream. If the network (AA) server determines that the resources are available on one or more different network servers, sending to the network device a reference (e.g., URI) identifying each of the different network server so the network device can branch to the different network server to receive the resources. The initial resource component is provided in response to a request from the network device and additional resources are subsequently pushed in parallel streams.

[0012] In accordance with another aspect, the network server sends to the network device an additional information indicating that multiple simultaneous streams comprising independent resource components for the AA session is allowed from either the network server or the one or more different network server or both.

[0013] In accordance with another aspect, the simultaneous streams comprise solicited and unsolicited resources by the device, where the unsolicited resource may be discarded by the device.

[0014] In accordance with one aspect, a network server comprises at least one processor; and memory that comprises instructions executable by the at least one processor whereby the network entity is operable to perform any of the embodiments provided herein.

[0015] In accordance with another aspect, the network server is adapted to perform any of the embodiments provided herein.

[0016] In accordance with another aspect, a network device comprises at least one processor; and memory that comprises instructions executable by the at least one processor whereby the network entity is operable to perform any of the embodiments provided herein.

[0017] In accordance with another aspect, the network device or entity is adapted to perform any of the embodiments provided herein.

[0018] This summary is not an extensive overview of all contemplated embodiments and is not intended to identify key or critical aspects or features of any or all embodiments or to delineate the scope of any or all embodiments. In that sense, other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.

Brief Description of the Drawings

[0019] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0020] Figure 1 (Prior art) illustrates authentication and control of users in a conventional access network; [0021 ] Figure 2 (Prior art) illustrates one example system of a 3GPP Service based architecture.

[0022] Figure 3A (Prior art) and 3B illustrate timing of push vs. traditional AAA request processing according to an embodiment.

[0023] Figure 4 illustrates branching and parallel server push in accordance with an embodiment.

[0024] Figure 4A illustrates a method of operation in a network device or entity interacting with the AA server in accordance with some embodiments.

[0025] Figure 4B illustrates a method of operation in a server or server entity interacting with the network device in accordance with some embodiments.

[0026] Figures 5 through 7 illustrate example embodiments of a network node.

Detailed Description

[0027] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0028] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

[0029] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include 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 embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other

embodiments whether or not explicitly described.

[0030] 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," "includes," and/or "including" when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[0031 ] The idea in this disclosure relates to 5G core networks, but is also valid in a more general case of any networks consisting of a "visited" network and a "home network," or a "Network Access Server" and a "central control point.", or a "client" and a "server". The central idea of this disclosure also extends beyond the core network, into various control aspects in the Radio Access Network (RAN).

[0032] Traditionally, most core networks have been built to authenticate and control users wishing to access them. This control is typically arranged as shown in Figure 1 (Prior art). Current Core networks rely heavily on AAA infrastructure using as

DIAMETER as the Authentication, Authorization & Accounting (AAA) protocol. The DIAMETER protocol is used over various interfaces in today 3GPP and Internet Service provider networks. The following is a list of some of the EPC related functions and interfaces provided using DIAMETER in 3GPP:

S6a - Authentication, see 3GPP TS 29.272

Gy - Prepaid charging, see 3GPP TS 23.203, TS 32.299;

Gz - Postpaid charging;

- Gx - QoS/Policy, see 3GPP TS 29.21 1 , TS 29.212;

Rf - Charging, see 3GPP TS 32.299;

Ro - Charging, see 3GPP TS 32.299;

Rx - QoS/Policy, see TS 29.214;

S6d - Authentication;

- S9 - QoS/Policy;

Sh - Subscriber Profile;

Cx - Subscriber Profile;

e2 - Location. [0033] DIAMETER is also used to provide functions in IP Multimedia Subsystem, IMS, including:

Dh - used by AS to find the HSS holding the User Profile in multi-HSS environment;

- Dx - used by l-CSCF or S-CSCF to find a correct HSS in a multi-HSS environment;

Gq - to exchange policy decisions-related information between P-CSCF and PDF;

[0034] 5G networks (currently in development phase in 3GPP) are expected to support similar functions but using different communication interfaces.

[0035] The embodiments described herein are mainly described using DIAMETER as an example, however similar embodiments can be applied with other AAA protocols such as RADIUS or the likes and with Authentication and Authorization communication scheme that would be used in 5G SBA architecture.

[0036] The example in Figure 1 (Prior art) shows a typical core network arrangement that is found in most public networks, such as 3GPP networks. Figure 1 (Prior art) illustrates an example arrangement for the 5G or 4G core networks. When in 5G, the model illustrates 5G nodes including a 5G User Equipment, UE, an access server, e.g., a 5G Authentication Management Function, AMF, Session Management function, SMF, which may be in visited network and an authentication server, e.g., a 5G Authentication Server Function (AUSF) in the home network. This model is also used in a 4G Evolved Packet Core, EPC, network with Long Term Evolution (LTE) access network where the UE is a 4G UE connected to a Mobility Management Entity, MME, which is connected to a Home subscriber Server, HSS using the S6 DIAMETER interface. Additionally, when EPC supports non-3GPP access networks, there are other DIAMETER interfaces (e.g., SWn interface) that perform similar functions as the AAA (DIAMETER) interface illustrated in Figure 1 . Other DIAMETER interfaces currently used in EPC include policy based interfaces, such as Gx, Rx interfaces, accounting based interfaces such as Gz, Gy and the likes as described in 3GPP TS 23.401 .

[0037] The 5G core network arrangement is similar to EPC, but some or all of the interfaces are replaced from "legacy" protocols, such as DIAMETER, to more modern, web-based tools that can be used to build what 3GPP calls a "service-based

architecture" as illustrated in Figure 2 (Prior art). Nevertheless, similar functions to EPC reside in the 5G Core network, no matter what protocols are used. In particular, the 5G AMF is similar to 4G MME, the 5G AUSF is similar to 4G HSS, the 5G PCF is similar to 4G PCRF, etc.

[0038] The key function in the arrangement of Figure 1 is having a local access network (e.g., a visited network) ask a home network that knows the user (subscriber) to perform authentication and decide to authorize the user's device to be used in the visited network. In addition, this simple function is typically amended to provide a number of additional functions, e.g., set Quality of Service (QoS) parameters, keep a real-time count of the user's pre-paid time remaining, provide location information that can be used in various ways, such as set up some user-specific network configuration etc.

[0039] The 3GPP 5G system architecture is being changed to become more based on modern web technologies and APIs, and less on traditional telecom protocols that are mainly transactional based protocols such as for example the AAA DIAMETER protocols. As a part of that change, it makes sense to rethink not merely the underlying protocol details but also consider many practices that have been found useful in other contexts.

[0040] For instance, current AAA Systems using AAA protocols such as DIAMETER, operate on a single, end-to-end session that runs from a network access server (e.g., NAS, MME, GW, CSCF) to an authentication/policy server (e.g., AAA server, HSS, PCRF). At the end of an authentication transaction in a session a set of resources may be granted to the user (QoS class, addresses, etc). In a Service-Based Architecture model, the AAA protocols are replaced by web-based APIs, hence providing an opportunity to use the full scope of tools in the web protocol stacks to change how the transactions are performed.

[0041 ] For instance, embodiments are enclosed to describe how to arrange the AAA transactions so that they could be run more efficiently, do more things in parallel, or otherwise employ the web tools to their full extent. For example, an embodiment describes how different aspects of a transaction are packaged together in terms of transport protocol behavior. In the well-known TCP-based DIAMETER model for instance, all sessions flowing through a set of DIAMETER agents (proxies) are packaged in a single TCP transport session, leading to the possibility of head-of-the- line blocking. That is, a lost packet needs to be re-transmitted, but while this is being done, no other data from the TCP session beyond the lost packet can be used for delivering a payload to the application, even if no data associated with a particular session was not lost.

[0042] SCTP-based DIAMETER implementations avoid the TCP-based DIAMETER model problem by using either separate streams or unordered communications and where one blocked transaction does not then block others from completing. This is important, and modern web protocols such as HTTP 2 or QUIC allow similar multiplexing.

[0043] Embodiments described herein employ the multiplexing options offered by a modern web-based protocol stack for:

- splitting parts of an AAA transaction to separate streams so that they can proceed in parallel within one transport connection.

- Allowing AAA servers to push content thereby eliminating an

unnecessary roundtrip. Note that a AAA server described herein may be an HSS, an AUSF, a PCRF or a PCF or the likes.

- Using the web platform for splitting transactions automatically to

component parts through retrieval of separate URIs in separate connections or from different servers.

[0044] Splitting off a special resource (also referred to as component) to its own stream within a transport connection enables large files to be downloaded without impacting the rest of a transaction.

[0045] Figure 3A and 3B is an embodiment illustrating the timing difference between a traditional AAA signaling and a web-based AAA protocol using server push. Using server push enables AAA server to initiate sending a resource at time t1 as shown in Figure 3B. When using a traditional mechanism as shown in Figure 3A, the initial part of a resource could only be sent after the message sent at to has reached the AAA client (at t1 ), and further when the client has processed the message (at t2), requested the resource from the AAA server (at t3), and when that request arrives at the server (at t4) which responds with the requested resource. At t5, the AAA client receives the resource from the AAA server.

[0046] Allowing AAA systems to branch complex transactions to a set of sub- transactions makes it possible to parallelize further the complex transaction. With web protocols and data formats, it is also possible to automatically perform this branching, as a AAA node (e.g., NAS, MME, AMF, etc.) can be programmed to fetch the Uniform Resource Identifiers, URIs, it has received from the main authentication server. In previous systems such branching had to be done explicitly by programming the AAA node to do it.

[0047] Figure 4 illustrates an embodiment of AAA signaling improvement where within a single AAA session some components proceed in parallel and wherein part of the transaction is automatically redirected to other AAA node 120. For instance, an authorization transaction may result in a number of parameters for the user's session. These parameters could be, for instance, QoS settings, programing codes or even pointers to resources such as programing codes or a software image to be run in a virtual environment. Such resources can be retrieved in parallel with the rest of transaction proceeding. As a result, they can be placed on their own transport stream if the underlying transport protocols enable this. For instance, Hypertext Transfer Protocol 2, HTTP2 (specified in Internet Engineering Task Force, Request for Comment, IETF RFC 7540) allows this, and makes the independent streams even more independent if HTTP2 is run over Quick UDP Internet Connection, QUIC (currently described in IETF draft draft-hamilton-early-deployment-quic-00). This way all streams between the same parties share the same congestion control state but can proceed independently from a transport perspective.

[0048] In another embodiment, such parallel behavior is used for the retrieval of Authentication and Key exchange Algorithm, AKA, authentication vector from an authentication server with the other node 120 and which is fundamentally an

independent operation from the use of one of those vectors in authentication.

[0049] Referring to Figure 4, a AAA server 1 10 starts sending a resource even before the device 100 hosting a AAA client 100 has requested it, thereby avoiding a roundtrip where the AAA client parses a response and determines that it should request the resource. This is commonly used in web page loading when the server knows that a particular component on a page is always required. But it can also be used in the AAA setting for resources such as:

- Computer programming code,

- a software image,

- a user profile (e.g., QoS, filters, triggers, accounting profile) or

- other similar resources.

[0050] Some of these resources may consist of large files and therefore it would be desirable to break large monolithic resources to smaller parts (individual resource) to improve the overall quality of experience as information is quickly available at the AAA client allowing services to be provided quickly for the UE. If one or more resource is a special resource represented by a large file, it would be beneficial to enable the AAA server to simultaneously push each of the special resource to the AAA client (or proxy) over its own individual transport stream.

[0051 ] Furthermore, the AAA server may send one or more resource over a single transport stream when the one or more resource is not described or represented by a large file.

[0052] The AAA server would determine the number of streams it should push in parallel in accordance with the number and size of the resources.

[0053] Although the AAA server would be enabled to push multiple resources at a time over parallel streams without explicitly being solicited for those resources, the AAA client may simply discard the resources that it wouldn't use. The AAA server may have a preconfigured profile indicating the type of resources to be pushed based on the user profile and/or the type and capabilities of the device hosting the AAA client and/or the capability/agreement of the network where the device is located (e.g., if the device is in a visited network) and/or the type of access network technology.

[0054] Furthermore, while the AAA transactions are naturally end-to-end between two parties and intervening proxies, in a Service-Based Architecture and web models one can imagine some aspects of a user authentication transaction be split to different parties. For instance, the actual authentication transaction and user's settings retrieval may reside in different places illustrated as other AAA node 120 in Figure 4 (e.g., other AAA servers, policy server, etc.). The NAS, AMF, SMF, MME, etc. hosting a AAA client or a proxy AAA may initiate multiple parallel operations with different parties, as long as the resources resulting from the resource transactions do no take effect until authentication itself has completed successfully.

[0055] In this regard, Figure 4 illustrates one example system in which embodiments of the present disclosure may be implemented. Figure 4 includes a device 100 hosting a AAA client (e.g., a UE 10, base station, NAS, MME, AMF, SMF, etc.), a AAA server 1 10 (e.g., an authentication server, a policy server, etc.) and other AAA node 120 which may be other AAA server, policy server, HSS, etc. In one embodiment, the device 100 is in a visited network and the AAA server 1 10 and other AAA node 120 are in the home network of the UE 10, where the visited network may include other network nodes/functions and the home network may include other network nodes/functions in addition to the AAA server 1 10. The device 100, the AAA server 1 10 and the other AAA node 120 may also be within the same network.

[0056] As illustrated in Figure 4, at time to, the device 100 initiates user

authentication with the AAA server 1 10 for a UE accessing a network. The device 100 sends at step 400 an authentication request to the AAA server 120. At time t1 , the AAA server 120 proceeds with processing the authentication request and also determines that one or more resources related to user's settings could be sent to the device 100 while authentication is still in progress. As exemplified in Figure 4, the resources are however located in other AAA node 120. The AAA server 1 10 includes a

PUSH PROMISE frame/indicator to instruct the device 100 to use pushed resource related to the user's settings and allows the AAA server 1 10 to send multiple responses for a single request. In this embodiment, the resources are located on other AAA server(s) 120, the AAA server 1 10 would then include a reference or link (e.g., a URI) of the other node AAA 120 from where the device 100 can retrieve the initial push resource and receive server push requests pushing other related resources. By sending the URI of the other AAA server or node 120, the AAA server 1 10 is thus instructing the device 100 to initiate a parallel transaction with the other AAA node 120 for receiving resources related to the user's settings while completing the authentication transaction with the AAA server 1 10. At step 410, the AAA server 1 10 may include the

PUSH PROMISE as an indicator in the initial response. Alternatively, the AAA server 1 10 may send the PUSH_PROMISE as a separate PUSH_PROMISE frame (as in HTTP2/QUIC) in parallel with the initial response sent to the device 100 at step 410. In an embodiment, the PUSH_PROMISE in association with the URI of the other AAA node 120 could be used to indicate that multiple responses for a single request may be initiated by the AAA server 1 10 or the other AAA node 120 pointed by the URI, or both.

[0057] At time t2 and step 410, the device 100 receives the initial response which comprises the PUSH_PROMISE and a URI, pointing to the other AAA node 120, which the device 100 should use to retrieve the initial push resource. Note that if resources are located in more than one other AAA node 120, the initial response at step 410 would include one or more corresponding URI.

[0058] At step 420, at time t3, the device 100 sends a resource request to the other AAA node 120, pointed by the URI, to establish a AAA session for retrieving the initial push resource while in parallel, continuing execution of the authentication transactions with the AAA server 1 10. At step 430 and in response to the received resource request, the other AAA node 120 sends the initial resource to the device 100 and may also include a PUSH PROMISE indicator/frame. Subsequent server push for additional resources may be sent in parallel streams by the other AAA node 120 to the device 100 without the device 100 requesting for the resources. Each response corresponds to an independent component or resource (resource that may be required or used for the UE while connected to the network) pushed within their own transport streams. The device 100 stores the resources received at step 430 and resources received in subsequent push server (not shown in Figure 4) until the user authentication transaction it performs with the AAA server 1 10 is successfully completed.

[0059] In parallel with step 420, at time t3, the device 100 continues its

authentication transaction with the AAA server 1 10. Once the user authentication is successfully completed, the device 100 uses the stored pushed resources to manage the user's session(s).

[0060] The device 100 may receive subsequent push resources by the other AAA node 120 and/or AAA server 1 10 even after the authentication is completed.

[0061 ] In summary, the embodiments of the solution as presented herein are based on the following principles:

- use of separate streams for components within a single session,

- use of push-type initiation for some of these components, and

- automatic reaction to the reception of an URI that needs to be branched off to a separate transaction with another AAA node.

[0062] Figure 4A illustrates a method of operation in a device 100 interacting with the AAA or AA server(s) 1 10, 120 in accordance with some embodiments. The device may be a 5G AMF, SMF or could be an element of a radio access network such as eNB or gNB. The method comprises the step 41 OA when the device executes the step of initiating an Authentication and Authorization, AA, transaction for a user equipment with a first AA server in order to establish a first AA session which is typically used for authenticating the user equipment or user. In current implementations of AAA protocols, authentication should be successfully completed prior to providing authorized resources for the user to the device. However, in the embodiment herein, the method in the device comprises step 420A of receiving an instruction from the first AA server in response to the first AA communication instructing the device to initiate one or more other transactions with other one or more AA servers in order to retrieve or receive the resources for the user while still authentication is ongoing with the first AA server. The instruction may consist of a reference to the one or more AA servers, where the reference may be a URI and may also be an IP address, an FQDN or any reference that will allow the device to reach the AA server. In addition to the instruction, the device may also receive an additional information to indicate that subsequent server push may be received from either the first AA server or the other AA servers or even both in order to push more resources that can be applied for the user or the user equipment. The pushed resources may correspond to requested or non-requested resources. Non-requested resources may be discarded by the device at successful completion of the user/user equipment authentication with the first AA server.

[0063] A number of alternatives are described:

1 . The first AA server may determine that resources to be applied for the user are only available in one or more other AA servers.

2. One or more resource to be applied for the user equipment is available at the first AA server and other resources are available in one or more other AA servers.

3. All resources are available at the first AA server, in which case the first AA server may only indicate subsequent server push without indicating reference to other AA servers, in which case the subsequent push server for additional resources are received by the device subsequent to receiving the response to the first AA

communication. The initial resource may be received in the response to the first AA communication in step 410 or in the first server push. As indicated below, each independent resource is pushed in its own transport stream.

[0064] At step 430, the device starts initiating a resource request for receiving an initial resource from the at least one of the other AA server while still completing the AA transaction with the first AA server.

[0065] In response to the resource request sent to the other AA server, the device may receive an initial or the first resource component or components. The device may subsequently be receiving from the AA server or at least one of the other AA server or both, one or more subsequent server push pushing one or more independent additional resource for the user equipment, without the device necessarily and explicitly requesting for the resource. Each independent additional resource is received on its own transport stream. If more than one independent additional resource is received, they may be received over parallel (simultaneous) transport streams, where each independent resource is on its own transport stream. [0066] Figure 4B illustrates a method of operation in a network server such as a AAA or AA server interacting with an entity such as a network device 100 in the network in accordance with some embodiments. The method comprises the step 410B of receiving from the network device an Authentication and Authorization, AA, request for establishing an AA session for a user equipment, UE. The network server determines if:

- the resources governing authorization and policy for the UE are available at the same network server, or

- no resources governing authorization and policy for the UE are available at the network server or

- if some resources governing authorization and policy for the UE are available in other network servers and some are available in the same network server.

[0067] At step 420B, in response to determining that resources governing

authorization and policy for the UE are available within the network server, it executes the step of initiating one or more simultaneous streams to push one or more

independent resource components within the AA session. Each independent resource component of the AA session is pushed over its own transport stream. The initial resource may be sent in response to the request or may be sent in the first server push. The network server may also include a PUSH PROMISE indicator/frame and subsequent server push for additional resources may be sent in parallel streams by the network server to the device without receiving a request for the resources.

[0068] At step 430B, in response to determining that resources governing

authorization and policy for the UE are available on one or more different network servers, the network server executes the step of sending to the device a reference identifying each of the different network server to allow the device to reach the different network server. A reference for each of the different network server may be a URI, an IP address or any other reference that may be used by the device to reach the different (or other) network server.

[0069] Each of the other network server for which a reference is provided to the device may then receive a resource request. The resource request may include an indication that the user equipment is being authenticated by the network server, e.g., a token, an identification of the authentication server, a cookie received from the network server, etc. the other network server may provide an initial resource in the response, and/or it may provide a PUSH_PROMISE indicator/frame. The PUSH_PROMISE indicator indicates that subsequent server push from the other network servers for additional resources may be sent in parallel streams to the device without the network server receiving a request for the resources.

[0070] Figure 5 is a schematic block diagram of a network node 500 (e.g., the device 100 hosting a AAA client or the authentication server 1 10 or the other node 120) according to some embodiments of the present disclosure. As illustrated, the network node 500 includes one or more processors 520 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 522, and a network interface(s) 524. In some embodiments, the functionality of the network node 500 described above may be fully or partially implemented in software that is, e.g., stored in the memory 522 and executed by the processor(s) 520.

[0071 ] Figure 6 is a schematic block diagram that illustrates a virtualized

embodiment of the network node 500 in a system 600 (e.g., the device 100 hosting a AAA client or the authentication server 1 10 or the other node 120) according to some embodiments of the present disclosure. As used herein, a "virtualized" network node 500 is a network node 500 in which at least a portion of the functionality of the network node 500 is implemented as a virtual component (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, the network node 500 includes one or more processing nodes 526 coupled to or included as part of a network(s) 528. Each processing node 526 includes one or more processors 530 (e.g., CPUs, ASICs, DSPs, FPGAs, and/or the like), memory 532, and a network interface 534.

[0072] In this example, functions 536 of the network node 500 (e.g., functions of the device 100 hosting a AAA client or the authentication server 1 10 or the other node 120) described herein are implemented at the one or more processing nodes 526 (e.g., distributed across multiple processing nodes 526) in any desired manner. In some particular embodiments, some or all of the functions 536 of the network node 500 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 526.

[0073] In some embodiments, a computer program including instructions which, when executed by the at least one processor 520, 530 causes the at least one processor 520, 530 to carry out the functionality of the network node 500 or a processing node 526 according to any of the embodiments described herein is provided. In some embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as the memory 522, 532).

[0074] Figure 7 is a schematic block diagram of the network node 500 (e.g., the device 100 hosting a AAA client or the authentication server 1 10 or the other node 120) according to some other embodiments of the present disclosure. The network node 18 includes one or more modules 538, each of which is implemented in software. The module(s) 538 provide the functionality of the network node 500 described herein (e.g., the functionality of the device 100 hosting a AAA client or the authentication server 1 10 or the other node 120) as described herein, e.g., with respect to Figures 3B and 4).

Example Embodiments

[0075] While not being limited thereto, some example embodiments of the present disclosure are provided below.

1 . A method of operation of a device (100), comprising:

Initiating an Authentication Authorization and Accounting, AAA, transaction for a user equipment with a first AAA server (1 10) for establishing a first AAA session;

receiving an instruction to simultaneously establish a second AAA session and initiate a resource request for receiving an initial resource from a second AAA server (120). 2. The method of embodiment 1 further comprising receiving in response to the resource request, the initial resource and one or more subsequent push responses from at least one of the first AAA server 1 10 and the second AAA server (120) containing additional resources wherein the one or more subsequent push responses correspond to one or more independent resource of the additional resources (components) and each within its own transport stream.

3. The method of embodiment 1 wherein the instruction comprises a reference to the second AAA server (120). The method of embodiment 3 wherein the reference is a uniform resource identifier, URI. The method of embodiment 3 wherein the method further comprises using the reference to branch to a separate transaction with the second AAA server. The method of embodiment 1 wherein the receiving step further comprises receiving an indication that multiple responses to a single resource request is allowed for at least one of the first AAA server and the second AAA server. The method of embodiment 1 wherein the AAA transaction is an

authentication transaction. The method of embodiment 1 , 2 and 6 wherein the method further comprises storing the received resources until the AAA transaction is successfully completed. The method of any one of embodiments 1 to 7 wherein the device (100) is at least one of an AMF and an SMF in a 5G core network. The method of embodiment 8 wherein the device (100) is in a visited network by the user equipment. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of embodiments 1 to 10. A carrier containing the computer program of embodiment 1 1 , wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium. A method of operation of a network server (1 10, 120), comprising: - receiving from a device an authentication and authorization request for establishing a AAA session for a user equipment, UE;

- if resources governing UE's authorization and policy (user's

settings) are available on the network server (1 10, 120), initiating one or more stream to push one or more component (resources) within the AAA session wherein independent components of the session are in their own transport streams; and

- If resources are available on a different network server, sending to the device a reference identifying the different network server for allowing the device to branch off to a separate transaction with the different network server. The method of embodiment 13 wherein the reference is a uniform resource identifier, URI.

The method of embodiment 13 wherein the network server (1 10) is a 5G AUSF. A network server (1 10, 120) adapted to perform the method of any one of embodiments 13 to 15. A network server (1 10, 120) comprising:

a network interface;

one or more processors; and

memory comprising instructions executable by the one or more processors whereby the network server (1 10, 120) is operable to perform the method of any one of embodiments 13 to 15. A network server (1 10, 120) comprising:

one or more modules operable to perform the method of any one of embodiments 13 to 15. A device (100) adapted to perform the method of any one of embodiments 1 to 10. A device (100) comprising:

a network interface;

one or more processors; and

memory comprising instructions executable by the one or more processors whereby the device (100) is operable to perform the method of any one of embodiments 1 to 10. A device (100) comprising:

one or more modules operable to perform the method of any one of embodiments 1 to 10. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of embodiments 13 to 15. A carrier containing the computer program of embodiment 22, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

The following acronyms are used throughout this disclosure.

3GPP Third Generation Partnership Project

5G Fifth Generation

AAA Authentication, Authorization, and Accounting

AMF Authentication Management Function

AUSF Authentication Server Function

CPU Central Processing Unit

DSP Digital Signal Processor

HSS Home Subscriber Service

HTTP Hypertext Transfer Protocol

IMS Internet Protocol based Multimedia call System

IP Internet Protocol

LTE Long Term Evolution

MME Mobility Management Entity PCRF Policy Control

QoS Quality of Service

QUIC Quick UDP Internet Connections

RAN Radio Access Network

RFC Request for Comments

SBA Service- Based Architecture

SMF Session Management Function

TCP Transmission Control Protocol

TS Technical Specification

UE User Equipment

URI Uniform Resource Identifier

[0077] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims:

1 . A method of operation of a device (100), comprising:

initiating an Authentication and Authorization, AA, transaction for a user equipment with a first AA server (1 10) for establishing a first AA session; receiving an instruction to establish at least one second AA session with at least one second AA server (120); and

initiating a resource request for receiving an initial resource from the at least one second AA server (120) while completing the AA transaction with the first AA server (1 10).

2. The method of Claim 1 further comprising:

receiving the initial resource from the at least one second AA server (120); and

- receiving one or more subsequent server push of one or more independent additional resource for the user equipment over one or more parallel transport streams from at least one of the first AA server (1 10) and the at least one second AA server (120) wherein each independent additional resource is pushed over a corresponding transport stream.

3. The method of Claim 1 wherein the instruction comprises at least one

reference to the at least one second AA server (120).

4. The method of Claim 3 wherein the at least one reference is a uniform

resource identifier, URI.

5. The method of Claim 3 wherein the method further comprises using the at least one reference to branch to a separate transaction with the at least one second AA server (120).

6. The method of Claim 1 wherein the receiving step further comprises receiving an indication that multiple responses to a single resource request is allowed from at least one of the first AA server (1 10) and the at least one second AA server (120).

7. The method of Claims 1 and 6, wherein the multiple responses comprise push of parallel streams comprising solicited and unsolicited resources.

8. The method of Claim 1 , 2 and 6 wherein the method further comprises

storing the received initial and additional resources until the AA transaction with the first AA server (1 10) is successfully completed.

9. The method of Claims 1 , 7 and 8 wherein the method further comprises

discarding any unsolicited resources following successful completion of the AA transaction with the first AA server (1 10).

10. The method of any one of Claims 1 to 9 wherein the device (100) is at least one of an Access Mobility Function, AMF, and a Session Mobility

management, SMF, in a Fifth Generation, 5G, core network.

1 1 . The method of Claim 1 wherein the device (100) is in a visited network and the AA server is in a home network.

12. The method of any of Claims 1 -1 1 wherein the AA server correspond to at least one of Authentication Server Function, AUSF, and a Unified Data Management, UDM, in a 5G core network.

13. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of Claims 1 to 12.

14. A carrier containing the computer program of Claim 13, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

15. A method of operation of a network server (1 10, 120), comprising: - receiving from a device (100) an Authentication and Authorization, AA, request for establishing an AA session for a user equipment, UE;

- in response to determining that resources governing authorization and policy for the UE are available within the network server, initiating one or more simultaneous streams to push one or more independent resource components within the AA session wherein each independent resource component of the AA session is pushed over a corresponding transport stream; and

- in response to determining that resources are available on one or more different network servers, sending to the device (100) a reference identifying each of the different network server.

16. The method of Claim 15 wherein the reference to the different network server is a uniform resource identifier, URI.

17. The method of Claim 15 wherein the network server (1 10) corresponds to at least a fifth generation, 5G, Authentication Server Function, AUSF and a User Data management, UDM.

18. The method of Claim 15 wherein sending to the device (100) a reference identifying each of the different network server further comprises sending an additional information indicating that multiple simultaneous streams comprising independent resource components for the AA session is allowed from at least one of the network server and the one or more different network server.

19. The method of Claims 15 and 18, wherein the simultaneous streams

comprise solicited and unsolicited resources by the device (100).

20. A network server (1 10, 120) adapted to perform the method of any one of Claims 15 to 19.

21 . A network server (1 10, 120) comprising: a network interface;

one or more processors; and

memory comprising instructions executable by the one or more processors whereby the network server (1 10, 120) is operable to perform the method of any one of Claims 15 to 19.

22. A network server (1 10, 120) comprising:

one or more modules operable to perform the method of any one of Claims 15 to 19.

23. A device (100) adapted to perform the method of any one of Claims 1 to 12.

24. A device (100) comprising:

a network interface;

one or more processors; and

memory comprising instructions executable by the one or more processors whereby the device (100) is operable to perform the method of any one of Claims 1 to 12.

25. A device (100) comprising:

one or more modules operable to perform the method of any one of Claims 1 to 12.

26. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of Claims 15 to 19.

27. A carrier containing the computer program of Claim 26, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.