Patent Application
20170164212
The present embodiments generally relate to network slice management, and in particular to selection of network slices for user devices and/or users.
A network slice, sometimes denoted network instance in the art, is a logical instantiation of a network, where Virtualized Network Functions (VNFs) can be delivered and deployed as pre-integrated systems. From the management perspective, network slicing splits the network management domain into sub-domains. Each network slice has its own management domain, allowing deployment, upgrade, and any other network operation to be independent of other network slices. More importantly, network slicing enables Mobile Virtual Network Operators (MVNOs) and service providers to have their own network slices, which can be crafted to meet the policy, expected behavior and requirements of different type of data or communication services. Network slicing allows a service provider to be focused on the management of network solutions driven by business requirements with self-contained and automated network architecture.
Thus, a network operator would have a physical network infrastructure, which could support many separate virtualized networks, i.e. network slices. Each such network slice may then have unique characteristics for meeting specific requirements of the use case it serves. Network slicing thereby allows, for instance, separation of data traffic for different types of services, business segment separation, maintaining integrity between different services, performance optimization for different services, usage of different security levels and performing software upgrades in separate network slices.
For example, a network slice could include Public Data Network (PDN) Gateway (GW) (PGW), Serving GW (SGW), Mobile Management Entities (MMEs) and Policy Control Resource Functions (PCRFs) as Evolved Packet Core (EPC) for typical mobile broadband usage. Another network slice has combined PGW/SGW and an MME, but no PCRF, using only static policies but no per user dynamic policies. The MME could be simplified for stationary Machine Type Communication (MTC) and Machine-to-Machine (M2M) services. There could be also network slices dedicated to users having non-Subscriber Identity Module (non-SIM) identities and various specific authentication mechanisms, e.g. Facebook or Google slices. In such a case, the network slice might contain only a limited subset of EPC functions. In general, a network slice has to be able to identify and authenticate all attached user devices.
In the current mobile networks, a user device is attached to a network provider independently on traffic type or subscribed services. The same is valid in the roaming scenario when only preferred visited networks are used. From the other end, the network slicing concept can result in a high number of network slices and Virtual Network Operators (VNOs) sharing the same network infrastructure. Different network slices can be related to numerous user device identity types and numerous authentication mechanisms. User device identity could, for instance, be SIM identity, bank account identity, Internet of Things (IoT) sensor identity, etc. Therefore, selecting a network slice is becoming an important new function addressing new requirements. Network slice discovery and selection should be dynamic, flexible and extendable in comparison with an existing networks, where selection is fixed, restrictive and controlled by a single network operator.
There is, thus, a need for an efficient selection of network slices for users and/or user devices.
It is a general objective to provide an efficient selection of network slices for users and/or user devices.
This and other objectives are met by embodiments as defined herein.
An aspect of the embodiments relates to a network slice selection method. The method comprises authenticating, by an identity manager of a network operator providing multiple network slices having a respective network slice type, a user device and/or a user of the user device based on a network attachment request originating from the user device to correlate the user device and/or the user to a network slice type. The method also comprises authorizing, by the identity manager, access to a network slice of the network slice among the multiple network slices based on credentials of the user device and/or the user. The method further comprises providing, by the identity manager and for transmission to the user device, information of an entry point to an application provided by the network slice.
Another aspect of the embodiments relates to an identity manager. The identity manager is configured to authenticate a user device and/or a user of the user device based on a network attachment request originating from the user device to correlate the user device and/or the user to a network slice type of a network operator providing multiple network slices having a respective network slice type. The identity manager is also configured to authorize access to a network slice of the network slice type among the multiple network slices based on credentials of the user device and/or the user. The identity manager is further configured to provide, for transmission to the user device, information of an entry point to an application provided by the network slice.
A related aspect of the embodiments defines an identity manager. The identity manager comprises an authentication unit for authenticating a user device and/or a user of the user device based on a network attachment request originating from the user device to correlate the user device and/or the user to a network slice type of a network operator providing multiple network slices having a respective network slice type. The identity manager also comprises an authorization unit for authorizing access to a network slice of the network slice type among the multiple network slices based on credentials of the user device and/or the user. The identity manager further comprises a providing unit for providing, for transmission to the user device, information of an entry point to an application provided by the network slice.
A further aspect of the embodiments relates to a computer program comprising instructions, which when executed by at least one processor, cause the at least one processor to authenticate a user device and/or a user of the user device to correlate the user device and/or the user to a network slice type of a network operator providing multiple network slices having a respective network slice type. The at least one processor is also caused to authorize access to a network slice of the network slice type among the multiple network slices based on credentials of the user device and/or the user. The at least one processor is further caused to provide, for transmission to the user device, information of an entry point to an application provided by the network slice.
A related aspect of the embodiments defines a carrier comprising a computer program as defined above. The carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Another related aspect of the embodiments defines a computer-program product comprising a computer-readable medium having stored thereon a computer program as defined above.
The present embodiments provide support for attachment and selection of network slices for a variety of user devices. The present embodiments furthermore allow reduction of the total number of advertised network slices per network operator to a low number, or even a single network slice comprising an identity manager that may handle network slice attachment and selection for all network slices of the network operator and for all types of user devices.
The embodiments, together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which:
Throughout the drawings, the same reference numbers are used for similar or corresponding elements.
The present embodiments generally relate to network slice management, and in particular to selection of network slices for user devices and/or users.
Network slicing creates an efficient way to deploy and manage network services and business offering. End users can use a network slice, sometimes denoted network instance in the art, which provides services they subscribe to. In order to achieve this, proper network slice selection mechanisms should be in place to allow selection of a correct network slice for users.
Unlike their 2G/3G/4G predecessors, 5G will bring an ability of operators and their equipment suppliers to seamlessly integrate all types of access technologies, i.e. fixed, mobile, WiFi, short-range radios, etc., to serve a number of use cases. The prior art solution of selecting a network slice for a user presumes that each user device has a subscribed identity module (SIM) card. This means that the information needed to select a network slice resides or is relied on the SIM card.
However, 5G requires a network slice selection mechanism that supports both SIM-based devices and user devices without any SIM cards, such as a sensor that does not have SIM card due to its limited size or cost. Further issues with regard to implementing an efficient network slice selection mechanism include deployment scalability and backwards compatibility. In order to support existing user devices, e.g. legacy mobile phones, existing sensors and so on, it is generally better to provide a network slice selection mechanism allowing user devices to connect to network slices without having to upgrade the user devices.
Network slices may be created upon business demands. This means that one service provider or mobile virtual network operator (MVNO) could offer multiple network slices for its own business customers for various use cases. Furthermore, it would be possible to increase or decrease the number of network slices upon changing business needs. Accordingly, the number of network slices may in the near future be too large for current mobile networks to handle with the prior art selection mechanisms. Thus, proper a network slice selection mechanism needs to cope with the volume and dynamics of network slices.
The present embodiments introduce an identity manager (IDM) that acts as an authentication and authorization entity, and also serves as a network slice attachment point when a user device sends attachment request via a network node, such as evolved NodeB (eNodeB or simply eNB). User and/or user device identification in the IDM triggers selection of a network slice type capable of handling the identified user and/or user device. Following authentication in the IDM, a final network slice selection is made to determine whether the user and/or user device is authorized to connect to that network slice.
The proposed technology is very flexible and can therefore be applied to achieve network slice selection for virtual network operators (VNOs) providing multiple network slices even though the actual network infrastructure may be owned and provided by another entity, the network owner. Such a VNO is sometimes denoted MVNO in the art in particular if the relevant network infrastructure provides mobile, radio-based communication services. The proposed technology is, however, not limited to network slice selection for VNOs and MVNOs but can also be applied to non-virtualized operators. In such a case, the network operator providing the multiple network slices is typically also the network owner, i.e. owns the network infrastructure or at least a portion thereof.
The network infrastructure includes network nodes. As used herein, the non-limiting term “network node” may refer to base stations, access points, network control nodes, such as network controllers, radio network controllers, base station controllers, access controllers, and the like. In particular, the term “base station” may encompass different types of radio base stations including standardized base station functions, such as NodeBs, or eNBs, and also macro/micro/pico radio base stations, home base stations, also known as femto base stations, relay nodes, repeaters, radio access points, Base Transceiver Stations (BTSs), and even radio control nodes controlling one or more Remote Radio Units (RRUs), or the like.
As used herein, a user device, also referred to as user equipment (UE), may refer to a mobile phone, a cellular phone, a Personal Digital Assistant (PDA) equipped with radio communication capabilities, a smart phone, a laptop or Personal Computer (PC) equipped with an internal or external mobile broadband modem, a tablet with radio communication capabilities, a target device, a device to device UE, a machine type UE or UE capable of machine to machine communication, Customer Premises Equipment (CPE), Laptop Embedded Equipment (LEE), Laptop Mounted Equipment (LME), USB dongle, a portable electronic radio communication device, a sensor device equipped with radio communication capabilities or the like. In particular, the term “user device” should be interpreted as a non-limiting term comprising any type of device capable of communicating with a network node in a wireless communication system and/or possibly communicating directly with another user device. In other words, a user device may be any device equipped with circuitry for wireless communication according to any relevant standard for communication.
Due to higher business demands in the network slicing architecture, the number of network slices can easily get too large for the current mobile network to handle. For instance, one network operator can have multiple network slices for different user device types, different services as well as for different operational reasons. With a large number of network slices supporting different user device types for different services, network slice selection is becoming a very difficult and segmented function.
The proposed network slice selection method uses an identity manager, also denoted Identity Management (IDM) component, to determine user device and/or user correlated network slices. The proposed technology introduces a common identity manager per network operator that can be part of each network slice, distributed among network slices or implemented in a single network slice. This results in a flexible and scalable setup where a network operator can advertise a single network slice, or a subset of the network slices, to users.
The method steps of the network slice selection method are thereby preferably performed by and in an identity manager. Each network operator thereby preferably has access to at least one such identity manager, although it may be feasible for multiple network operators to have a common identity manager handling network slice selection for users accessing a network slice of either network operator.
The identity manger then manages the two main steps of the network slice selection, i.e. the user and/or user device authentication in step S1 and the user and/or user device authorization in step S2. The authentication step is performed in order to authenticate the user and/or user device transmitting a network attachment request. This authentication in turn correlates or connects the user or user device to a particular network slice type.
Each network slice has a respective network slice type. In such a case, each network slice provided by the network operator could have a unique networks slice type that is different from the network slice types of all other network slices provided by this network operator. Thus, if the network operator provides N≧2 network slices these are of N different network slice types, T1, T2, . . . , TN. Alternatively, at least two of the network slices provided by the network operator could be of the same network slice type.
The network slice type division could be based on the services provided in or the applications provided by, i.e. running in, the network slice, such as mobile or wireless broadband (MBB) services or applications, mobile or wireless multicast services or applications, Machine Type Communication (MTC) services or applications, Machine-to-Machine (M2M) services or applications, etc.
A further alternative is to define network slice types depending on the authentication mechanism to authenticate users or user devices, such as SIM-based network slices, Facebook network slices, Google network slices, etc.
Yet another alternative to define network slice types is based on the functionality included or supported by the network slice, such as PGW, SGW, MMEs, and/or PCRFs, etc.
The second step, the authorization steps, is performed in order to verify that the user and/or user device is authorized to select a network slice of the correct or identified network slice type. This user and/or user device authorization is managed by the identity manager based on credentials of the user and/or user device. The identity manager could be the authorizing entity performing this authentication process all by itself. Alternatively, the identity manager could cooperate with and use another authorization device or logic to perform the user and/or user device authorization. In this case, the identity manager operates similar to an authorization proxy.
Once, and preferably only once, a user and/or user device has been successfully authenticated and authorized, the identity manager provides information of an entry point to an application running in or provided by the network slice of the identity network slice type. This information can then be sent to the user device in order to enable the user device to access the application and the network slice.
The authentication and authorization performed in
In this embodiment, identity managers of network operators are registered at a database as respective attachment entry points for the network slices provided by the respective network operators. This means that any attachment requests generated by user devices in connection with accessing a network slice is sent or directed to the attachment entry point registered in the database.
The database could be any database or register that houses the information of the identity managers, i.e. information allowing transmission of network attachment requests to the identity managers. As a non-limiting but illustrative example of a particular implementation of such a database, the registration in step S10 could be made at a Domain Name System (DNS) server. The information registered in the database is thereby location information or address information of the identity manager.
In a particular embodiment, each network operator registers a single identity manager in the database. In such a case, all attachment requests from users or user devices to the multiple network slices provided by a network operator is directed or sent to the single identity manager. It is, however, possible to register more than one identity manager for a given network operator in the database, in particular for a network operator handling a large amount of network attachment requests and where the management of such network attachment requests need to be distributed between multiple identity managers of the network operator. However, generally the number of identity managers and attachment entry points registered by a network operator is preferably lower than the total number of network slices that the network operator provides.
The registered information in the database is preferably provided to network nodes, such as eNBs, such as upon request from such network nodes. The network nodes may then announce or advertise the available network slices to user devices by transmitting the information of the registered attachment entry point to the user devices. This enables a user device to send the network attachment request to the correct entity, i.e. the identity manager, of the relevant network operator. In an alternative embodiment, the network node announces or advertises the network slices and/or operator, such as by announcing or advertising information of the registered network slice(s) and/or the network operator. In such a case, the user device transmits a network attachment request comprising information of a desired and selected network operator and/or network slice to the network node. The network node can then investigate the list or information obtained from the database to match the information of the selected network operator and/or network slice with the attachment entry point registered for that particular network operator. The network node then forwards and directs the network attachment request to this attachment entry point, i.e. identity manager, of the relevant network operator.
Thus, the identity information included in the network attachment request allows the identity manager to identify and determine which particular authentication method that should be used for the given user or user device. Different such authentication methods may use different types or formats of identity information.
Non-limiting but illustrative examples of such different authentication methods include Authentication, Authorization and Accounting (AAA) protocols. In such a case, the identity information could include username and password using an Extensible Authentication Protocol-Pre-Shared Key (EAP-PSK), certificates using EAP-Transport Layer Security (EAP-TLS), SIM credentials using EAP-SIM, EAP-Authentication and Key Agreement (EAP-AKA) or EAP-AKA Prime (EAP-AKA′).
Further EAP-based authentication solutions include EAP-MDS, EAP-Protected One-Time Password (EAP-POTP), EAP-Password (EAP-PWD), EAP-Tunneled Transport Layer Security (EAP-TTLS), EAP-Internet Key Exchange version 2 (EAP-IKEv2), EAP-Flexible Authentication via Secure Tunneling (EAP-FAST), EAP-Generic Token Card (EAP-GTC), EAP-Encrypted Key Exchange (EAP-EKE).
Other examples of authentication methods include OpenID-based authentication and MME authentication. Also authentication based on Facebook or Google identities are possible as illustrative examples.
Signaling involved in various authentication methods will be further described herein with reference to
Hence, in this embodiment the identity manager supports various authentication methods and can thereby handle network attachment requests from user devices having different types or formats of identity information.
In this implementation example, the identity manager authenticates an identity of the user device and/or the user based on the network attachment request and preferably based on the above described identity information included in the network attachment request. The identity manager further provides the user device profile of the user device with authenticated identity and/or a user profile of the user with authenticated identity. This provision could be performed according to various embodiments. In an embodiment, the identity manager has access to user device profiles and/or user profiles of user devices and/or users having a subscription with the network operator. The identity manager then simply retrieves the relevant user device profile and/or user profile based on the authenticated identity of the user device and/or user. In another embodiment, the identity manager requests the user device profile and/or user profile from another device or server, such as a Home Subscriber Server (HSS) or a User Profile Server Function (UPSF), using the authenticated identity of the user device and/or user. In a further embodiment, the user device profile and/or user profile is included in the network attachment request originating from the user device. The identity manager can then provide the user device profile and/or user profile by retrieving it from the network attachment request.
A user device profile lists capabilities of the user device. These capabilities are then matched with the respective requirements for the network slice types to see which network slice type or types that the user device can access. Thus, the user device is preferably only allowed to access a network slice type if the capabilities of the user device matches or exceeds the requirements for that network slice type.
Non-limiting but illustrative examples of such capabilities include capacity, latency, bandwidth, distribution, mobility, real-time requirements, reliability, security level, software/device version, location requirements, supported service(s), etc.
Correspondingly, a user profile comprises subscription data or information for the user. This subscription data can then be matched with a corresponding subscription or subscription data housed at the identity manager or at least accessible to the identity manager, such as from a HSS. The identity manager can then verify whether data in the user profile matches the subscription as required for accessing a network slice provided by the network operator.
In this embodiment, the user has multiple different user profiles. The particular user profile to use in step S33 of
Examples of different user profiles include high vs. low connectivity speed profiles, private user profile vs. work-related user profile, etc.
This means that in some cases the user might have several user profiles for a same network slice type and the network operator may have separate network slices for each user profile type. In those cases, the user device optionally sends profile information, such as in the form of a set of wished capabilities and/or service profile type, in, for instance, the network attachment request. The identity manager can then use that input, i.e. profile information, in the network slice selection.
Thus, in this embodiment, once the user device and/or user has been authenticated, the authorization step starts by providing and preferably transmitting, to the user device, information of an authorization entry point at the identity manager. This information in turns enables the user device to transmit an authorization request with the user device and/or user credentials to the identity manger to be used during the authorization.
The method then continues to step S2 of
This embodiment thereby enables the identity manager to distribute the processing of network attachment requests and authorization requests to different entry points or addresses of the identity manager.
In an alternative embodiment, step S40 is omitted. In this case, the same entry point at the identity manager to which the user device transmitted the network attachment request could be used when transmitting the authorization request. In a further variant, the credentials of the user device and/or user are included in the original network attachment request. In such an embodiment, step S2 of
This means that the user device only needs to transmit a single request in order to effectuate the authentication and authorization, i.e. no separate authorization request is needed.
In this embodiment, a service profile of the user is selected by the identity manager based on profile information originating from the user device. This profile information could, for instance, be included in an authorization request, the network attachment request or indeed in a separate message transmitted by the user device.
The service profile could, as illustrative examples, include information of device type, information of software version implemented in the user device, information of related services, information of capabilities, such as mentioned above in connection with user device profile, information of subscription type, etc.
In this embodiment, the identity manager does not necessarily have access to authorization credentials, which in clear contrast are stored at the authorization entity. This means that the identity manager forwards the credentials received from the user device, such as in the authorization request or the network attachment request, to the authorization entity, preferably together with an identifier of the relevant user device and/or user unless the credentials comprises such an identifier. The authentication entity can then retrieve the relevant authorization credentials, preferably based on the identifier of the user device and/or user, and verify whether the received credentials match or correspond to the retrieved authorization credentials. If they match, the authorization entity compiles and returns the authorization acceptance response to the identity manager. The identity manager then concludes that the user device and/or user has been correctly authorized.
The method then continues to step S3 in
A network node 7, represented by eNBs in the figure, queries the database 6 for information of the VNOs 4 available for user devices (UDs) 8 in step 2. The database 6 returns the registered information to the network node 7 in step 3. When a user device 8 tries to attach to a network, the network node 7 advertises a list of available VNOs 4 and corresponding VNO identities, or a list of available network slices 3 and corresponding VNO identities in step 4. This advertisement could be in the form of Master Information Block (MIB) and System Information Block (SIB) transmissions for mobile networks or SSID transmissions for WiFi networks. The user device 8 then selects one VNO 4 from the advertised list and transmits a network attachment request to the network node 7 in step 5. After receiving the network attachment request, the network node 7 matches the selected VNO identity with the registered entries and retrieves the attachment entry point for the selected VNO identity. The network node 7 then forwards, i.e. redirects in step 6, the network attachment request to the identity manager 1 registered as attachment entry point for the selected VNO 4 in the list at the database 6.
When the network attachment request is received by the identity manager 1, the identity manager 1 identifies the user device 8 and/or user and matches the user device and/or user identity and capability tags with the correlated network slice type, e.g. IoT device with IoT network slice type. In this case, the identity manager 1 has knowledge and capabilities to identify different UD types belonging to the same VNO 4. Please note that the network slice 4 that comprises the identity manager 1 can be of a different network slice type as compared to the network slice type selected for the user device 8, i.e. identity manager 1 present in a network slice of slice type 2, whereas the user device 1 should access an application 2 in a network slice of slice type 1.
The identity manager 1 responds back to the user device 7 with information of an authorization entry point and preferably a temporary identity of the user device 8 and/or user to be used during the network slice selection procedure. This response is sent to the network node 7 in step 7 and therefrom forwarded to the user device in step 8. In this embodiment, an authorization entry point is to an authorization function within an identity manager 1. Please note that the identity manager 1 with the authorization point may be the same or different from the identity manager that receives and handles network attachment requests, i.e. is registered in the database 6.
In a next step of the network slice selection procedure, see
When the identity manager 1 receives the authorization request, it preferably firstly selects a correlated network slice that belongs to the same VNO 4 and meets the user device requirements. User device capability requirements and preferred profile can be read from the user's subscription data and/or from the authorization request. That input is important for the cases when user can have multiple profiles for a same network slice type. Alternatively, the identity manager 1 performs this network slice selection and user device requirement verification following reception of the attachment request.
The identity manager 1 then selects an authorization function to be used when determining whether the user device 8 and user are allowed access to the selected network slice 3. Once the user device 8 and user are authorized, the identity manager 1 provides information of an entry point to an application 2 provided by the selected network slice 3. This information of application entry point is transmitted to the network node 7 in step 11 and further to the user device in step 12. An entry point here is an application entry or access point in the selected network slice 3. All the future user device related traffic is then redirected to the selected network slice 3 using the information of received application entry point in step 13.
In
In these figures, MTC slice denotes a network slice dedicated for machine type communication services and MBB slice denotes a network slice dedicated for mobile broadband services as illustrative examples of different types of services that can be provided in network slices.
A VNO or service provider may already have an IDM before the creation of network slices. Thus, the IDM can be deployed independently of and separate from any network slice, see
Since automation is one of the main characteristics of network slice, a VNO may spin off an IDM together with other slices. Thus, the IDM can be implemented within one its own network slice, see
Another deployment scenario is shown in
In the deployment scenario shown in
The authentication procedure and signaling is performed similar to the embodiment shown in
The initial registration as shown in
Depending on the access network that is used by the user device, the AAA backend in the identity manager may need to support RADIUS/DIAMETER protocols as well. This would be the case when the access is based on WiFi and a 802.11 access point that tunnels the EAP message between the user device and the AAA point (AP). This is shown in
The signaling involves transmission of a beacon from the AP to the user device. The user device returns an EAP over LTE (EAPoL) start. The AP sends an EAP request for the identity of the user device and/or user, whereby the user device returns an EAP response with the identity. The AP uses the identity to compile and transmit an attachment request to the identity manager using the RADIUS/DIAMETER protocol. The identity manager returns an attachment challenge using the RADIUS/DIAMETER protocol. The AP compiles, based on the attachment challenge, an EAP challenge that is sent to the user device. The authentication then continues based on the relevant EAP method, such as EAP-PSK, EAP-TLS, EAP-SIM, etc. Finally, the identity manager confirms that the attachment is accepted and transmits an attachment accept using the RADIUS/DIAMETER protocol to the AP, which forwards the attachment accept using EAP to the user device.
In some scenarios, the identity manager may not be able to authenticate the user device and/or user directly. This may be the case when the user is roaming and the authentication credentials reside in the home network. RADIUS and DIAMETER also allow the identity manager to proxy EAP messages inside RADIUS/DIAMETER to the correct authoritative server for that user. In this case, the identity manager only acts as a RADIUS/DIAMETER proxy that forwards messages based on the Network Access Identifier (NAI) of the user.
In addition, or alternatively, the identity manager may support MME authentication as is done in typical LTE networks. In such a case, when the identity manager receives a network attachment request originating from a user device, the following message exchanges may be performed during the authentication step.
An Authentication Information Request (AIR) is sent from identity manager, which hosts the MME functionality, to the HSS of the requesting user device. This AIR comprises username, i.e. identity of the user device and/or user, and visited PLMN-ID in addition to other Attribute Value Pairs (AVPs). These AVPs are used by HSS to generate authentication parameters. The HSS then responds with an Authentication Information Answer (AIA) comprising information, including an authentication token (AUTN), a random number (RAND) and an expected result (XRES), which will be used by the MME functionality to authenticate the user device and/or user. The identity manager then sends an authentication request containing the AUTN and the RAND to the user device. The user devices uses the RAND and generates an AUTN. If the AUTN received in the authentication request from the identity manager matches the one the user device generates, the user device has successfully authenticated the identity manager. The user device also generates a result (RES) with the RAND received from the identity manager and a secret key that it possess. The device transmits an authentication answer comprising the RES to the identity manager. The identity manager checks the RES received from the user device against the XRES received from the HSS. If the two matches, the identity manager has successfully authenticated the user device and/or user.
The above described authentication procedures should be seen as some typical examples. However, the flexible identity manager can support other forms of authentication methods, such as Web-based authentication with digest, etc.
The identity manager of the embodiments acts as an authentication and authorization entity for network operators, including VNOs and MVNOs, and also serves as the first contact point when a user device or user sends a network attachment request. In an embodiment, the process of authentication may be based on each user or user device having a unique set of credentials. Depending on the type of authentication method, the identity manager verifies the authentication credentials to ensure that only authorized users and their user devices are allowed any further access to the network. Following authentication, a user and/or user device profile is preferably retrieved to determine whether the user and/or device has authority to connect to a network slice provided by the network operator. Following the authentication and authorization, the identity manager provides information to the user device to direct future traffic to the correct network slice.
In order to support various kinds of user devices, the authentication methods supported by the identity manager may be expandable by either software upgrade or runtime plugin installation. The authentication methods can include, for instance, AAA, OpenID authentication and authentication methods used by MME among other possible authentication methods. In some deployment scenarios, the real logic to decide whether a user device and/or user may access the network is not inside the identity component. In such a case, the identity manager can be seen as an authorization proxy to the authorization logic, which might reside in an authorization entity or indeed in a network slice.
The identity manager of the embodiments is thereby used in a network slice selection to determine user device and/or user correlated network slices.
The identity manager acts as an authentication and authorization entity, and also serves as a network slice contact point when a user device sends a network attachment request via a network node, e.g. eNB. User device and/or user identification in the identity manager triggers selection of the network slice type capable of handling the identified user device and/or user. Following authentication in the identity manager, a user device and/or user profile is retrieved to determine the final network slice selection and whether the user device and/or user is authorized to connect to that network slice.
In some cases, the user might have several user profiles for a same type of network slice and the network operator can have a separate network slice for each user profile type. In such cases, the user can optionally send a set of wished capabilities or/and service profile type in the authentication request or in the network attachment request. The identity manager can use that input in the network slice selection procedure. An alternative, is to use only the user's subscription data, which may be preferred in the backward compatible cases.
In some deployment scenarios, the authorization logic to decide whether a user device and/or user may access a network or network slice could be outside of the identity manager. In this case, the identity manager can be seen as an authorization proxy to the authorization logic.
The identity manager that belongs to the selected network operator can preferably identify, authenticate and authorize all the user device types that might want to access the network sliced provided by the network operator. The network operator can have multiple network slices and each network slice can share a common identity manager, the identity manager functionality can be distributed among the network slices or each network slice can have a respective identity manager. The network operator can, independent on implementation variant for the identity manager, register a single identity manager in a selected network slice and thereby a single attachment entry point for all network slices and all user devices independently of user device and/or user identity types and authentication method used. After authentication, the identity manager selects a matching network slice and redirects all further application traffic for that user to the selected network slice.
This solution reduces the number of advertised network slices in the network and simplifies the network slice selection. This further means that different user device types with different authentication mechanisms can get authenticated and authorized in a single network slice point, i.e. the identity manager, and still attach to the correlated and selected network slice.
The proposed solution is expandable by either software upgrade or runtime plugin installation. For instance, when a new user device type is introduced, e.g. new identity type or/and related authentication mechanism, the identity manager can be upgraded to support that user device type. Also when a new network slice is introduced, the identity manager is updated to include the network slice in the network slice selection procedure.
The embodiments thereby introduce a new component called the identity manager related to the core networks and to the concept of network slicing of future core networks. Network slicing is an essential concept in the 5G core network.
By introducing the identity manager, a network operator, such as VNO or MVNO, can authenticate and authorize a user device and/or user connecting to a network. Based on the authentication and authorization information, the user device and/or user can be directed to the right network slice. No special requirements are put on the user devices, thus legacy user devices are also supported. This means that the embodiments are backwards compatible. The proposed identity manager is compatible with different kinds of attachment or access technologies, including cellular and WiFi as illustrative examples.
The network slice selection related to the user device attachment to the network is, in an embodiment, performed through two steps. In the first authentication or identification step, the user device and/or user is identified and correlated to the network slice type offered by the network operator. In the second, authorization step, the identity manager verifies that the user device and/or user is authorized to access the selected network slice. Following the authorization, the data traffic can be directed to the selected network slice.
No special requirements are put on the user devices, thus legacy user devices are also supported. The network operator can offer multiple network slices of the same network slice type for different user profiles. In that case, user device capability requirements or/and preferred user profile can be used to select appropriate network slice. That information can be read from the user subscription data or optionally it can be sent in the network attachment request.
The proposed solution enables reduction of total number of advertised network slices per network operator even down to a single network slice by using a single identity manager entry point for all the user devices and users independently on user device and/or user identity, user device type, authentication mechanism and user services. The proposed solution is compatible with a different kind of access technologies including cellular and WiFi as illustrative examples.
Another aspect of the embodiments relates to an identity manager. The identity manager is configured to authenticate a user device and/or a user of the user device based on a network attachment request originating from the user device to correlate the user device and/or the user to a network slice type of a network operator providing multiple network slices having a respective network slice type. The identity manager is also configured to authorize access to a network slice of the network slice type among the multiple network slices based on credentials of the user device and/or the user. The identity manager is further configured to provide, for transmission to the user device, information of an entry point to an application provided by the network slice.
In an embodiment, the identity manager is configured to register the identity manager as an attachment entry point for the multiple network slices of the network operator at a database of registered network slices.
In an embodiment, the identity manager is configured to select an authentication method among multiple authentication methods based on identity information retrieved from the network attachment request. The identity manager is also configured to authenticate the user device and/or the user based on the network attachment request and according to the selected authentication method.
In an embodiment, the identity manager is configured to authenticate an identity of the user device and/or the user based on the network attachment request. The identity manager is also configured to provide a user device profile of the user device and/or a user profile of the user based on the authenticated identity of the user device and/or the user. The identity manager is further configured to correlate the user device and/or the user to the network slice type by matching capabilities of the user device with respective requirements for the network slice types based on the user device profile and/or matching a subscription of the user with the network slice types based on the user profile.
In an embodiment, the identity manager is configured to select a user profile among multiple user profiles of the user based on profile information originating from the user device.
In an embodiment, the identity manager is configured to provide information of an authorization entry point at the identity manager for transmission to the user device following authentication of the user device and/or the user.
In a particular embodiment, the identity manager is configured to authorize access to the network slice based on the credentials received by the identity manager at the authorization entry point and originating from the user device.
In an embodiment, the identity manager is configured to authorize access to the network slice based on the credentials retrieved by the identity manager from the network attachment request.
In an embodiment, the identity manager is configured to select a service profile of the user based on profile information originating from the user device. The identity manager is also configured to authorize access to the network slice based on the credentials and the service profile.
In an embodiment, the identity manager is configured to forward the credentials to an authorization entity. The identity manager is also configured to authorize access to the network slice based on an authorization acceptance response from the authorization entity generated by matching the credentials with authorization credentials stored at the authorization entity.
It will be appreciated that the methods and arrangements described herein can be implemented, combined and re-arranged in a variety of ways.
For example, embodiments may be implemented in hardware, or in software for execution by suitable processing circuitry, or a combination thereof.
The steps, functions, procedures, modules and/or blocks described herein may be implemented in hardware using any conventional technology, such as discrete circuit or integrated circuit technology, including both general-purpose electronic circuitry and application-specific circuitry.
Alternatively, or as a complement, at least some of the steps, functions, procedures, modules and/or blocks described herein may be implemented in software such as a computer program for execution by suitable processing circuitry such as one or more processors or processing units.
Examples of processing circuitry includes, but is not limited to, one or more microprocessors, one or more Digital Signal Processors (DSPs), one or more Central Processing Units (CPUs), video acceleration hardware, and/or any suitable programmable logic circuitry such as one or more Field Programmable Gate Arrays (FPGAs), or one or more Programmable Logic Controllers (PLCs).
It should also be understood that it may be possible to re-use the general processing capabilities of any conventional device or unit in which the proposed technology is implemented. It may also be possible to re-use existing software, e.g. by reprogramming of the existing software or by adding new software components.
Optionally, the identity manager 100 may also include a communication circuit 103. The communication circuit 103 may include functions for wired and/or wireless communication with user devices and/or network nodes in the network. In a particular example, the communication circuit 103 may be based on radio circuitry for communication with one or more network nodes, including transmitting and/or receiving information. The communication circuit 103 may be interconnected to the processor 101 and/or memory 102. By way of example, the communication circuit 103 may include any of the following: a receiver, a transmitter, a transceiver, input/output (I/O) circuitry, input port(s) and/or output port(s).
The term ‘processor’ should be interpreted in a general sense as any system or device capable of executing program code or computer program instructions to perform a particular processing, determining or computing task.
The processing circuitry including one or more processors 310 is thus configured to perform, when executing the computer program 340, well-defined processing tasks such as those described herein.
The processing circuitry does not have to be dedicated to only execute the above-described steps, functions, procedure and/or blocks, but may also execute other tasks.
In a particular embodiment, the computer program 340 comprises instructions, which when executed by at least one processor 310, cause the at least one processor 310 to authenticate a user device and/or a user of the user device to correlate the user device and/or the user to a network slice type of a network operator providing multiple network slices having a respective network slice type. The at least one processor 310 is also caused to authorize access to a network slice of the network slice type among the multiple network slices based on credentials of the user device and/or the user. The at least one processor 310 is further caused to provide, for transmission to the user device, information of an entry point to an application provided by the network slice.
The proposed technology also provides a carrier 350 comprising the computer program 340, wherein the carrier 350 is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
By way of example, the software or computer program 340 may be realized as a computer program product 350, which is normally carried or stored on a computer-readable medium, in particular a non-volatile medium. Thus, the proposed technology further provides a computer-program product 350 comprising a computer-readable medium having stored thereon a computer program 340 as defined above.
The computer-readable medium may include one or more removable or non-removable memory devices including, but not limited to a Read-Only Memory (ROM), a Random Access Memory (RAM), a Compact Disc (CD), a Digital Versatile Disc (DVD), a Blu-ray disc, a Universal Serial Bus (USB) memory, a Hard Disk Drive (HDD) storage device, a flash memory, a magnetic tape, or any other conventional memory device. The computer program 340 may thus be loaded into the operating memory of a computer or equivalent processing device for execution by the processing circuitry 310 thereof.
The flow diagram or diagrams presented herein may be regarded as a computer flow diagram or diagrams, when performed by one or more processors. A corresponding identity manager may be defined as a group of function modules, where each step performed by the processor corresponds to a function module. In this case, the function modules are implemented as a computer program running on the processor.
The computer program residing in memory may thus be organized as appropriate function modules configured to perform, when executed by the processor, at least part of the steps and/or tasks described herein.
Alternatively it is possible to realize the modules in
It is becoming increasingly popular to provide computing services in network devices, such as network nodes and/or servers, where the resources are delivered as a service to remote locations over a network. By way of example, this means that functionality, as described herein, can be distributed or re-located to one or more separate physical nodes or servers. The functionality may be re-located or distributed to one or more jointly acting physical and/or virtual machines that can be positioned in separate physical node(s), i.e. in the so-called cloud. This is sometimes also referred to as cloud computing, which is a model for enabling ubiquitous on-demand network access to a pool of configurable computing resources such as networks, servers, storage, applications and general or customized services.
A network device 400 may generally be seen as an electronic device being communicatively connected to other electronic devices in the network. By way of example, the network device 400 may be implemented in hardware, software or a combination thereof. For example, the network device 400 may be a special-purpose network device or a general purpose network device, or a hybrid thereof.
A special-purpose network device may use custom processing circuits and a proprietary operating system (OS), for execution of software to provide one or more of the features or functions disclosed herein. A general purpose network device may use common off-the-shelf (COTS) processors and a standard OS, for execution of software configured to provide one or more of the features or functions disclosed herein. By way of example, a special-purpose network device may include hardware comprising processing or computing resource(s), which typically include a set of one or more processors, and physical network interfaces (NIs), which sometimes are called physical ports, as well as non-transitory machine readable storage media having stored thereon software. A physical NI may be seen as hardware in a network device through which a network connection is made, e.g. wirelessly through a wireless network interface controller (WNIC) or through plugging in a cable to a physical port connected to a network interface controller (NIC). During operation, the software may be executed by the hardware to instantiate a set of one or more software instance(s). Each of the software instance(s), and that part of the hardware that executes that software instance, may form a separate virtual network element.
By way of another example, a general purpose network device may for example include hardware comprising a set of one or more processor(s), often COTS processors, and network interface controller(s) (NICs), as well as non-transitory machine readable storage media having stored thereon software. During operation, the processor(s) executes the software to instantiate one or more sets of one or more applications. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization—for example represented by a virtualization layer and software containers. For example, one such alternative embodiment implements operating system-level virtualization, in which case the virtualization layer represents the kernel of an operating system or a shim executing on a base operating system that allows for the creation of multiple software containers that may each be used to execute one of a sets of applications. In an example embodiment, each of the software containers, also called virtualization engines, virtual private servers, or jails, is a user space instance, typically a virtual memory space. These user space instances may be separate from each other and separate from the kernel space in which the operating system is executed; the set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes. Another such alternative embodiment implements full virtualization, in which case: 1) the virtualization layer represents a hypervisor, sometimes referred to as a Virtual Machine Monitor (VMM), or the hypervisor is executed on top of a host operating system; and 2) the software containers each represent a tightly isolated form of software container called a virtual machine that is executed by the hypervisor and may include a guest operating system.
A hypervisor is the software/hardware that is responsible for creating and managing the various virtualized instances and in some cases the actual physical hardware. The hypervisor manages the underlying resources and presents them as virtualized instances. What the hypervisor virtualizes to appear as a single processor may actually comprise multiple separate processors. From the perspective of the operating system, the virtualized instances appear to be actual hardware components.
A virtual machine is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine; and applications generally do not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, though some systems provide para-virtualization which allows an operating system or application to be aware of the presence of virtualization for optimization purposes.
The instantiation of the one or more sets of one or more applications as well as the virtualization layer and software containers if implemented, are collectively referred to as software instance(s). Each set of applications, corresponding software container if implemented, and that part of the hardware that executes them (be it hardware dedicated to that execution and/or time slices of hardware temporally shared by software containers), forms a separate virtual network element(s).
The virtual network element(s) may perform similar functionality compared to Virtual Network Element(s) (VNEs). This virtualization of the hardware is sometimes referred to as Network Function Virtualization (NFV)). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which could be located in data centers, NDs, and Customer Premise Equipment (CPE). However, different embodiments may implement one or more of the software container(s) differently. For example, while embodiments are illustrated with each software container corresponding to a VNE, alternative embodiments may implement this correspondence or mapping between software container-VNE at a finer granularity level; it should be understood that the techniques described herein with reference to a correspondence of software containers to VNEs also apply to embodiments where such a finer level of granularity is used.
According to yet another embodiment, there is provided a hybrid network device, which includes both custom processing circuitry/proprietary OS and COTS processors/standard OS in a network device, e.g. in a card or circuit board within a network device ND. In certain embodiments of such a hybrid network device, a platform Virtual Machine (VM), such as a VM that implements functionality of a special-purpose network device, could provide for para-virtualization to the hardware present in the hybrid network device.
The identity manager of the embodiments can be implemented in a network node 7. The network node 7 may form part of the access network 430, the core network 440 or the OSS 450. Alternatively, the identity manager can be implemented in one or more, i.e. distributed implementation, network devices 400.
The embodiments described above are to be understood as a few illustrative examples of the present invention. It will be understood by those skilled in the art that various modifications, combinations and changes may be made to the embodiments without departing from the scope of the present invention. In particular, different part solutions in the different embodiments can be combined in other configurations, where technically possible. The scope of the present invention is, however, defined by the appended claims.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SE2015/051029 | 9/29/2015 | WO | 00 |
