SYSTEMS AND METHODS FOR NETWORK-BASED SLICE ACCESS AUTHORIZATION

A method may include receiving, by at least one network device and from a user device, a registration message including a service identifier and at least one of a network slice identifier or a network slice token. The method may also include determining, based on information included in the registration message, whether the user device is authorized to use a network slice associated with the service identifier. The method may further include setting up a data session to be serviced by the network slice, in response to determining that the user device is authorized to use the network slice.

BACKGROUND INFORMATION

The concept of network slices within Fifth Generation (5G) networks is one of the benefits of 5G. Slices may be associated with a particular Quality of Service (QoS). User devices typically need to be authorized to use network slices to avoid overloading the network slices with unauthorized data traffic. Despite authorization requirements, however, network slices are still vulnerable to unauthorized usage due to the security of the user device execution environment being compromised, fraud or other reasons.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Implementations described herein provide for network slice access authorization to avoid unauthorized network slice usage. In exemplary implementations, network elements in a core network associated with routing data traffic provide a user device initiated solution to authorizing network slice usage. For example, in one implementation, a user device requests and receives network slice information, which is later verified by the core network prior to setting up a data session serviced by the requested network slice. In another implementation, an application server may initiate the network slice authorization process by providing slice related information to a user device. The network slice authorization information may then be verified by core network elements prior to setting up a data session serviced by the requested slice. In each case, core network elements determine whether the user device is authorized to use a network slice to provide a unified approach to network slice authorization. In this manner, unauthorized network slice usage may be avoided.

FIG.1is a diagram illustrating an exemplary environment100in which systems and methods described herein may be implemented. Referring toFIG.1, environment100includes user equipment (UE) device110-1through110-N, access network120, wireless stations122-1through122-N, core network130, network devices140, data network150and application service provider160.

UE devices110-1and110-2(referred to herein individually as UE device or UE110, and collectively as UE devices or UEs110) may include any computing device, such as a personal computer (PC), a laptop computer, a server, a tablet computer, a notebook, a Chromebook®, a mobile device, such as wireless or cellular telephone device (e.g., a conventional cell phone with data processing capabilities), a smart phone, a personal digital assistant (PDA) that can include a radiotelephone, any type of mobile computer device or system, a game playing device, a music playing device, a home appliance device, a home monitoring device, a virtualized system, etc., that includes communication functionality. UE device110-1may connect to access network120via wireless station122-1and UE device110-N may connect to access network120via wireless station122-N. UE devices110may also connect to other devices in environment100via any conventional technique, such as wired, wireless, optical connections or a combination of these techniques. UE device110and the person associated with UE device110(e.g., the party holding or using UE device110) may be referred to collectively as UE device110or UE110in the description below.

Access network120may provide access to transport network130for wireless devices, such as UE devices110. Access network120may enable UE device110to connect to core network130for Internet access, non-Internet Protocol (IP) data delivery, cloud computing, mobile telephone service, Short Message Service (SMS) message service, Multimedia Message Service (MMS) message service, and/or other types of data services. Access network120may provide access to core network130, a service or application layer network, a cloud network, a multi-access edge computing (MEC) network, a fog network, etc. Furthermore, access network120may enable a device in core network130to exchange data with UE device110using a non-IP data delivery method such as Data over Non-Access Stratum (DoNAS).

Access network120may also include a 5G access network or another advanced network, such as a Fourth Generation (4G) Long Term Evolution (LTE) access network. Additionally, access network120may include functionality such as the functionality of a millimeter (mm) Wave Radio Access Network (RAN). Access network120may also include: support for advanced or massive multiple-input and multiple-output (MIMO) antenna configurations (e.g., an 8×8 antenna configuration, a 16×16 antenna configuration, a 256×256 antenna configuration, etc.); support for cooperative MIMO (CO-MIMO) configurations; support for carrier aggregation; relay stations; Heterogeneous Networks (HetNets) of overlapping small cells and macrocells; Self-Organizing Network (SON) functionality; machine type communication (MTC) functionality, such as 1.4 MHz wide enhanced MTC (eMTC) channels (also referred to as category Cat-M1), Low Power Wide Area (LPWA) technology such as Narrow Band (NB) IoT (NB-IoT) technology, and/or other types of MTC technology; and/or other types of 5G functionality.

Wireless stations122(referred to collectively as wireless stations122and individually as wireless station122) may be included in access network120. Each wireless station122may service a number of UE devices110and/or other user devices when the particular device is within radio frequency range of wireless station122. In one implementation, wireless station122may include 5G base station (e.g., a next generation NodeB (gNB)) that includes one or more radio frequency (RF) transceivers. For example, wireless station122may include three RF transceivers and each RF transceiver may service a 120 degree sector of a 360 degree field of view. Each RF transceiver may include or be coupled to an antenna array. The antenna array may include an array of controllable antenna elements configured to send and receive 5G new radio (NR) wireless signals via one or more antenna beams. In other implementations, wireless station122may also include a 4G base station (e.g., an evolved NodeB (eNodeB)) or a 6G base station that communicates wirelessly with UEs110located within the radio frequency range of wireless station122.

Core network130may include one or more wired, wireless and/or optical networks that are capable of receiving and transmitting data, voice and/or video signals. In an exemplary implementation, core network130may be associated with a telecommunications service provider (e.g., a service provider providing cellular wireless communication services and wired communication services) and may manage communication sessions of UE devices110connecting to core network130via access network120. Core network130may include one or multiple networks of different types and technologies. For example, core network130may be implemented to include a next generation core (NGC) network for a 5G network, an Evolved Packet Core (EPC) of an LTE or LTE Advanced network, a sixth generation (6G) network, and/or a legacy core network. Core network130may provide packet-switched services and wireless IP connectivity to various components in environment100, such as UE devices110, to provide, for example, data, voice, and/or multimedia services.

Core network130may include various network devices140. Depending on the implementation, network devices140may include 5G core network components (e.g., a User Plane Function (UPF), an Access and Mobility Management Function (AMF), a Network Exposure Function (NEF), a Session Management Function (SMF), a Unified Data Management (UDM) function, a Unified Data Repository (UDR), a Policy Control Function (PCF), a Charging Function (CHF), etc.), 4G core network components (e.g., a Serving Gateway (SGW), a Packet data network Gateway (PGW), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), a Policy Charging and Rules Function (PCRF) etc.), or another type of core network components (e.g., future 6G network components). In other implementation, network devices140may include combined 4G and 5G functionality, such as a session management function with PGW-control plane (SMF+PGW-C) and a user plane function with PGW-user plane (UPF+PGW-U).

Data network150may include, for example, a packet data network. In an exemplary implementation, UE device110may connect to data network150via core network130. Data network150may also include and/or be connected to a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an autonomous system (AS) on the Internet, an optical network, a cable television network, a satellite network, a wireless network, an ad hoc network, a telephone network (e.g., the Public Switched Telephone Network (PSTN) or a cellular network), an intranet, or a combination of networks.

Application service provider160may include one or more computer devices and/or servers that store applications (referred to herein as “apps”) and provide the applications and services associated with the applications to users, such as UE devices110. For example, application service provider160may provide a particular application accessed by UE device110via core network130. In some implementations, application service provider160may also provide network slice tokens to UE devices110, as described in detail below.

The exemplary configuration illustrated inFIG.1is provided for simplicity. It should be understood that a typical environment may include more or fewer devices than illustrated inFIG.1. For example, environment100may include a large number (e.g., thousands or more) of UE devices110and wireless stations122, as well as multiple access networks120that connect UE devices110to core network130. Environment100may also include elements, such as gateways, monitoring devices, network elements/functions, etc. (not shown), that aid in providing data services and routing data in environment100.

Various functions are described below as being performed by particular components in environment100. In other implementations, various functions described as being performed by one device may be performed by another device or multiple other devices, and/or various functions described as being performed by multiple devices may be combined and performed by a single device.

FIG.2illustrates a portion of environment100, including elements implemented in core network130in accordance with an exemplary implementation. Referring toFIG.2, network devices140in core network130include AMF142, SMF143, UPF144, NSSF145, NEF146, UDM/UDR147and PCF148. It should be understood that core network130may include other elements and/or differently arranged elements. Environment100also includes application repository210, operational support system (OSS)220and authorization device230.

As illustrated inFIG.2, UE device110-1may connect to core network130via wireless station122, shown inFIG.2as gNB122. Application service provider160may also connect to elements in core network130, such as UPF144and NEF146.

Application repository210may store applications accessed and provided to UE devices110. For example, application repository210may correspond to an “app store” via which users access applications. In some implementations, application repository210may store applications provided by application service provider160. In an exemplary implementation, application repository210may store an application identifier (ID) and a corresponding service ID for each application. OSS220may provide services associated with applications stored in application repository210. For example, in one implementation, OSS210may generate application IDs and service IDs for each application in application repository210and provide this information for storage in application repository210.

Authorization device230may include a computing device or server that generates tokens or other authorization information for use in authorizing access to a network slice, as described in detail below. For example, in one implementation, authorization device230may correspond to an OAuth 2.0 authorization server that generates tokens for use by user devices110executing particular applications to access network slices during data sessions. Authorization device230and/or other devices in, for example, core network130may validate the token using, for example, a public key or other authentication mechanism to determine whether the token is valid.

AMF142may perform registration management, connection management, reachability management, mobility management, lawful intercepts, Short Message Service (SMS) transport, transport of session management messages between UE device110and other network devices, such as SMF143, access authentication and authorization, location services management, functionality to support non-3GPP access networks, and/or other types of management processes. In an exemplary implementation, AMF142may perform slice access authorization, as described in detail below.

UPF144may maintain an anchor point for intra/inter-RAT mobility, maintain an external Packet Data Unit (PDU) point of interconnect to a particular data network (e.g., data network150), perform packet routing and forwarding, perform the user plane part of policy rule enforcement, perform packet inspection, perform lawful intercept, perform traffic usage reporting, perform QoS handling in the user plane, perform uplink traffic verification, perform transport level packet marking, perform downlink packet buffering, forward an “end marker” to a RAN node (e.g., gNB122), and/or perform other types of user plane processes.

SMF143may perform session establishment, session modification, and/or session release, perform IP address allocation and management, perform Dynamic Host Configuration Protocol (DHCP) functions, perform selection and control of UPF144, configure traffic steering at UPF144to guide the traffic to the correct destinations, terminate interfaces toward PCF148, perform lawful intercepts, charge data collection, support charging interfaces, control and coordinate of charging data collection, terminate session management parts of Non-Access Stratum (NAS) messages, perform downlink data notification, manage roaming functionality, and/or perform other types of control plane processes for managing user plane data.

NSSF145may select a set of network slice instances to serve a particular UE device110, determine network slice selection assistance information (NSSAI) or a Single-NSSAI (S-NSSA), determine a particular AMF142to serve a particular UE device110, and/or perform other types of processing associated with network slice selection or management.

NEF146may expose capabilities and events to other network functions (NFs), including third party NFs, application functions (AFs), edge computing NFs, and/or other types of NFs. Furthermore, NEF146may secure provisioning of information from external applications to core network130, translate information between core network130and devices/networks external to core network130, support a Packet Flow Description (PFD) function, and/or perform other types of network exposure functions. In an exemplary implementation, NEF146may store information regarding network slice access and perform network slice access authorization checking, as described in detail below.

UDM/UDR147may maintain subscription information for UE devices110, manage subscriptions, generate authentication credentials, handle user identification, perform access authorization based on subscription data, perform network function registration management, maintain service and/or session continuity by maintaining assignment of SMF143for ongoing sessions, support SMS delivery, support lawful intercept functionality, and/or perform other processes associated with managing user data.

PCF148may support policies to control network behavior, provide policy rules to control plane functions (e.g., to SMF143), access subscription information relevant to policy decisions, render policy decisions, and/or perform other types of processes associated with policy enforcement.

Environment100illustrated inFIG.2may include additional elements and/or NFs that are not illustrated. It should also be understood that functions described as being performed by various elements inFIG.2, including elements in core network130, may be performed by other elements/functions in other implementations.

FIG.3illustrates an exemplary configuration of a device300. One or more devices300may correspond to or be included in devices in environment100, such as UE device110, wireless station122, network devices140, such as AMF142, SMF143, UPF144, NSSF145, NEF146, UDM/UDR147, PCF148, application service provider160, application repository210, OSS220, authorization device230and other devices included in environment100. Referring toFIG.3, device300may include bus310, processor320, memory330, input device340, output device350and communication interface360. The exemplary configuration illustrated inFIG.3is provided for simplicity. It should be understood that device300may include more or fewer components than illustrated inFIG.3. Processor320may include one or more processors, microprocessors, or processing logic that may interpret and execute instructions. Memory330may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor320. Memory330may also include a read only memory (ROM) device or another type of static storage device that may store static information and instructions for use by processor320. Memory330may further include a solid state drive (SSD). Memory330may also include a magnetic and/or optical recording medium (e.g., a hard disk) and its corresponding drive.

Input device340may include a mechanism that permits a user to input information, such as a keypad, a keyboard, a mouse, a pen, a microphone, a touch screen, voice recognition and/or biometric mechanisms, etc. Output device350may include a mechanism that outputs information to the user, including a display (e.g., a liquid crystal display (LCD)), a speaker, etc. In some implementations, device300may include a touch screen display may act as both an input device240and an output device350.

Communication interface360may include one or more transceivers that device300uses to communicate with other devices via wired, wireless or optical mechanisms. For example, communication interface360may include one or more radio frequency (RF) transmitters, receivers and/or transceivers and one or more antennas for transmitting and receiving RF data. Communication interface360may also include a modem or an Ethernet interface to a LAN or other mechanisms for communicating with elements in a network.

In an exemplary implementation, device300performs operations in response to processor320executing sequences of instructions contained in a computer-readable medium, such as memory330. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into memory330from another computer-readable medium (e.g., a hard disk drive (HDD), solid state drive (SSD), etc.), or from another device via communication interface360. Alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the implementations described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

FIG.4is a flow diagram illustrating processing associated with network slice access authorization in accordance with an exemplary implementation.FIG.5is a signal flow diagram illustrating exemplary signal flows associated with the processing ofFIG.4. Processing may begin with an application being stored in application repository210. For example, OSS220or another device in environment100may approve an application for storage in application repository210. OSS220may assign an application identifier (ID) to the application and a service ID to the application (block410). OSS220may assign the service ID to applications stored in app repository210to effectively tie particular classes of applications to particular service categories. The service categories may then be assigned to network slices. When a UE110accesses applications stored in app repository210, the UE110receives the application ID and service ID and uses this information for network slice access authorization, as described in detail below.

For example, OSS220may assign a particular service ID to gaming applications, assign another service ID to industrial Internet of Things (HOT) applications, such as an application associated with ultra reliable low latency communications (URLLC), assign still another service ID to business related applications, etc. In this case, assume that the application is a video game. OSS220may assign an application ID, such as Game X to the application, and a Service ID, such as Game Network Slice (NS)-1 to the application, indicating that Game X can be serviced with NS1. OSS220may forward the application ID and service ID to NEF146(block410;FIG.5,510).

NEF146receives the application information for Game X and registers the application by storing the application ID and service ID in a database within NEF146(block420;FIG.5,520). For example,FIG.6illustrates an exemplary database600included in NEF146. In alternative implementations, database600may be located externally from NEF146(e.g., in AMF142, SMF143, NSSF145, etc.) and accessible by NEF146, AMF142, SMF143, NSSF145, etc. Referring toFIG.6, database600includes a UE ID field610, a Network Slice ID field612, a Service ID field614, an Application ID field616, a Session ID field618and a token field620.

As illustrated in row600-1of table600, NEF146may store a service ID of GameNS-1 in field614and an application ID of Game X in field616. NEF146may also access NSSF145to obtain a network slice ID, such as network slice selection assistance information (NSSAI), that identifies a particular slice for servicing a session associated with UE110-1executing Game X. In this example, NSSF145may identify network slice selection assistance information (NSSAI) that uniquely identifies a particular slice, such as NSSAI-1. NSSF145may forward this information to NEF146for storage in database600(e.g., in NS ID field612in row600-1, as illustrated inFIG.6). NEF146may also optionally store an access token and/or information identifying an access token for NSSAI-1, such as information identifying token 1 (T1) in token field620of row600-1, as also illustrated inFIG.6(block420). The token, if used, provides additional security with respect to ensuring a UE110is authorized to use a particular network slice, as described in detail below.

As also illustrated in row600-2of table600, a NS ID, service ID may be stored for another application, accessed by another UE110. For example, a UE110identified with UE ID999may be associated with an IIOT application Y (stored in app ID field616of row600-2) and having a service ID of URLLC Network Slice (stored in service ID field614). As illustrated, different applications have different service IDs, NS IDs, use different tokens, etc.

Assume that a user at UE110-1wishes to play Game X. In an exemplary implementation, UE110-1may access Game X from application repository210or from storage within UE110-1if Game X has already been downloaded by the user at UE110-1. In either case, when Game X is executed/launched, UE110-1may transmit a request for a network slice access token to NEF146(FIG.5,530). NEF146receives the request for the slice access token (block430). NEF146may then identify the particular UE110-1based on a UE ID included in the request, the application ID (i.e., Game X) and/or the service ID (GameNS-1) and obtain the access token associated with Game X and the corresponding service ID (block532).

For example, NEF146may access database600and identify the access token for Game X in row600-1, field620. In this example, the access token is T1. As described previously, NEF146may obtain network slice selection assistance information (NSSAI) from NSSF145and obtain an access token corresponding to the NS ID provided by NSSF145. For example, NEF146may obtain a slice access token for the particular application from authorization device230. In other implementations, the token T1 generated by authorization device230may be previously stored in database600. In either case, NEF146may provide the network slice access token T1 to UE110-1(block430;FIG.5,540). UE110-1receives the network slice access token.

Assume that UE110-1initiates a registration service request associated with a session for playing Game X. For example, UE110-1may transmit a registration request message that includes a UE ID associated with UE110-1, an Application ID, a Service ID, an NSSAI, and/or the access token received from NEF146, as well as other information, such as a data network name (DNN) associated with the request (FIG.5,550). AMF142may receive the registration request message from UE110-1(block440). AMF142may then determine whether UE110-1is authorized to access the particular requested network slice based on the UE ID, Service ID, NSSAI and/or token included in the registration message (block450).

For example, NEF146may determine whether the UE ID, NS ID, Service ID, App ID and/or token provided in the registration message correspond to the information stored in database600for the particular UE110-1and service ID. For example, AMF142may signal NEF146to determine whether the UE ID included in the registration message identifies a UE110that is authorized to use the particular slice identified by the service ID and NSSAI included in the registration message based on performing a lookup in database600. NEF146may also signal authorization device230to validate the token included in the registration message.

Assume that NEF146determines that the information in the registration request message matches the information stored in database600and NEF146/authorization device230determines that the token is valid. In this case, NEF determines that UE110-1is authorized to use the particular network slice identified in the registration message and/or associated with the provided token (block450—yes).

NEF146may signal AMF142that UE110-1is authorized to use the network slice (FIG.5,570). AMF142and/or NEF146may then signal SMF143to initiate a PDU session for UE110-1with the particular network slice (i.e., NSSAI-1) servicing the PDU session (block460;FIG.5,580). SMF143may provide PDU session information to UE110-1, and SMF143may then establish the PDU session using the particular network slice (block470;FIG.5,590).

Referring back to block450, if AMF142/NEF146determines that UE110-1is not authorized to use the requested network slice for executing Game X (block450—no), NEF146may signal SMF143to initiate a PDU session for UE device110-1, but without using the resources corresponding to the particular network slice (block480). For example, if the service ID and/or NS ID included in the registration message do not match the information stored in database600and/or the access token is not validated, this may indicate that a UE110is attempting to access a network slice for which UE is not authorized. In this case, SMF143may provide a PDU session for UE110-1, but without using resources associated with the requested network slice. In alternative implementations, SMF143may not establish a PDU session when UE110-1is attempting to access a network slice for which UE110-1is not authorized, and SMF143may send an alert to, for example, OSS220.

In this manner, elements in core network130may determine whether a UE110is authorized to use a network slice, prior to initiating a PDU session. This may help prevent network slices from becoming overloaded by unauthorized data traffic.

As described above with respect toFIGS.4and5, in one implementation, a UE110may initiate a request for network slice authorization and obtain network slice information with respect to particular applications executed by UE110. In other implementations, other devices may initiate the provisioning of network slice authorization information to UEs110, such as an application service provider/server, as described in detail below.

FIG.7is a flow diagram illustrating processing associated with network slice access authorization in accordance with another exemplary implementation. Processing may begin in a similar manner as described above with respect toFIGS.4and5. For example, OSS220or another device in environment100may approve an application for storage in application repository210. OSS220may assign an application ID to the application and a service ID to the application (block710). The service categories may be assigned to network slices.

For example, OSS220may assign a particular service ID to gaming applications, assign another service ID to IIOT applications, assign still another service ID to business related applications, etc. Similar to the implementation described above, assume that the application is a video game. OSS220may assign an application ID of Game X to the application, and a Service ID of Game NS-1 to the application, indicating that Game X can be serviced with NS1. OSS220may forward the application ID and service ID to NEF146(block710).

NEF146receives the application information for Game X and registers the application by storing the application ID and service ID database600(block720). NEF146may also access NSSF145to obtain a network slice ID, such as NSSAI that identifies a particular slice for servicing a session associated with UE110-1executing Game X, such as NSSAI-1. NEF146may obtain a network slice access token for the particular application from authorization device230. NEF146may also store the access token or information identifying the access token for NSSAI-1, such as information identifying token 1 (T1) in database600(block720).

In this implementation, NEF146may forward the access token and/or information identifying the token to application service provider160. Application service provider160may then push the token associated with GameNS-1 to UE device110-1(block730). In an exemplary implementation, NEF146may also provide the token to other elements in core network130, such as PCF148, via, for example, UE route selection policy (URSP) signaling. In each case, application service provider160initiates the process associated with providing a network slice authorization token to UE110-1. That is, the token is sent to UE110-1without UE110-1requesting the token.

Assume that a user at UE110-1wishes to play Game X. As described previously, UE110-1may access Game X from application repository210or from storage within UE110-1if Game X has already been downloaded by the user at UE110-1. In either case, UE110-1may initiate a registration service request associated with a session for playing Game X. For example, UE110-1may transmit a registration request message that includes a UE ID associated with UE110-1, an Application ID, a Service ID, an NSSAI, and/or the access token received from application service provider160, as well as other information, such as DNN associated with the request. AMF142may receive the registration request message from UE110-1(block740). AMF142may then determine whether UE110-1is authorized to access the particular requested network slice corresponding to the NSSAI and token included in the registration message (block750).

For example, as described above with respect toFIGS.4and5, NEF146may determine whether the UE ID, NS ID, Service ID, App ID provided in the registration message correspond to the information stored in database600for the particular UE110-1. For example, AMF142may signal NEF146to determine whether the UE identified by the UE ID included in the registration message is authorized to use the particular slice identified by the service ID, NSSAI included in the registration message. NEF146may also signal authorization device230to validate the token included in the registration message.

Assume that NEF146determines that the information in the registration request matches the information stored in database600for the particular Service ID and app ID and that the token is valid. In this case, NEF determines that UE110-1is authorized to use the particular network slice identified in the registration message and/or associated with the access token (block750—yes).

NEF146may signal AMF142that UE110-1is authorized to use the network slice. AMF142and/or NEF146may then signal SMF143to initiate a PDU session for UE110-1with the particular network slice (i.e., NSSAI-1) servicing the PDU session (block760). SMF143may provide PDU session information to UE110-1and SMF143may then service the PDU session using the particular network slice (block770).

Referring back to block750, if AMF142/NEF146determines that UE110-1is not authorized to use the requested network slice for executing Game X (block750—no), NEF146may signal SMF143to initiate a PDU session for UE device110-1, but without using the resources corresponding to the particular network slice (block780). For example, if the NS ID included in the registration message does not match the information stored in database600and/or the token is not validated, this may indicate that a UE110is attempting to access a network slice for which UE110is not authorized. In such cases, SMF143may establish the PDU session, but not service the PDU session with the requested network slice. In other implementations, SMF143may not set up the PDU session for UE110-1when UE110is attempting to access a network slice for which UE110is not authorized.

Implementations described herein provide for network slice access authorization performed by elements in a core network. For example, implementations described herein provide for network-based network slice authorization prior to setting up a data session. This may allow a service provider to ensure that the use of network slices is limited to authorized users.

For example, features have been described above with respect to providing network slice authorization using elements in core network130. In other implementations, similar processing may be performed in other portions of environment100, such as in a Multi-access Edge Computing (MEC) platform located, for example, between access network120and core network130.

Further, while series of acts have been described with respect toFIGS.4and7and signal flows with respect toFIG.5, the order of the acts and signal flows may be different in other implementations. Moreover, non-dependent acts may be implemented in parallel.

It will be apparent that various features described above may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement the various features is not limiting. Thus, the operation and behavior of the features were described without reference to the specific software code—it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the various features based on the description herein.

Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include hardware, such as one or more processors, microprocessor, application specific integrated circuits, field programmable gate arrays or other processing logic, software, or a combination of hardware and software.