Patent Publication Number: US-11659481-B2

Title: Methods and systems for UE to request appropriate NSSAI in 5G

Description:
This application is a 35 U.S.C. § 371 national phase filing of International Application No. PCT/IB2018/053763, filed May 26, 2018, the disclosure of which is incorporated herein by reference in its entirety. 
     TECHNICAL FIELD 
     The present disclosure relates to User Equipment (UE) operating within a Fifth Generation (5G) network or other network that supports network slices, where a UE can be any device containing a 5G Modem, such as, but not limited to, a smart phone, a fixed wireless access Customer Premise Equipment (CPE), Vehicles Connectivity Systems, Robots/Machines connectivity Systems, Connected Goggles, Unmanned Aerial Vehicles (UAVs)/Drones, Airplanes Connectivity Systems, etc. 
     BACKGROUND 
     Network slicing is a key Fifth Generation (5G) network concept introduced to model and realize specific and dedicated connectivity services over network service provider networks. 5G introduces a Network Slice Selection Function (NSSF), which assists in selecting a network slice. 5G also introduces the concept of Network Slice Selection Assistance Information (NSSAI) to assist slice selection. The NSSAI consists of a list of Single NSSAIs (S-NSSAIs). A network, such as a Public Land Mobile Network (PLMN), combines different 5G core network elements to deliver much more flexible types of network slices (i.e., NSSAIs), and these network slices can be delivered in real time based on S-NSSAIs values provided in the N1 interface. 
       FIG.  1    illustrates a conventional 5G telecommunications network  100  in which a UE  102  is operating. In the embodiment illustrated in  FIG.  1   , network  100  includes a Radio Access Node/Access Node ((R)AN)  104 , a User Plane Function (UPF)  106 , a Core Access and Mobility Management Function (AMF)  108 , a Session Management Function (SMF),  110 , a Policy Control Function (PCF)  112 , an Application Function (AF)  114 , a NSSF  116 , a Authentication Server Function (AUSF)  118 , a Unified Data Management function (UDM)  120 , and a Network Exposure Function (NEF)  122 . In  FIG.  1   , some of the standard interfaces are labeled, e.g., “N1,” “N2,” etc. The network  100  shown in  FIG.  1    is illustrative and not limiting, i.e., the enhanced UE  102  disclosed herein may operate in telecommunication networks having other nodes or combinations of nodes. It should be noted that, as used herein, the term “(R)AN” refers to an entity that may be Radio Access Network, a (non-radio) Access Network, or a combination of the two. Hereinafter, the terms “RAN” and “(R)AN” will be used synonymously, except where “RAN” is explicitly indicated as referring to a Radio Access Network exclusively. 
     Prior to 5G, there was no network slice or NSSAI. The closest thing conceptually was a Quality of Service (QoS) Class Identifier (QCI), which allowed the network to predefine some network elements characteristics, i.e., QoS, depending on the type of service being requested by the UE. This pre-5G mechanism differs from network slices, however, in that a UE was limited to a single network slice and a UE was not allowed to have multiple network slices for each Protocol Data Unit (PDU) session. 
     In contrast, 5G network slicing allows simultaneous connectivity to multiple network slices per UE (and the multiple network slices are not constrained to all occupy the same physical path), extends network slice awareness out to the RAN (that is, 5G network slices are “end-to-end”), and enhances the possibilities to provide isolation between network slices. A UE may be associated with at most eight different S-NSSAIs in total, and the AMF instance serving the UE logically belongs to each of the network slice instances serving the UE, e.g., the AMF instance is common to the network slice instances serving the UE. 
     The PLMN combines different 5G core network functions to deliver much more flexible type of network slices (NSSAIs), and these network slices can be delivered in real time based the information provided by the UE in the N1 interface during the registration procedure. The NSSAI may be a Configured NSSAI, a Requested NSSAI or an Allowed NSSAI. During the registration process the AMF will consult the NSSF, based on the UE request, and so authorize or not the NSSAIs associated with the information coming from UE. 
       FIG.  2    is a signaling message diagram illustrating a portion of a conventional process by which a UE  102  establishes a PDU Session with a Data Network (DN)  200 . The process starts when the UE  102  sends a PDU Session Establishment request (message  202 ) to the AMF  108 , which selects an SMF (step  204 ), and sends to the SMF  110  a request for creation of a PDU Session Context (step  206 ). The SMF  110  communicates with the UDM  120  for the purpose of registration and subscription retrieval (step  208 ), after which the UE  102  performs PDU Session authentication and authorization (step  210 ) with the DN  200 . At some point, the UE  102  may request that the existing PDU Session be modified (message  212 ), which triggers the AMF  108  to send to the SMF  110  a request to update the PDU Session Context (message  214 ), causing the SMF to communicate with the UDM  120  for the purpose of updating the subscription(s) (step  216 ).  FIG.  2    illustrates the point that, in conventional 5G networks, the network slice awareness extends only to the RAN  104 . 
     SUMMARY 
     Methods and systems for exposing the network slice selection process to the entities within or attached to a User Equipment (UE) are provided. In some embodiments, the network slice selection process is accessible via one or more Application Programming Interfaces (APIs) within the UE. 
     According to one aspect of the present disclosure, a method for allowing slice consumers within or attached to a client device operating in a telecommunications network to access and use Network Slice Selection Assistance Information (NSSAI) comprises: at the client device: receiving, at an Application Programming Interface (API) layer within the client device, a query for NSSAI, the query being sent by a slice consumer; sending, to a Fifth Generation (5G) modem within the client device, the query for NSSAI; receiving, from the 5G modem, a response to the query for NSSAI; and sending, to the slice consumer, the response to the query for NSSAI. 
     In some embodiments, upon receiving the query for NSSAI, the API layer determines whether the query for NSSAI is allowed and sending the query for NSSAI to the 5G modem only when the query for NSSAI is allowed. 
     In some embodiments, receiving the query for NSSAI comprises receiving the query from a native slice consumer within the client device and wherein sending the response to the query for NSSAI comprises sending a response to the native slice consumer. 
     In some embodiments, the native slice consumer comprises a browser or a native application. 
     In some embodiments, receiving the query for NSSAI comprises receiving the query from an external slice consumer attached to the client device and wherein sending the response to the query for NSSAI comprises sending the response to the external slice consumer. 
     In some embodiments, receiving the query from the external slice consumer attached to the client device comprises receiving the query via a wired interface or a wireless interface of the UE and wherein sending the response to the external slice consumer comprises sending the response via the wired interface or the wireless interface of the UE. 
     In some embodiments the method further comprises, in response the receiving the query for NSSAI, fetching, by the 5G modem and from a Core Access and Mobility Management Function (AMF), a list of Single NSSAIs (S-NSSAIs) available for the UE from the AMF, wherein sending the response to the query for the NSSAI comprises sending the list of S-NSSAI(s) available for the UE received from the AMF. 
     In some embodiments, fetching the list of S-NSSAI(s) from the AMF comprises: sending, to the AMF, a request for a list of S-NSSAIs available from the network; and receiving, from the AMF, the list of S-NSSAIs available from the network. 
     In some embodiments, the method further comprises, at the API layer: receiving, from the slice consumer information identifying at least one S-NSSAI; and sending, to the 5G modem, the information identifying the at least one S-NSSAI. 
     In some embodiments, receiving the information identifying the at least one S-NSSAI comprises receiving the information identifying the at least one S-NSSAI from a native slice consumer. 
     In some embodiments, receiving the information identifying the at least one S-NSSAI from a native slice consumer comprises receiving the information from a browser or a native application. 
     In some embodiments, receiving the information identifying the at least one S-NSSAI comprises receiving the information identifying the at least one S-NSSAI from the external slice consumer. 
     In some embodiments, receiving the information identifying the at least one S-NSSAI from the external slice consumer comprises receiving the information identifying the at least one S-NSSAI via a wired interface or a wireless interface. 
     In some embodiments, the method further comprises, at the 5G modem: receiving the information identifying the at least one S-NSSAI; and sending, to the AMF an N1 interface signaling message. 
     In some embodiments, sending the N1 interface signaling message comprises sending the N1 interface signaling message comprising the information identifying the at least one S-NSSAI. 
     In some embodiments, sending the N1 interface signaling message comprises sending a Protocol Data Unit (PDU) Session Establishment Request. 
     In some embodiments, sending the N1 interface signaling message comprises sending a PDU Session Modification Request. 
     In some embodiments, sending the N1 interface signaling message comprises sending, to the AMF, a request involving a selected S-NSSAI. 
     In some embodiments, the method further comprises: receiving, from the AMF, a notification that the request was denied; and sending, to an AF a request to subscribe to the selected S-NSSAI. 
     In some embodiments, wherein receiving, from the AF, an indication that the request to subscribe to the selected S-NSSAI was approved. 
     In some embodiments, the method further comprises sending, to the AMF, a request involving the selected S-NSSAI and receiving, from the AMF, a notification that the request was allowed. 
     In some embodiments, the method further comprises: sending, from the slice consumer to the AF, a request for certification of the slice consumer by the network; and receiving, from the AF, a certificate for use by the slice consumer. 
     In some embodiments, the method further comprises, at the API layer: receiving, from the slice consumer a request to validate the certificate received by the AF; sending, to a Network Exposure Function (NEF), the request to validate the certificate; receiving, from the NEF, notification that the certificate is valid or invalid; and forwarding, to the slice consumer, the received notification that the certificate is valid or invalid. 
     In some embodiments, the method further comprises: at the AF: receiving, from a UE, the request for certification of the slice consumer by the network; sending, to a slice manager, the request for certification of the slice consumer; receiving, from the slice manager, a certificate for use by the slice consumer; and sending, to the UE, the certificate for use by the slice consumer. 
     In some embodiments, sending the request to the slice manager comprises sending the request to the slice manager via a NEF, and wherein receiving the certificate from the slice manager comprises receiving the certificate from the slice manager via the NEF. 
     In some embodiments, the AF comprises an Over-The-Top (OTT) backend server. 
     In some embodiments, the method further comprises: at the NEF: receiving, from the UE, the request to validate the certificate; sending, to the slice manager, the request to validate the certificate; receiving, from the slice manager, a notification that the certificate is valid or invalid; and sending, to the UE, the notification that the certificate is valid or invalid. 
     In some embodiments, the slice manager comprises a Unified Data Management (UDM), a Policy Control Function (PCF), a Network Slice Selection Function (NSSF), or a Home Subscriber Server (HSS). 
     According to another embodiment of the present disclosure, a client device for operating in a telecommunications network and that allows slice consumers within or attached to the client device to access and use NSSAI the client device comprising: a modem for communicating with the telecommunications network; an API layer for providing at least one API by which a network slice consumer may request network slice information or may perform network slice related network functions; one or more processors; and memory storing instructions executable by the one or more processors, whereby the client device is operable to: receive, at the API layer within the client device, a query for NSSAI, the query being sent by a slice consumer; send, to a 5G modem within the client device, the query for NSSAI; receive, from the 5G modem, a response to the query for NSSAI; and send, to the slice consumer, the response to the query for NSSAI. 
     In some embodiments, the modem for communicating with the telecommunications network comprises a modem for communicating on at least one of a 5G telecommunications network and a Long Term Evolution (LTE) telecommunications network. 
     In some embodiments, the client device comprises at least one native slice consumer within the client device. 
     In some embodiments, the at least one native slice consumer comprises a browser or a native application. 
     In some embodiments, the client device comprises an interface for supporting an external slice consumer. 
     In some embodiments, the interface for supporting the external slice consumer comprises a wired interface or a wireless interface by which the external slice consumer may communicate with the client device. 
     In some embodiments, the client device comprises a UE, a fixed wireless access Customer Premises Equipment (CPE), a smart phone, a vehicles connectivity system, a robots/machines connectivity system, connected goggles, Unmanned Aerial Vehicles (UAVs)/drones, airplanes connectivity systems, connected home appliance system, a connected entertainment system, or an Internet of Things (IoT) device. 
     In some embodiments, the client device is further operable to perform any of the client device methods described herein. 
     According to another aspect of the present disclosure, a client device for operating in a telecommunications network and that allows slice consumers within or attached to the client device to access and use NSSAI is adapted to: receive, at an API layer within the client device, a query for NSSAI, the query being sent by a slice consumer; send, to a 5G modem within the client device, the query for NSSAI; receive, from the 5G modem, a response to the query for NSSAI; and send, to the slice consumer, the response to the query for NSSAI. 
     In some embodiments, the client device is further adapted to perform any of the client device methods described herein. 
     According to another aspect of the present disclosure, a client device for operating in a telecommunications network and that allows slice consumers within or attached to the client device to access and use NSSAI comprises: means for receiving, at an API layer within the client device, a query for NSSAI, the query being sent by a slice consumer; means for sending, to a 5G modem within the client device, the query for NSSAI; means for receiving, from the 5G modem, a response to the query for NSSAI; and means for sending, to the slice consumer, the response to the query for NSSAI. 
     In some embodiments, the client device is further comprises means for performing any of the client device methods described herein. 
     According to another aspect of the present disclosure, a client device for operating in a telecommunications network and that allows slice consumers within or attached to the client device to access and use NSSAI the client device comprising one or more modules, the modules operable to: receive, at an API layer within the client device, a query for NSSAI, the query being sent by a slice consumer; send, to a 5G modem within the client device, the query for NSSAI; receive, from the 5G modem, a response to the query for NSSAI; and send, to the slice consumer, the response to the query for NSSAI. 
     In some embodiments, the one or more modules are further operable to perform any of the client device methods described herein. 
     According to another aspect of the present disclosure, a non-transitory computer readable medium storing software instructions that when executed by one or more processors of a client device that allows slice consumers within or attached to the client device to access and use NSSAI cause the client device to: receive, at an API layer within the client device, a query for NSSAI, the query being sent by a slice consumer; send, to a 5G modem within the client device, the query for NSSAI; receive, from the 5G modem, a response to the query for NSSAI; and send, to the slice consumer, the response to the query for NSSAI. 
     In some embodiments, the non-transitory computer readable medium stores software instructions that when executed by one or more processors of a client device further cause the client device to perform any of the client device methods described herein. 
     According to another aspect of the present disclosure, a computer program comprises instructions which, when executed by at least one processor, cause the at least one processor to carry out any of the client device methods described herein. 
     According to another aspect of the present disclosure, a method for allowing slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI the method comprising: at a AMF: receiving, from a client device, a first request involving network slices; and sending, to the client device, a response to the first request involving network slices. 
     In some embodiments, the method further comprises: in response to receiving the first request involving network slices, sending, to a slice manager, a second request involving network slices; receiving, from the slice manager, a response to the second request involving network slices; and sending the response to the first request involving network slices in response to receiving the response to the second request involving network slices from the slice manager. 
     In some embodiments, the first request comprises a request for a list of S-NSSAIs available to the client device from the network; the second request comprises a Nudm_SDM_Get Request for slice selection subscription data; the response to the second request comprises a list of S-NSSAIs available to the client device from the network; and the response to the first request comprises the list of S-NSSAIs available to the client device from the network. 
     In some embodiments, the first request comprises a request for a selected S-NSSAI; the second request comprises a query to determine if the selected S-NSSAI is allowed; the response to the second request comprises a notification that the selected S-NSSAI was allowed or not allowed; and the response to the first request comprises a notification that the first request was allowed or denied. 
     In some embodiments, the first request comprises a PDU Session Modification Request comprising information that identifies a S-NSSAI selected by the slice consumer within or connected to the client device. 
     According to another aspect of the present disclosure, an AMF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises: one or more processors; and memory storing instructions executable by the one or more processors, whereby the AMF is operable to perform any of the AMF methods described herein. 
     According to another aspect of the present disclosure, an AMF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI is adapted to perform any of the AMF methods described herein. 
     According to another aspect of the present disclosure, an AMF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises means for performing any of the AMF methods described herein. 
     According to another aspect of the present disclosure, an AMF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises one or more modules, the modules operable to perform any of the AMF methods described herein. 
     According to another aspect of the present disclosure, a non-transitory computer readable medium stores software instructions that when executed by one or more processors of a AMF cause the AMF perform any of the AMF methods described herein. 
     According to another aspect of the present disclosure, a computer program comprises instructions which, when executed by at least one processor, cause the at least one processor to carry out any of the AMF methods described herein. 
     According to another aspect of the present disclosure, a method for allowing slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises: at an AF: receiving, from a slice consumer within or connected to the client device, a first request involving network slices; and sending, to the client device, a response to the first request involving network slices. 
     In some embodiments, the first request comprises a request to subscribe to a selected S-NSSAI and wherein the method further comprises: sending, to a slice manager, the request to subscribe to the S-NSSAI; and receiving, from the slice manager, a response to the request to subscribe to the S-NSSAI; wherein the response to the first request comprises the response to the request to subscribe to the S-NSSAI. 
     In some embodiments, the first request comprises a request to certify the slice consumer with the network and wherein the method further comprises: sending, to the slice manager, the request to certify the slice consumer with the network; and receiving, from the slice manager, a response to the request to certify the slice consumer with the network; wherein the response to the first request comprises the response to the request to certify the slice consumer with the network. 
     In some embodiments, sending the request to certify the slice consumer with the network comprises sending the request to the slice manager via a NEF, and wherein receiving the response to the request to certify the slice consumer with the network comprises receiving the response from the slice manager via the NEF. 
     In some embodiments, the slice manager comprises a UDM node, a PCF, a NSSF, or a HSS. 
     In some embodiments, the AF comprises an OTT backend server. 
     According to another aspect of the present disclosure, an AF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises: one or more processors; and memory storing instructions executable by the one or more processors, whereby the AF is operable to perform any of the AF methods described herein. 
     According to another aspect of the present disclosure, an AF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI is adapted to perform any of the AF methods described herein. 
     According to another aspect of the present disclosure, an AF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises a means for performing any of the AF methods described herein. 
     According to another aspect of the present disclosure, an AF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises one or more modules, the modules operable to perform any of the AF methods described herein. 
     According to another aspect of the present disclosure, a non-transitory computer readable medium stores software instructions that when executed by one or more processors of an AF cause the AF to perform any of the AF methods described herein. 
     According to another aspect of the present disclosure, a computer program comprises instructions which, when executed by at least one processor, cause the at least one processor to carry out the method of the non-transitory computer readable medium described above. 
     According to another aspect of the present disclosure, a method for allowing slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises: at a NEF: receiving a first request involving network slices; and sending a response to the first request involving network slices. 
     In some embodiments, receiving a first request involving network slices comprises receiving, from an AF, a request to subscribe a slice consumer within or connected to a client device to a S-NSSAI and wherein the method further comprises: sending the request to subscribe the slice consumer to the S-NSSAI to a slice manager; and receiving, from the slice manager, a response to the request to subscribe the slice consumer to the S-NSSAI; wherein sending a response to the first request involving network slices comprises forwarding, to the AF, the response to the request to subscribe the slice consumer to the S-NSSAI. 
     In some embodiments, receiving the first request involving network slices comprises receiving, from an AF, a request for certification of a slice consumer by the network and wherein the method further comprises: sending the request for certification to a slice manager; and receiving, from the slice manager, a response to the request for certification; wherein sending the response to the first request involving network slices comprises sending, to the AF, the response to the request for certification. 
     In some embodiments, the response to request for certification comprises a certificate for use by the slice consumer and wherein sending the response to the request for certification comprises sending the certificate for use by the slice consumer to the AF. 
     In some embodiments, receiving a first request involving network slices comprises receiving, from an API layer, a request to validate a certificate for use by a slice consumer and wherein the method further comprises: sending the request to validate the certificate to a slice manager; and receiving, from the slice manager, a response to the request to validate the certificate; wherein sending the response to the first request involving network slices comprises sending, to the API layer, the response to the request to validate the certificate. 
     In some embodiments, the slice manager comprises a UDM node, a PCF, a NSSF, or a HSS. 
     According to another aspect of the present disclosure, a NEF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises: one or more processors; and memory storing instructions executable by the one or more processors, whereby the NEF is operable to perform any of the NEF methods described herein. 
     According to another aspect of the present disclosure, a NEF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI the NEF being adapted to perform any of the NEF methods described herein. 
     According to another aspect of the present disclosure, a NEF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises means for performing any of the NEF methods described herein. 
     According to another aspect of the present disclosure, a NEF that allows slice consumers within or attached to a client device operating in a telecommunications network to access and use NSSAI comprises one or more modules, the modules operable to perform any of the NEF methods described herein. 
     According to another aspect of the present disclosure, a non-transitory computer readable medium stores software instructions that when executed by one or more processors of a NEF causes the NEF to perform any of the NEF methods described herein. 
     According to another aspect of the present disclosure, a computer program comprises instructions which, when executed by at least one processor, cause the at least one processor to carry out any of the NEF methods described here. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure. 
         FIG.  1    illustrates a conventional Fifth Generation (5G) telecommunications network in which a User Equipment (UE) may operate; 
         FIG.  2    is a signaling message diagram illustrating a portion of a conventional process by which a UE establishes a Protocol Data Unit (PDU) Session with a Data Network (DN); 
         FIG.  3    illustrates an example of a User Equipment (UE) capable of requesting appropriate Network Slice Selection Assistance Information (NSSAI) from a 5G network according to some embodiments of the present disclosure; 
         FIG.  4    illustrates an example of signaling message by which a UE may query a Core Access and Mobility Management Function (AMF) for a list of Single NSSAI (S-NSSAI) values that are available to the UE from the network according to some embodiments of the present disclosure; 
         FIG.  5    illustrates an example of signaling messages by which an entity within the UE may request at least one Single NSSAI (S-NSSAI) according to some embodiments of the present disclosure; 
         FIG.  6    illustrates an example of signaling messages by which an entity external to the UE but connected to the UE may request at least one S-NSSAI according to some embodiments of the present disclosure; 
         FIG.  7    illustrates an example of signaling messages by which an slice consumer within or connected to the UE may establish or modify a PDU session of the UE according to some embodiments of the present disclosure; 
         FIG.  8    illustrates an example of a scenario in which a request for a slice is denied according to some embodiments of the present disclosure; 
         FIG.  9    illustrates an example in which a slice owner, such as an Over-The-Top provider, certifies a slice consumer and in which the slice consumer validates the certification with the network according to some embodiments of the present disclosure. 
         FIG.  10    illustrates an example of a cellular communications network according to some embodiments of the present disclosure; 
         FIG.  11    is a schematic block diagram of a radio access node according to some embodiments of the present disclosure; 
         FIG.  12    is a schematic block diagram that illustrates a virtualized embodiment of the radio access node of  FIG.  11    according to some embodiments of the present disclosure; 
         FIG.  13    is a schematic block diagram of the radio access node of  FIG.  11    according to some other embodiments of the present disclosure; 
         FIG.  14    is a schematic block diagram of a User Equipment device (UE) according to some embodiments of the present disclosure; 
         FIG.  15    is a schematic block diagram of the UE of  FIG.  14    according to some other embodiments of the present disclosure; 
         FIG.  16    illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments of the present disclosure; 
         FIG.  17    is a generalized block diagram of a host computer communicating via a base station with a UE over a partially wireless connection in accordance with some embodiments of the present disclosure; 
         FIG.  18    is a flowchart illustrating a method implemented in a communication system in accordance with some embodiments of the present disclosure; 
         FIG.  19    is a flowchart illustrating a method implemented in a communication system in accordance with some embodiments of the present disclosure; 
         FIG.  20    is a flowchart illustrating a method implemented in a communication system in accordance with some embodiments on the present disclosure; and 
         FIG.  21    is a flowchart illustrating a method implemented in a communication system in accordance with some embodiments of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. 
     Terms and Definitions 
     Radio Node: As used herein, a “radio node” is either a radio access node or a wireless device. 
     Radio Access Node: As used herein, a “radio access node” or “radio network node” is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node. 
     Core Network Node: As used herein, a “core network node” is any type of node in a core network. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), or the like. 
     Wireless Device: As used herein, a “wireless device” is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and/or receiving signals to a radio access node(s). Some examples of a wireless device include, but are not limited to, a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and a wired/wireless Customer Premises Equipment (CPE). 
     Network Node: As used herein, a “network node” is any node that is either part of the radio access network or the core network of a cellular communications network/system. 
     Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system. 
     Note that, in the description herein, reference may be made to the term “cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams. 
     As described above, previous technologies didn&#39;t provide the flexibility being introduced in 5G Core/NR that would allow the use of network slices, identified by Network Slice Selection Assistance Information (NSSAIs) serving the same UE. In 5G, the delivery of network slices happens automatically based on information exchanged between the UE and the 5G NR/CORE, which is very different mechanism from that used in LTE networks in which it was necessary to predefine Quality of Service (QoS) Class Identifiers (QCIs), each QCI having fixed QoS parameters tied to a dedicated type of service. 
     Thus, one disadvantage to the current 5G implementation is that there is currently no mechanism to expose these 5G QoS values (called Single NSSAIs (S-NSSAIs)) to applications within the UE, herein referred to as “native applications,” or to applications running on devices connected to the UE, herein referred to as “external applications.” As used herein, an application may also be referred to as an “app.” Examples of native applications include, but are limited to, online services applications, such as Facebook, Google, Amazon, Netflix, etc., and browsers, such as Safari. Examples of external applications include, but are not limited to, applications running on external devices such as smart watches, health monitoring devices, games consoles, entertainment solutions, smart televisions, personal assistants, etc., that are connected to the UE via a wired or wireless connection. 
     Enhanced UE 
       FIG.  3    illustrates an example of a UE or CPE capable of requesting appropriate NSSAI from a 5G network according to some embodiments of the present disclosure. The following description will use the term UE but it will be understood that the same principles may apply to a CPE or other similar equipment. 
     Modem. In the embodiment illustrated in  FIG.  3   , UE  300  communicates with a Core Access and Mobility Management Function (AMF)  108  via the N1 interface, which is attached to a 5G modem  302 . 
     Application Programming Interface (API) Layer. The UE  300  also includes one or more APIs, which, in the embodiment illustrated in  FIG.  3   , are located in an API Layer  304 . 
     Slice consumers. In the embodiment illustrated in  FIG.  3   , the API Layer  304  provides APIs to entities that may request to use network slices, referred to generically as “slice consumers.” Example slice consumers include internal applications or programs, such as a browser  306  or other native applications  308 , as well as devices external to the UE  300  but attached to the UE  300  via a wired interface  310  or a wireless interface  312 . Slice consumers within the UE  300  may also be referred to as “native slice consumers” and slice consumers external to the UE  300  may also be referred to as “external slice consumers  314 .” 
     For example, the UE  300  may have a wired connection to audio speakers, a television, or other appliance. Likewise, the UE  300  may be connected wirelessly to different kinds of devices, including smart watches or health monitoring devices, audio speakers, a television, headphones or in-ear speakers, game consoles, etc. These examples are illustrative and not limiting. In some embodiments, the wireless interface  312  may support one or more wireless protocols, including but not limited to Bluetooth, 2.4/5 Gigahertz (GHz) WiFi, WiGIG, Zigbee, Long Range (LoRa) radio, SigFox, or any type of low power type of wireless communication, etc. In this manner, external devices may be connected to the 5G network through the UE  300 , via cable, wire, or wireless link to the UE  300 , e.g., the UE  300  operates as a “hub.” 
     In the embodiment illustrated in  FIG.  3   , both the wired interface  310  and wireless interface  312  are allowed access to the APIs provided by the API Layer  304 . In this manner, not only can internal devices have the capability to perform NSSAI-related functions such as requesting information about S-NSSAIs, selecting S-NSSAIs, etc., but external device can also have such capabilities. 
     In some embodiments, the API layer  304  is middleware that resides on the UE  300  and is conceptually located between the 5G modem  302  and slice consumers. In some embodiments, the API layer  304  may perform multiple functions, including but not limited to the following: 
     Exposing current and future 5G, N1 interface, capabilities to the slice consumers. This allows browsers and native applications, as well as external devices, to discover the capabilities of the network slices that are allowed for that UE. Having that knowledge allows the slice consumer to make informed decisions about what slices to request. 
     Allowing a slice consumer to proactively request a slice or a slice having a particular characteristic, whether or not the slice consumer is aware of the capabilities of the allowed network slices. In this manner, a slice consumer may request a particular network slice that it knows to be allowed for that UE, or the slice consumer may make a request for a slice having a particular characteristic, and the API layer  304  will attempt to identify an appropriate network slice and request that slice on behalf of that UE. 
     Mapping industry-specific terms to NSSAI language, such that the slice consumer may make requests in terms of QoS, in terms of S-NSSAIs, or both. In some embodiments, the allowed slices information provided by the API layer  304  and/or 5G modem  302  may contain the details of the slice parameters. In some embodiments, there may be a previous agreement between the slice consumers and the Mobile Network Operator (MNO) or Mobile Virtual Network Operator (MVNO) regarding the establishment of slices identification and authorization. In some embodiments, there may be standardized network slices that could be understood by all entities within the ecosystem, such as “enhanced Mobile Broadband” (eMBB), “enhanced Machine Type Communication” (eMTC), “Ultra-Reliable Low-Latency Communication” (URLLC), and others. This allows a slice consumer to successfully request a slice whether or not the slice consumer is “NSSAI-literate.” 
     Providing Authentication/Authorization/Access (AAA) functions to the API consumers, e.g., via certificates/tokens previously authorized by the 5G Core. 
     In some embodiments, where slice consumers are requesting a dedicated Protocol Data Unit (PDU) session, the network slices can be consumed without previous minimum QoS validation. In some embodiments, where there is a common PDU session being used by multiple slice consumers, each of those multiple slice consumers will be allowed only request a network slice that provides an upgraded QoS, e.g., network slice requests that degrade QoS of the shared PDU session will be denied, so that the shared PDU session will also accommodate the needs of the other slice consumers. 
     Interfaces 
     In some embodiments, the network slice selection process may be exposed to the native and external applications through the API layer  304  via the creation or modification of interfaces within the UE architecture. In the embodiment illustrated in  FIG.  1   , a new interface  316  is defined between browsers  306  and the API layer  304 ; a new interface  318  is defined by between non-browser native apps  308  and the API layer  304 ; and a new interface  320  is defined between external devices that are connected to the UE  300  via the wired interface  310  or the wireless interface  312 . 
     In some embodiments, new interface  316  comprises a Representational State Transfer (REST) API to be used inside the UE  300  call flows when a browser needs to query and select allowed NSSAIs. 
     In some embodiments, new interface  318  comprises a REST API to be used inside the UE  300  call flows when a native application needs to query and select allowed NSSAIs. 
     In some embodiments, new interface  320  comprises a REST API to be used inside the UE  300  call flows when an external application needs to query and select allowed NSSAIs. In some embodiments, the wired interface  310  and the wireless interface  312  are modified to allow external devices to communicate with the API layers  304 . 
     In some embodiments, the interface  322  between the API layer  304  and the 5G modem  302  is modified to allow native and external browsers or other applications to specify NSSAI values requirements to be included within N1 messages when triggering a request for an NSSAI. For this reason, modified interface  322  may be referred to as being “N1-like,” in that it is capable of exposing 5G capabilities to entities within the UE  300  and entities external to but connected to the UE  300 . The N1 interface between a UE and an AMF as defined in the 5G standards already has the capability to allow UEs to select S-NSSAI(s), and thus can also support having internal and external UE applications making similar requests. 
     The new or modified interfaces described above allow the 5G modem  302 , which oversees the N1 interface with AMF  108  containing the NSSAI parameter, to expose the allowed NSSAI values to the API layer  304 , which could further expose those values for potential use by native and external applications. As an example, in the embodiment illustrated in  FIG.  3   , the UE  300  may be wirelessly connected to a display device, such as a television, which is mirroring the screen of the UE  300  (e.g., the user is streaming a movie through his or her mobile phone and using the television as the display device). The dashed line  324  represents a communication path by which the external display device may establish—or later modify—a network slice having appropriate characteristics (e.g., throughput sufficient to support a particular screen resolution, etc.) 
     Although  FIG.  1    illustrates a UE  300  having this capability, the same concepts may be applied to other types of devices, including, but not limited to, automobiles, Unmanned Aerial Vehicles (UAVs), airplanes, robots, machinery, appliances, vehicles, or any other entity that contains a 5G modem and that may be capable of (or would benefit from) selecting network slices via the N1 interface. Any such devices—not just UEs—may support exposing S-NSSAI communicated via the N1 interface for consumption by native or external applications according to embodiments of the present disclosure. Such devices can query allowed S-NSSAIs, request allowed 5-NSSAIs, and/or request the subscription to new S-NSSAIs. For simplicity of description, however, the term “UE” will hereinafter be used to represent any device having the capabilities described in the present disclosure. 
     Enhanced UE  300  provides several benefits over conventional UEs. For example, both native applications and external applications have the advantage that they have first-hand knowledge of when there is a need to change the QoS for a specific PDU session. Some illustrative examples include, but are not limited to, the following: 
     A user may change QoS requirements explicitly with actions such as:
         The user watching a video on a native or external application or browser explicitly changes the resolution of the video (e.g., by choosing, 144p, 240p, 360p, 480p, 720p, 1080p, 4K, 8K, etc.), which affects the required bandwidth and/or throughput or even the Content Delivery Network (CDN) server physical location; and   The user watching a video or listening to an audio book on any type of native or external application or browser explicitly changes the playback speed of the media content.       

     A user can change QoS requirements implicitly with actions such as:
         The user starts a Multiplayer, Real Time Game (MRTG) that requires super low latency;   The user starts an Augmented Reality (AR) application that requires super low latency (some researches show that &lt;5 ms round trip may be required in certain use cases);   The user starts an tactile Internet action that requires super low latency for haptic feedback (some researches show that &lt;10 ms round trip may be required in certain use cases); and   The user changes a display from portrait mode to landscape mode or vice versa, which may implicitly change the resolution of the video.       

     In the examples above, a native application or an external application is aware that the QoS for a specific PDU session will need to change. The UE  300  provides a mechanism by which the native or external application can actively request a change of QoS for an existing PDU session. The same principles apply to creation of a new PDU session, i.e., the native or external application has first-hand knowledge of what level of QoS will be needed for a new PDU session. The UE  300  provides a mechanism by which the native or external application can specify the initial QoS value for a new PDU session that is being requested. 
     It should be noted that some of the enhanced features of UE  300  do not require any modification to the existing N1 interface, but instead reuse current conventional N1 capabilities, with the caveat that the conventional messages sent over the N1 interface now take into account the information provided to the API layer via the new interfaces. For example, in some embodiments, messages sent by the 5G modem  302  to the AMF  108  via the N1 interface may include the NSSAI values requested by the native or external browsers or applications. 
     In other embodiments, the existing N1 interface may be enhanced. For example, in some embodiments, the existing N1 interface may be extended to allow the API layer  304  to be synchronized with 5G core systems on which native and external applications are authorized to participate in the NSSAI establishment process. In some embodiments, the existing N1 layer may be extended so as to provide the 5G modem  302  with details of the network slice parameters. 
     Enhanced AMF 
     In embodiments where the N1 layer is modified or enhanced, then the network may include an enhanced AMF  324  that supports the enhanced N1 layer functionality. Such enhancements supported by the enhanced AMF  324  include, but are not limited to: the possibility for 5G Modems and N1 consumers to request registration to existing NSSAIs (e.g., association to allowed NSSAIs); the possibility for 5G Modems and N1 consumers to request the creation of new NSSAIs; and the possibility to extend certain functions from N2 to N1, such as handover required request. Examples of all of these scenarios are illustrated in  FIGS.  4  through  7   . 
     Call Flows 
     The methods and systems provided herein may influence existing call flows described in 3GPP TS 23.502 as detailed below: 
     Registration Procedure. No changes: the UE  300  will register with the NSSAI values coming from the 5G modem  302 . 
     Registration with AMF reselection. No changes: the UE  300  will register with the NSSAI values coming from the 5G modem  302 . 
     UE-requested PDU Session Establishment for non-roaming and roaming with local breakout. During the PDU session Establishment the UE  300  could send the NSSAI values requested by a browser  306  or native application  308 . As defined in the call flow, the serving AMF  106 / 324  has discretionary decision to reject NSSAI requested and deliver the allowed/supported NSSAI. 
     UE-requested PDU Session Establishment for home-routed roaming scenarios. During the PDU session Establishment the UE  300  could send the NSSAI values requested by a browser  306  or native application  308 . As defined in the call flow, the serving AMF  106 / 324  has discretionary decision to reject NSSAI requested and deliver the allowed/supported NSSAI. 
     UE or network requested PDU Session modification for non-roaming and roaming with local breakout. The slice consumer can proactively or reactively modify an existing PDU session, or at least provide information with which the UE  300  may make an informed request for modification of the existing PDU session. 
     UE or network requested PDU Session modification for home-routed roaming scenario. The slice consumer can proactively or reactively modify an existing PDU session, or at least provide information with which the UE  300  may make an informed request for modification of the existing PDU session. 
     The enhanced call flows described above provide a valuable capability—namely, to allow both native and external slice consumers to create a PDU session with QoS characteristics that are appropriate to the anticipated need of the slice consumer and also to modify an existing PDU session in response to a current or anticipated change of QoS requirements. 
       FIG.  4    illustrates an example of signaling messages by which a UE may query an AMF for a list of S-NSSAI values that are available to the UE from the network according to some embodiments of the present disclosure.  FIG.  4    illustrates a new procedure that allows a 5G modem  302  to trigger an AMF  326  process to determine what S-NSSAI values are available from the network and to pass to the 5G modem  302  a list of the available S-NSSAI values. 
     At step  400 , the UE&#39;s 5G modem  302  sends a message over the N1 interface to the AMF  326  via the (R)AN  104 . In the embodiment illustrated in  FIG.  4   , this message comprises a query for available S-NSSAI values. 
     At step  402 , the AMF  326  responds to the query by requesting available slice information from a network node that manages slice information (herein referred to as a “slice information manager” or “slice manager.” In the embodiment illustrated in  FIG.  4   , the slice manager is a Unified Data Management node (UDM)  120  and the message is a Nudm_SDM_Get (Slice Selection Subscription Data) message. In alternative embodiments, this function may be performed by other operator network nodes, such as a Policy Control Function (PCF), Home Subscriber Server (HSS), or other database node. 
     At step  404 , the UDM  120  responds by sending to the AMF  326  a list of available S-NSSAI values. 
     At step  406 , the AMF  326  forwards the list of available S-NSSAI values to the 5G modem  302  via the (R)AN  104 . 
     This process allows a UE  300  to find out what S-NSSAI(s) are available from the network, either in response to request from a slice consumer within or connected to the UE  300 , or requested by the UE  300  (or by the 5G modem  302 ) in advance, e.g., before there is a particular need from a slice consumer. In contrast, in conventional networks, which do not have this capability, the UE  300  is forced to try blindly request different S-NSSAIs until it finds one that is allowed. In the following figures, this process of getting a list of available S-NSSAI values is shown as an optional step, reflecting the point that this process may be performed in response to a particular need or it may have been previously performed and the list of values saved by the 5G modem  302 . 
       FIG.  5    illustrates the scenario in which the native slice consumer seeks to establish a new PDU session or modify an existing PDU session. 
     At step  500 , the native slice consumer, which may be a browser  306  or other native application  308 , sends to the API Layer  304  a query requesting a list of available S-NSSAI values. 
     At step  502 , the API layer  304  first determines whether or not to allow the query. In the embodiment illustrated in  FIG.  5   , the query is allowed. In alternative embodiments, the query may be denied. In some embodiments, this step may be omitted entirely, i.e., the API layer  304  may always accept such queries. 
     At step  504 , the API layer  304  forwards the query to the 5G modem  302 . 
     At optional step  506 , if the 5G modem  302  does not already have a list of available S-NSSAI values (or wants to ensure that the list that it does have is up to date), the 5G modem  302  fetches the list of S-NSSAI(s) available for this UE  300 , e.g., by performing the steps illustrated in  FIG.  4   . This step may be skipped, e.g., if the 5G modem  302  already possesses the list of available S-NSSAI values. 
     At step  508 , the 5G modem  302  forwards the list of available S-NSSAIs to the native slice consumer via the API layer  304 . 
     At step  510 , the native slice consumer selects one or more S-NSSAI(s) from the list of available S-NSSAI values. 
     At step  512 , the slice consumer sends a request for the selected S-NSSAI(s) to the 5G modem  302  via the API layer  304 . 
     At step  518  the 5G modem  302  sends to the AMF  108 / 326  an N1 signal that includes information identifying the S-NSSAI(s) selected by the slice consumer. 
       FIG.  6    illustrates an example of signaling messages by which an entity external to the UE but connected to the UE, herein referred to as “an external slice consumer,” may request NSSAI according to some embodiments of the present disclosure.  FIG.  6    illustrates the scenario in which an external slice consumer  314  seeks to establish a new PDU session or modify an existing PDU session. 
     At step  600 , the external slice consumer  314  sends to the UE  300  a query requesting a list of available S-NSSAI values (message  500 ), which is received via the wired interface  310  or the wireless interface  312 . 
     At step  602 , the query is forwarded to the API layer  304   
     At step  604 , the API layer  304  determinates whether or not to allow the query from the external slice consumer  314  to be forwarded to the API layer  304 . In the embodiment illustrated in  FIG.  6   , the query is allowed. In an alternative embodiment the query may be denied. In some embodiments this step may be omitted entirely, i.e., the API layer  304  may always accept such queries from external slice consumers. 
     At step  606 , the API layer  304  forwards the query to the 5G modem  302 . 
     At optional step  608 , the 5G modem  302  fetches the list of S-NSSAI(s) available for this UE  300 , e.g., by performing the steps illustrated in  FIG.  4   . 
     At step  610 , the 5G modem  302  forwards the list of available S-NSSAIs to the wired interface  310  or the wireless interface  312 . 
     At step  612  the list of available S-NSSAIs is forwarded to the external slice consumer  3143 . 
     At step  614 , the external slice consumer  314  selects one or more S-NSSAI(s). 
     At step  616 , the external slice consumer  314  sends to the UE  120  a request for the selected S-NSSAI(s). 
     At step  618 , the request is forwarded through the API layer  304  to the 5G modem  302 . 
     At step  620 , the 5G modem  302  sends to the AMF  108 / 326  an N1 signal that includes information identifying the S-NSSAI(s) selected by the slice consumer. 
       FIG.  7    illustrates two examples of N1 signaling that includes information identifying the S-NSSAI(s) selected by a native or external slice consumer. The first example is request to establish a PDU session and the second example is a request to modify an existing PDU session. 
     At step  700 , the API layer  304  receives, from a native or external slice consumer that desires to establish a PDU session, a signal that identifies at least one S-NSSAI, e.g., S-NSSAI(s) selected by the slice consumer. 
     At step  702 , the API layer  304  forwards the information to the 5G modem  302 . 
     At step  704 , the 5G modem  302  uses conventional N1 signaling, e.g., a PDU Session Establishment Request, that contains information that identifies the S-NSSAI(s) selected by the slice consumer. In an alternative embodiment, the API layer  304  or the 5G modem  302 , rather than a slice consumer, may select the S-NSSAI(s). 
     At step  706 , the API layer  304  receives, from a slice consumer that desires to proactively or reactively modify an existing PDU session, information identifying one or more S-NSSAIs. 
     At step  708 , the API layer  304  forwards the information to the 5G modem  302 . 
     At step  710 , the 5G modem  302  uses enhanced N1 signaling, e.g., a PDU Session Modification Request that contains information that identifies the S-NSSAI(s) selected by the slice consumer. It is noted that conventional N1 signaling does not support this function: there is currently no mechanism for a slice consumer to request the modification of an existing PDU session using a specified S-NSSAI value or values. This function is supported by an enhanced AMF  326  as described herein but not supported by a conventional AMF  108 . 
     The call flows described above with regard to  FIGS.  5  and  6    provide a mechanism to allow, block, or filter NSSAI-related requests and other activities from native and external applications—namely, the steps in which the UE  300  determines whether or not to allow a query from a particular slice consumer. In some embodiments, other network nodes may be involved in this process, e.g., where network slice owners or other network functions may be involved in AAA functions. In this manner, the network may be protected from malicious actors trying to use the exposed N1 capabilities to engage in unapproved network activities or even network attacks.  FIGS.  8  and  9    illustrate two examples of the kinds of protection that the slice owners and/or network entities may provide to prevent unwanted or malicious activities by the slice consumers. 
       FIG.  8    illustrates an example of a scenario in which a request for a slice is denied because a subscription is required. 
     At step  800 , a native or external slice consumer sends, to its serving AMF  326 , a request for a selected S-NSSAI. The S-NSSAI may have been selected as a result of the steps taken in  FIG.  5    or  FIG.  6   , for example. It will be understood that traffic between the slice consumer and the AMF  326  will pass through the API layer  304  and the 5G modem  302 , which are omitted from  FIG.  8    for clarity. 
     At step  802 , the AMF  326  queries a slice manager to determine whether the selected S-NSSAI is allowed, e.g., available for use by the UE  300  or by the specific slice consumer. In the embodiment illustrated in  FIG.  8   , this function is performed by the UDM  120 . 
     At step  804 , the UDM  120  reports to the AMF  326  that the selected S-NSSAI is not allowed. 
     At step  806 , the AMF  326  notifies the slice consumer that the request was denied. In the embodiment illustrated in  FIG.  8   , the AMF  326  also notifies the slice consumer that a subscription is required in order to have access to the requested slice. 
     The slice consumer then uses or establishes a data session  808  with the Over-the-Top (OTT) backend  114 . 
     At step  810 , the slice consumer sends to the OTT backend  114  a request to subscribe to the selected S-NSSAI. 
     At step  812 , the OTT backend  114  forwards the subscription request to the UDM  120  via the Network Exposure Function (NEF)  122 . 
     At step  814 , the UDM  120  approves the subscription request and sends notification of the approval to the OTT backend  114  via the NEF  122 . 
     At step  816 , the OTT backend  114  then notifies the slice consumer to try the S-NSSAI request again. 
     At step  818 , the slice consumer again requests the selected S-NSSAI. 
     At step  820 , the AMF  326  queries the UDM  120  to determine whether or not the selected S-NSSAI is allowed. 
     At step  822 , the UDM  120  notifies the AMF  326  that the S-NSSAI is allowed. 
     At step  824 , the AMF  326  forwards to the slice consumer the notification that the requested S-NSSAI is allowed. 
       FIG.  9    illustrates an example in which a slice owner approves a slice request according to some embodiments of the present disclosure. In the embodiment illustrated in 9, a slice consumer (e.g., a native browser  306  or native application  308 ) already has a data session  900  with an Application Function  114  (e.g., an OTT backend server). 
     At step  902 , a request is sent from a new slice consumer, which may be a native or external slice consumer, to the associated OTT backend  114 . The OTT backend  114  needs to query an entity that certifies slice consumers to determine whether the requesting slice consumer is certified. In the embodiment illustrated in  FIG.  9   , the UDM  120  performs this function, but in alternative embodiments, this function may be performed by other operator network nodes, such as a PCF, HSS, or other database node. In the embodiment illustrated in  FIG.  9   , the OTT backend  114  is outside of the operator network; to get to the UDM  120 , the OTT backend  114  must go through a NEF  122  to reach operator network nodes such as the UDM  120 . 
     At step  904 , therefore, the OTT backend  114  sends to the NEF  122  a message asking to approve the new slice consumer. 
     At step  906 , the NEF  122  forwards the query to the UDM  120 . 
     At step  908 , the UDM  120  approves the new slice consumer and provides to the NEF  122  a certificate to be used by the UE  300 . In some embodiments, the approval includes a certificate to match a certificate of the API layer  304 . 
     At step  910 , the NEF  122  forwards the certificate to the OTT backend  114 . 
     At step  912 , the OTT backend  114  forwards the certificate to the now-certified slice consumer. Thus, the slice consumer goes through the OTT backend  114  to get certified. Once certified, the slice consumer then communicates with the NEF  122  directly to validate the certificate. 
     At step  914 , the slice consumer sends to the API layer  304  a request to validate the certificate. This request may include the certificate to be validated or may contain information that otherwise identifies the certificate to be validated. The API layer  304  communicates with the NEF  122  via an IP data session  916 . 
     At step  918 , the API layer  304  requests that the NEF  122  validate the certificate. This request may include the certificate to be validated or may contain information that otherwise identifies the certificate to be validated. 
     At step  920 , the NEF  122  queries the UDM  120  to validate the certificate. 
     At step  922 , the UDM  120  notifies the NEF  122  that the certificate is valid. 
     At step  924 , the NEF  122  forwards this notification to the API layer  304 . 
     At step  926 , the API layer  204  forwards this notification to the slice consumer. 
     In some embodiments, the slice consumer will then include the certificate when it makes a slice-related request. In some embodiments, the API layer  304  and/or the 5G modem  302  will maintain copies of the received certificates and will use them to validate requests from slice consumers, e.g., a 5G modem  302 , for example, may allow transmission of a request received from a slice consumer only if that request contains a certificate that matches one of the certificates maintained by the 5G modem  302 . In other embodiments, the API layer  304  and/or the 5G modem  302  may operate in an open, non-restrictive mode, e.g., allowing any request from a slice consumer to pass through to the network without restriction. In still other embodiments, the API layer  304  and/or the 5G modem  302  may impose limited restrictions on what requests from slice consumers may be allowed out onto the network. The same principles described above may apply to restrict (or not restrict) incoming traffic from the network to the UE  300 , as well. 
       FIGS.  8  and  9    illustrate the point that decisions from network slice owners and other network elements, including, but not limited to, AMFs  108 / 326 , Session Management Functions (SMFs)  110 , PCFs  112 , Application Functions (AFs)  114 , Network Slice Selection Functions (NSSFs)  116 , Authentication Server Function (AUSFs)  118 , UDMs  120 , Network Repository Functions (NRFs), Online Charging Systems (OCSs), and so on, may take into consideration the information that now can be provided by native and external slice consumers according to embodiments of the present disclosure. In some embodiments, the information may be in the form of standardized NSSAI values. 
     New Call Flows 
     In some embodiments, a new call flow allows the 5G core systems, such as an NSSF, a PCF, and/or a UDM, for example, to control which slice consumers are authorized to influence the network. In some embodiments, the call flow illustrated in  FIG.  8    would be enhanced, e.g., to incorporate a security mechanism whereby the particular slice consumer is subjected to an authentication, authorization, access, or other security procedure before being allowed to create or modify a PDU session. 
     In some embodiments, a new call flow allows the 5G core systems to accept new slice consumers&#39; requests to be included in a white list of NSSAIs requests. In some embodiments, the call flow illustrated in  FIG.  8    would be enhanced, e.g., to provide a mechanism by which a white list is created, maintained, and made available for query by network nodes that may be involved in slice-related network activities. 
     In some embodiments, a new call flow allows authorized slice consumers to request the subscription of new NSSAIs that are exposed by a 5G core system NSSAIs catalogue in the NSSF for example. In some embodiments, the call flow illustrated in  FIG.  9    would be enhanced, e.g., to provide a mechanism whereby the slice consumer can query an NSSF  116  to find out what NSSAIs are available for subscription. This kind of query could be made prior to the initial NSSAI-related request, e.g., to see what NSSAIs are supported by the network and/or by the particular UE, or during the slice request process, e.g., after a request is denied, to find out what NSSAIs the slice consumer does have access to, or after a request is allowed, to find out what other NSSAIs the slice consumer may also take advantage of. 
     Other Embodiments 
       FIG.  10    illustrates one example of a cellular communications network  1000  according to some embodiments of the present disclosure. In the embodiments described herein, the cellular communications network  1000  is a 5G NR network. In this example, the cellular communications network  1000  includes base stations  1002 - 1  and  1002 - 2 , which in LTE are referred to as eNBs and in 5G NR are referred to as gNBs, controlling corresponding macro cells  1004 - 1  and  1004 - 2 . The base stations  1002 - 1  and  1002 - 2  are generally referred to herein collectively as base stations  1002  and individually as base station  1002 . Likewise, the macro cells  1004 - 1  and  1004 - 2  are generally referred to herein collectively as macro cells  1004  and individually as macro cell  1004 . The cellular communications network  1000  also includes a number of low power nodes  1006 - 1  through  1006 - 4  controlling corresponding small cells  1008 - 1  through  1008 - 4 . The low power nodes  1006 - 1  through  1006 - 4  can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells  1008 - 1  through  1008 - 4  may alternatively be provided by the base stations  1002 . The low power nodes  1006 - 1  through  1006 - 4  are generally referred to herein collectively as low power nodes  1006  and individually as low power node  1006 . Likewise, the small cells  1008 - 1  through  1008 - 4  are generally referred to herein collectively as small cells  1008  and individually as small cell  1008 . The base stations  1002  (and optionally the low power nodes  1006 ) are connected to a core network  1010 . 
     The base stations  1002  and the low power nodes  1006  provide service to wireless devices  1012 - 1  through  1012 - 5  in the corresponding cells  1004  and  1008 . The wireless devices  1012 - 1  through  1012 - 5  are generally referred to herein collectively as wireless devices  1012  and individually as wireless device  1012 . The wireless devices  1012  are also sometimes referred to herein as UEs. 
       FIG.  11    is a schematic block diagram of a radio access node  1100  according to some embodiments of the present disclosure. The radio access node  1100  may be, for example, a base station  1002  or  1006 . As illustrated, the radio access node  1100  includes a control system  1102  that includes one or more processors  1104  (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory  1106 , and a network interface  1108 . In addition, the radio access node  1100  includes one or more radio units  1110  that each includes one or more transmitters  1112  and one or more receivers  1114  coupled to one or more antennas  1116 . In some embodiments, the radio unit(s)  1110  is external to the control system  1102  and connected to the control system  1102  via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s)  1110  and potentially the antenna(s)  1116  are integrated together with the control system  1102 . The one or more processors  1104  operate to provide one or more functions of a radio access node  1100  as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory  1106  and executed by the one or more processors  1104 . 
       FIG.  12    is a schematic block diagram that illustrates a virtualized embodiment of the radio access node  1100  according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. 
     As used herein, a “virtualized” radio access node is an implementation of the radio access node  1100  in which at least a portion of the functionality of the radio access node  1100  is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node  1100  includes the control system  1102  that includes the one or more processors  1104  (e.g., CPUs, ASICs, FPGAs, and/or the like), the memory  1106 , and the network interface  1108  and the one or more radio units  1110  that each includes the one or more transmitters  1112  and the one or more receivers  1114  coupled to the one or more antennas  1116 , as described above. The control system  1102  is connected to the radio unit(s)  1110  via, for example, an optical cable or the like. The control system  1102  is connected to one or more processing nodes  1200  coupled to or included as part of a network(s)  1202  via the network interface  1108 . Each processing node  1200  includes one or more processors  1204  (e.g., CPUs, ASICs, FPGAs, and/or the like), memory  1206 , and a network interface  1208 . 
     In this example, functions  1210  of the radio access node  1100  described herein are implemented at the one or more processing nodes  1200  or distributed across the control system  1102  and the one or more processing nodes  1200  in any desired manner. In some particular embodiments, some or all of the functions  1210  of the radio access node  1100  described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s)  1200 . As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s)  1200  and the control system  1102  is used in order to carry out at least some of the desired functions  1210 . Notably, in some embodiments, the control system  1102  may not be included, in which case the radio unit(s)  1110  communicate directly with the processing node(s)  1200  via an appropriate network interface(s). 
     In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node  1100  or a node (e.g., a processing node  1200 ) implementing one or more of the functions  1210  of the radio access node  1100  in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). 
       FIG.  13    is a schematic block diagram of the radio access node  1100  according to some other embodiments of the present disclosure. The radio access node  1100  includes one or more modules  1300 , each of which is implemented in software. The module(s)  1300  provide the functionality of the radio access node  1100  described herein. This discussion is equally applicable to the processing node  1200  of  FIG.  12    where the modules  1300  may be implemented at one of the processing nodes  1200  or distributed across multiple processing nodes  1200  and/or distributed across the processing node(s)  1200  and the control system  1102 . 
       FIG.  14    is a schematic block diagram of a UE  1400  according to some embodiments of the present disclosure. As illustrated, the UE  1400  includes one or more processors  1402  (e.g., CPUs, ASICs, FPGAs, and/or the like), memory  1404 , and one or more transceivers  1406  each including one or more transmitters  1408  and one or more receivers  1410  coupled to one or more antennas  1412 . In some embodiments, the functionality of the UE  1400  described above may be fully or partially implemented in software that is, e.g., stored in the memory  1404  and executed by the processor(s)  1402 . 
     In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE  1400  according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). 
       FIG.  15    is a schematic block diagram of the UE  1400  according to some other embodiments of the present disclosure. The UE  1400  includes one or more modules  1500 , each of which is implemented in software. The module(s)  1500  provide the functionality of the UE  1400  described herein. 
       FIG.  16    illustrates a communication system according to some embodiments of the present disclosure. In the embodiment illustrated in  FIG.  16   , the communication system includes a telecommunication network  1600 , such as a 3GPP-type cellular network, which comprises an access network  1602 , such as a RAN, and a core network  1604 . The access network  1602  comprises a plurality of base stations  1606 A,  1606 B,  1606 C, such as Node Bs (NBs), eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area  1608 A,  1608 B,  1608 C. Each base station  1606 A,  1606 B,  1606 C is connectable to the core network  1604  over a wired or wireless connection  1610 . A first UE  1612  located in coverage area  1608 C is configured to wirelessly connect to, or be paged by, the corresponding base station  1606 C. A second UE  1614  in coverage area  1608 A is wirelessly connectable to the corresponding base station  1606 A. While a plurality of UEs  1612 ,  1614  are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station  1606 . 
     The telecommunication network  1600  is itself connected to a host computer  1616 , which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer  1616  may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections  1618  and  1620  between the telecommunication network  1600  and the host computer  1616  may extend directly from the core network  1604  to the host computer  1616  or may go via an optional intermediate network  1622 . The intermediate network  1622  may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network  1622 , if any, may be a backbone network or the Internet; in particular, the intermediate network  1622  may comprise two or more sub-networks (not shown). 
     The communication system of  FIG.  16    as a whole enables connectivity between the connected UEs  1612 ,  1614  and the host computer  1616 . The connectivity may be described as an OTT connection  1624 . The host computer  1616  and the connected UEs  1612 ,  1614  are configured to communicate data and/or signaling via the OTT connection  1624 , using the access network  1602 , the core network  1604 , any intermediate network  1622 , and possible further infrastructure (not shown) as intermediaries. The OTT connection  1624  may be transparent in the sense that the participating communication devices through which the OTT connection  1624  passes are unaware of routing of uplink and downlink communications. For example, the base station  1606  may not or need not be informed about the past routing of an incoming downlink communication with data originating from the host computer  1616  to be forwarded (e.g., handed over) to a connected UE  1612 . Similarly, the base station  1606  need not be aware of the future routing of an outgoing uplink communication originating from the UE  1612  towards the host computer  1616 . 
       FIG.  17    illustrates a communication system according to other embodiments of the present disclosure. The UE, base station, and host computer discussed in the preceding paragraphs will now be described with reference to  FIG.  17   . In the embodiment illustrated in  FIG.  17   , in a communication system  1700 , a host computer  1702  comprises hardware  1704  including a communication interface  1706  configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system  1700 . The host computer  1702  further comprises processing circuitry  1708 , which may have storage and/or processing capabilities. In particular, the processing circuitry  1708  may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The host computer  1702  further comprises software  1710 , which is stored in or accessible by the host computer  1702  and executable by the processing circuitry  1708 . The software  1710  includes a host application  1712 . The host application  1712  may be operable to provide a service to a remote user, such as a UE  1714  connecting via an OTT connection  1716  terminating at the UE  1714  and the host computer  1702 . In providing the service to the remote user, the host application  1712  may provide user data which is transmitted using the OTT connection  1716 . 
     The communication system  1700  further includes a base station  1718  provided in a telecommunication system and comprising hardware  1720  enabling it to communicate with the host computer  1702  and with the UE  1714 . The hardware  1720  may include a communication interface  1722  for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system  1700 , as well as a radio interface  1724  for setting up and maintaining at least a wireless connection  1726  with the UE  1714  located in a coverage area (not shown in  FIG.  17   ) served by the base station  1718 . The communication interface  1722  may be configured to facilitate a connection  1728  to the host computer  1702 . The connection  1728  may be direct or it may pass through a core network (not shown in  FIG.  17   ) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware  1720  of the base station  1718  further includes processing circuitry  1730 , which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The base station  1718  further has software  1732  stored internally or accessible via an external connection. 
     The communication system  1700  further includes the UE  1714  already referred to. The UE&#39;s  1714  hardware  1734  may include a radio interface  1736  configured to set up and maintain a wireless connection  1726  with a base station serving a coverage area in which the UE  1714  is currently located. The hardware  1734  of the UE  1714  further includes processing circuitry  1738 , which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The UE  1714  further comprises software  1740 , which is stored in or accessible by the UE  1714  and executable by the processing circuitry  1738 . The software  1740  includes a client application  1742 . The client application  1742  may be operable to provide a service to a human or non-human user via the UE  1714 , with the support of the host computer  1702 . In the host computer  1702 , the executing host application  1712  may communicate with the executing client application  1742  via the OTT connection  1716  terminating at the UE  1714  and the host computer  1702 . In providing the service to the user, the client application  1742  may receive request data from the host application  1712  and provide user data in response to the request data. The OTT connection  1716  may transfer both the request data and the user data. The client application  1742  may interact with the user to generate the user data that it provides. 
     It is noted that the host computer  1702 , the base station  1718 , and the UE  1714  illustrated in  FIG.  17    may be similar or identical to the host computer  1616 , one of the base stations  1606 A,  16068 ,  1606 C, and one of the UEs  1612 ,  1614  of  FIG.  16   , respectively. This is to say, the inner workings of these entities may be as shown in  FIG.  17    and independently, the surrounding network topology may be that of  FIG.  16   . 
     In  FIG.  17   , the OTT connection  1716  has been drawn abstractly to illustrate the communication between the host computer  1702  and the UE  1714  via the base station  1718  without explicit reference to any intermediary devices and the precise routing of messages via these devices. The network infrastructure may determine the routing, which may be configured to hide from the UE  1714  or from the service provider operating the host computer  1702 , or both. While the OTT connection  1716  is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network). 
     The wireless connection  1726  between the UE  1714  and the base station  1718  is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE  1714  using the OTT connection  1716 , in which the wireless connection  1726  forms the last segment. More precisely, the teachings of these embodiments allow native and external slice consumers to have awareness of network slices generally (and perhaps of NSSAIs specifically) and to have a mechanism by which the slice consumers can use this awareness to request slice-related actions. These capabilities thereby provide benefits such as giving the slice consumers the ability to request network slices that are appropriate to the needs of the slice consumer as well as to proactively request the creation of new slices (or the modification of existing slices) in response to instantaneous or predicted need. 
     A measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection  1716  between the host computer  1702  and the UE  1714 , in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection  1716  may be implemented in the software  1710  and the hardware  1704  of the host computer  1702  or in the software  1740  and the hardware  1734  of the UE  1714 , or both. In some embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection  1716  passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which the software  1710 ,  1740  may compute or estimate the monitored quantities. The reconfiguring of the OTT connection  1716  may include message format, retransmission settings, preferred routing, etc.; the reconfiguring need not affect the base station  1714 , and it may be unknown or imperceptible to the base station  1714 . Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer  1702 &#39;s measurements of throughput, propagation times, latency, and the like. The measurements may be implemented in that the software  1710  and  1740  causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection  1716  while it monitors propagation times, errors, etc. 
       FIG.  18    is a flowchart illustrating a method implemented in a communication system, in accordance with some embodiments. The communication system includes a host computer, a base station, and a UE which may be those described with reference to  FIGS.  16  and  17   . For simplicity of the present disclosure, only drawing references to  FIG.  18    will be included in this section. In step  1800 , the host computer provides user data. In sub-step  1802  (which may be optional) of step  1800 , the host computer provides the user data by executing a host application. In step  1804 , the host computer initiates a transmission carrying the user data to the UE. In step  1806  (which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step  1808  (which may also be optional), the UE executes a client application associated with the host application executed by the host computer. 
       FIG.  19    is a flowchart illustrating a method implemented in a communication system, in accordance with some embodiments. The communication system includes a host computer, a base station, and a UE which may be those described with reference to  FIGS.  16  and  17   . For simplicity of the present disclosure, only drawing references to  FIG.  19    will be included in this section. In step  1900  of the method, the host computer provides user data. In an optional sub-step (not shown) the host computer provides the user data by executing a host application. In step  1902 , the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In step  1904  (which may be optional), the UE receives the user data carried in the transmission. 
       FIG.  20    is a flowchart illustrating a method implemented in a communication system, in accordance with some embodiments. The communication system includes a host computer, a base station, and a UE which may be those described with reference to  FIGS.  16  and  17   . For simplicity of the present disclosure, only drawing references to  FIG.  20    will be included in this section. In step  2000  (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step  2002 , the UE provides user data. In sub-step  2004  (which may be optional) of step  2000 , the UE provides the user data by executing a client application. In sub-step  2006  (which may be optional) of step  2002 , the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in sub-step  2008  (which may be optional), transmission of the user data to the host computer. In step  2010  of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure. 
       FIG.  21    is a flowchart illustrating a method implemented in a communication system, in accordance with some embodiments. The communication system includes a host computer, a base station, and a UE which may be those described with reference to  FIGS.  16  and  17   . For simplicity of the present disclosure, only drawing references to  FIG.  21    will be included in this section. In step  2100  (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step  2102  (which may be optional), the base station initiates transmission of the received user data to the host computer. In step  2104  (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station. 
     Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure. 
     While processes in the figures may show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.). 
     The subject matter of the present disclosure (herein referred to as “the solution”) provides several advantages over conventional systems. These advantages include, but are not limited to, the following:
         The solution provides a mechanism to empower native and external slice consumers to participate in the end-to-end customer experience, and possibly in the flow of money for 5G monetization, by participating in the creation and modification of network slices.   In 5G, network slices are “intended-based” delivery, and by allowing native and external slice consumers to express their needs, the solution helps the network to predict what type of network resources may be needed when and where is needed.   The solution reuses existing 5G Core Systems elements and existing or future call flows, and thus minimizes the impact of the implementation. Changes are needed only in the UE (devices) ecosystem, most of which may be implemented by changes to software or firmware within the UE.   The solution gives MNOs/MVNOs an alternative to monetize their network capabilities from OTT flow of money, e.g., via charging for the use of the new APIs.   The solution brings the opportunity for the UE ecosystem to dynamically take full advantage of the 5G spectrum flexibility, from Low-, through Mid-, and all the way to the High Bands. The solution enables a UE to send S-NSSAI values to accommodate bandwidth/frequency resources from these totally different types of 5G stratum access.   The solution brings the opportunity for the UE ecosystem to dynamically take full advantage of the 5G Core Systems flexibility, from different physical locations of UPFs, such as UPFs on premises, UPFs accessible via access sites, or centralized UPFs. The solution enables a UE to send S-NSSAI values to accommodate resources from these distributed UPFs architecture.       

     At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).
         3GPP Third Generation Partnership Project   5G Fifth Generation   AAA Authentication, Authorization, and Access   AF Application Function   AMF Core Access and Mobility Management Function   AN Access Node   AP Access Point   API Application Programming Interface   AR Augmented Reality   ASIC Application Specific Integrated Circuit   AUSF Authentication Server Function   CDN Content Delivery Network   CPE Customer Premise Equipment   CPU Central Processing Unit   DN Data Network   DSP Digital Signal Processor   eMBB Enhanced Mobile Broadband   eMTC Enhanced Machine Type Communication   eNB Enhanced or Evolved Node B   FPGA Field Programmable Gate Array   GHz Gigahertz   gNB New Radio Base Station   HSS Home Subscriber Server   ID Identifier/Identity   LoRa Long Range (wireless data communication)   LTE Long Term Evolution   MME Mobility Management Entity   MNO Mobile Network Operator   MRTG Multiplayer, Real Time Game   MTC Machine Type Communication   MVNO Mobile Virtual Network Operator   NB Node B   NEF Network Exposure Function   NR New Radio   NRF Network Repository Function   NSSAI Network Slice Selection Assistance Information   NSSF Network Slice Selection Function   OCS Online Charging System   OTT Over-the-Top   PCF Policy Control Function   PDU Protocol Data Unit   P-GW Packet Data Network Gateway   PLMN Public Land Mobile Network   QCI Quality of Service Class Identifier   QoS Quality of Service   RAM Random Access Memory   RAN Radio Access Network   REST Representational State Transfer protocol   ROM Read Only Memory   RRH Remote Radio Head   SCEF Service Capability Exposure Function   SMF Session Management Function   S-NSSAI Single Network Slice Selection Assistance Information   TS Technical Specification   UAV Unmanned Aerial Vehicle   UDM Unified Data Management   UE User Equipment   UPF User Plane Function   URLLC Ultra-Reliable Low Latency Communication   UTRAN Universal Terrestrial Radio Access Network       

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