[go: up one dir, main page]

WO2018013925A1 - Adaptive authorization framework for communication networks - Google Patents

Adaptive authorization framework for communication networks Download PDF

Info

Publication number
WO2018013925A1
WO2018013925A1 PCT/US2017/042141 US2017042141W WO2018013925A1 WO 2018013925 A1 WO2018013925 A1 WO 2018013925A1 US 2017042141 W US2017042141 W US 2017042141W WO 2018013925 A1 WO2018013925 A1 WO 2018013925A1
Authority
WO
WIPO (PCT)
Prior art keywords
authorization
service
network
access
information
Prior art date
Application number
PCT/US2017/042141
Other languages
French (fr)
Inventor
Samir Ferdi
Vinod Kumar Choyi
Yogendra C. Shah
Alec Brusilovsky
Original Assignee
Idac Holdings, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idac Holdings, Inc. filed Critical Idac Holdings, Inc.
Publication of WO2018013925A1 publication Critical patent/WO2018013925A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/67—Risk-dependent, e.g. selecting a security level depending on risk profiles

Definitions

  • a fifth generation of networks is generally referred to as 5G.
  • Mobile phones have evolved from voice centric monochrome devices with minuscule screens and little processing power to devices with high resolution, palm sized screens, and data processing power rivaling laptop computers. This transformation, coupled with an expanding cache of bandwidth hungry applications, have triggered demands for higher data rates.
  • Mobile data traffic reportedly grew more than 24-fold between 2010 and 2015 and may grow more than 500-fold between 2010 and 2020. This has, in turn, propelled the uptake of 4G network equipment contracts and driven operators worldwide to deploy 4G networks.
  • 4G supports high data rates (e.g., up to 1 Gbit/s) on the downlink.
  • 5G next generation
  • Use cases that may influence a 5G system architecture include Enhanced Mobile Broadband (eMBB) connectivity, Massive Machine Type Communications (mMTC) and Ultra-Reliable Critical Communications (URCC) services.
  • eMBB Enhanced Mobile Broadband
  • mMTC Massive Machine Type Communications
  • URCC Ultra-Reliable Critical Communications
  • an application or device, or a network function or service may be dynamically authorized to access a network resource or service.
  • Authorization information may be defined, provisioned, and/or updated specific to an application, device, network function, or service.
  • an authorization node or function receives a request from a device to use a service provided by at least one Network Slice (NS).
  • the authorization node obtains authorization decision information that includes at least one of: information related to a subscription, the service, or the at least one network slice; one or more operator policies; or information related to the device.
  • the authorization decision information is compared to the request.
  • the authorization function Based on the comparison between the authorization decision information and the request, the authorization function generates authorization information, and sends the authorization information to the device.
  • the authorization information may include at least one of a proof of authorization or an indication of an authorization grant decision.
  • the proof of authorization or the indication of the authorization grant decision may include an access token that indicates at least one of: 1) an authentication level that was achieved; 2) an identity proof of the device; 3) a security assurance level; 4) one or more authentication factors used; 5) an authorization role associated with the device; 6) an authorized access time period; 7) a service type that is authorized; 8) one or more service specific parameters; and 9) one or more payment parameters.
  • FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.
  • FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A.
  • WTRU wireless transmit/receive unit
  • FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. lA.
  • FIG. ID is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. lA.
  • FIG. IE is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. lA.
  • FIG. 2 depicts an example of different business models in 5G Networks.
  • FIG. 3 depicts an example of dimensions of innovation in 5G Networks.
  • FIG. 4 depicts an example of Network Slicing.
  • FIG. 5 depicts an example of NFV Layers in an example NFV architecture.
  • FIG. 6 depicts an example of an NFV-MANO Architecture.
  • FIG. 7 depicts an example of SDN Layering.
  • FIG. 8 depicts an example of ProSe Non-Roaming Reference Architecture.
  • FIG. 9 is an example of an OAUTH protocol flow.
  • FIG. 10 is a call flow that depicts an example of a PUSH Authorization Model.
  • FIG. 11 is a call flow that depicts an example of a PULL Authorization Model.
  • FIG. 12 is a call flow that depicts an example of an Agent Authorization Model.
  • FIG. 13 is a call flow that depicts an example of a PUSH Confirm Authorization
  • FIG. 14 is a call flow that depicts an example of an Indirect PUSH
  • FIG. 15 is a state diagram that illustrates examples of dynamic authorization triggers.
  • FIG. 16 depicts
  • FIG. 17 depicts
  • FIG. 18 depicts
  • FIG. 19 depicts
  • FIG. 20 depicts
  • FIG. 21 depicts an example of an authorization function for providing access to a network service.
  • FIG. 22 depicts an example of an authorization function for providing access for a roaming WTRU to access a network service.
  • FIG. 23 depicts an example of sub-networking with implicit authorization for WTRU access to a network function.
  • FIG. 24 depicts an example of an authorization function for WTRU access to a network function.
  • FIG. 25 depicts an example of implicit authorization and slice isolation by network configuration for access to a network slice by a network slice.
  • FIG. 26 depicts an example of an authorization function for access to a network slice by a network slice.
  • FIG. 27 depicts an example of authorization functions for WTRU access to multiple slices.
  • FIG. 28 depicts an example of an authorization function with tags applied to resources and consumers of those resources.
  • FIG. 29 depicts an example of generic security functions in a sliced network architecture.
  • FIG. 30 depicts an example of a Security Functions Toolbox for
  • FIG. 31 depicts an example of a Proactive Authorization Framework.
  • FIG. 32 depicts an example of a Trusted Third Party Authorization Architecture.
  • FIG. 33 depicts an example of a Service Access Token.
  • FIG. 34 depicts an example of a chained token structure.
  • FIG. 35 depicts another example of a Proactive Authorization Framework
  • FIG. 36 depicts an example of a Proactive Authorization Framework using MNO as a Trust Anchor.
  • FIG. 37 depicts an example of a Reactive Authorization Framework.
  • FIG. 38 is an example call flow performed within the Reactive Authorization Framework.
  • FIG. 39 depicts an example of high-level authorizations.
  • FIG. 40 depicts an example of a Proof-of-Authorization, e.g., a Service Access
  • FIG. 41 depicts an example of a multi service authorization with caching architecture.
  • FIGs. 42A and 42B depict an example of a tiered authorization procedure.
  • FIG. 43 depicts an example of an authorization update/revocation procedure.
  • FIG. 44 depicts an example of an authorization update/revocation procedure.
  • FIG. 45 depicts an example of distributed AF using an SDN infrastructure for CP/UP access control enforcement.
  • new radio (NR) networks may support higher data rates for uplink (UL) and downlink (DL) as compared to legacy networks.
  • uplink data throughput may be as high as or may exceed downlink data throughput.
  • 5G may improve coverage and user experience as compared to legacy systems, for example, with higher data rate, lower latency and improved energy efficiency.
  • IEEE 802.11 High Efficiency Wireless (HEW) may increase the presence of cellular operators, which may amalgamate different access technologies developed in different Standards Development Organizations (SDOs) to support future connectivity and data rates.
  • 5G throughput and connectivity may be provided by multiple interconnected
  • communication standards which may, for example, range from wireless metropolitan area networks down to wireless personal area networks and wired networks.
  • Massive connectivity may be driven by a variety of things or objects (e.g., RFID tags, sensors, actuators and mobile phones) in the environment, which may be referred to generally as the Internet of Things (IoT).
  • IoT Internet of Things
  • Objects or devices may interact with each other in a variety of ways and may generate huge amounts of data.
  • the IoT and the Internet have converged and may continue converging with a multitude and variety of service scenarios.
  • 5G systems may connect smart objects (e.g., M2M or IoT devices) and may enable them to interact with other objects, for example, to yield productivity and automation gains through predictive, actionable intelligence.
  • mobile devices may adopt a silent mode when entering a meeting room per a request of a meeting moderator (e.g., indicated in a policy), may alert a user to and/or turn off the radio on the user's mobile phone before entering sensitive medical areas, or may detect when a user enters a car and automatically connect to its sound system.
  • wireless sensors may let people check where their pet is in real-time, and may control the temperature for each room of their home while they are out.
  • Emergency services may be remotely and automatically alerted, for example, when a fire is detected in a building or when a patient's medical parameters shift beyond a critical threshold.
  • 5G may provide increased service reliability for mission critical
  • 5G systems may provide resiliency and reliability. 5G wireless systems may improve data rates, efficiencies, and may enable new IoT services. 5G technologies may support traffic growth of 1000 times, for example, without a corresponding increase in CAPEX and OPEX costs. 5G system architecture may reduce costs for Mobile Operators or Service Providers. Cost reduction and flexibility for wireless networks may be achieved, for example, by reducing dependency on dedicated network functions and switching to generic COTS platforms, such as cloud computing utilizing virtualization technologies. 5G systems may provide automation and remote interaction, but it is recognized herein that security and privacy issues may be introduced by and associated with 5G networks.
  • 5G networks may be designed to connect industries, such as manufacturing and processing, intelligent transportation, smart grids and e-health. Different environments may cause issues for speed, latency and heterogeneity. Interaction by different platforms may mean different protocols, different interfaces and different policies (e.g., QoS requirements). Diverse service contexts may introduce various security and privacy considerations. For example, an e- health information system may have more privacy than a Home Automation System (HAS) that may have more security for Control Plane (CP) signaling. Network data handling capabilities may be improved to accommodate a large volume of data transported, stored and/or processed in 5G systems. Radio Network equipment that supports higher frequencies (e.g., Millimeter wave (mmW) 30GHz+) and core networks that store, forward and process data may be deployed, which may increase CAPEX and associated OPEX expenditures by mobile network service providers.
  • mmW Millimeter wave
  • FIG. 1A is a diagram of an example communications system 100 in which one or more embodiments disclosed herein may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single- carrier FDMA
  • the communications system 100 may include wireless transmit/receive units (WTRUs), e.g., WTRUs, 102a, 102b, 102c and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs wireless transmit/receive units
  • RAN radio access network
  • PSTN public switched telephone network
  • Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • the communications system 100 may also include a base station 114a and a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
  • BSC base station controller
  • RNC radio network controller
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown).
  • the cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, e.g., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 115/116/117 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA
  • the base station 114a in the TDMA TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the TDMA TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as
  • WCDMA Universal Mobile Telecommunications System
  • HSPA High-Speed Packet Access
  • HSPA+ Evolved HSPA
  • HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
  • HSDPA High-Speed Downlink Packet Access
  • HSUPA High-Speed Uplink Packet Access
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE- A).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.16 e.g., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGERAN
  • the base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.
  • the RAN 103/104/105 may be in communication with the core network
  • 106/107/109 which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b,
  • VoIP voice over internet protocol
  • the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT.
  • the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • the core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.
  • Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.
  • the WTRU 102c shown in FIG. 1 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • FIG. IB is a system diagram of an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138.
  • GPS global positioning system
  • the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB or HeNodeB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.
  • BTS transceiver station
  • Node-B a Node-B
  • AP access point
  • eNodeB evolved home node-B
  • HeNB or HeNodeB home evolved node-B gateway
  • proxy nodes among others, may include some or all of the elements depicted in FIG. IB and described herein.
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some embodiments, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination implementation while remaining consistent with an embodiment.
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player
  • FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment.
  • the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115.
  • RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the
  • RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115.
  • the Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103.
  • the RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
  • the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b.
  • the Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface.
  • the RNCs 142a, 142b may be in communication with one another via an Iur interface.
  • Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected.
  • each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.
  • the core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MGW media gateway
  • MSC mobile switching center
  • SGSN serving GPRS support node
  • GGSN gateway GPRS support node
  • the RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface.
  • the MSC 146 may be connected to the MGW 144.
  • the MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
  • the RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface.
  • the SGSN 148 may be connected to the GGSN 150.
  • the SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • FIG. ID is a system diagram of the RAN 104 and the core network 107 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the core network 107.
  • the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and/or downlink (DL), and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the core network 107 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MME mobility management gateway
  • PDN packet data network
  • the MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S I interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer
  • the MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
  • the serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface.
  • the serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP- enabled devices.
  • the core network 107 may facilitate communications with other networks.
  • the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
  • the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108.
  • an IP gateway e.g., an IP multimedia subsystem (IMS) server
  • IMS IP multimedia subsystem
  • the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • FIG. IE is a system diagram of the RAN 105 and the core network 109 according to an embodiment.
  • the RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117.
  • ASN access service network
  • the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.
  • the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment.
  • the base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117.
  • the base stations 180a, 180b, 180c may implement MIMO technology.
  • the base station 180a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • the base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like.
  • the ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.
  • the air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification.
  • each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109.
  • the logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for
  • the communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations.
  • the communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point.
  • the R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.
  • the RAN 105 may be connected to the core network 109.
  • the communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example.
  • the core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MIP-HA mobile IP home agent
  • AAA authentication, authorization, accounting
  • the MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks.
  • the MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the AAA server 186 may be responsible for user authentication and for supporting user services.
  • the gateway 188 may facilitate interworking with other networks.
  • the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
  • the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks.
  • the communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs.
  • the communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.
  • FIG. 2 depicts different example business models in 5G Networks. In some cases, different Mobile Network Operators (MNOs) may have different business models, and may provide different services to end users.
  • MNOs Mobile Network Operators
  • an MNO may be an Asset Provider, Connectivity Provider, or Partner Service Provider.
  • An Asset Provider may own a certain function of a network (e.g., partially/fully sharing the radio access network (RAN) and/or the core network).
  • a connectivity provider may be an MNO that provides network (e.g., IP) connectivity for consumers, businesses, or a wholesale/Mobile Virtual Network Operator (MVNO).
  • MVNO Mobile Virtual Network Operator
  • a partner service provider may benefit from the service features offered by a third party operator that may own mobile connectivity capabilities (e.g., customers of smart wearable devices with services of a remote health monitoring company).
  • An Asset Owner generally refers to a model where a service provider (SP) partially or fully owns infrastructure.
  • SP may own a core network while sharing a RAN with other SPs.
  • an SP shares infrastructure with other SPs.
  • Business models in 5G networks may include implementations ranging from dedicated hardware (HAV) through to cloud-based services, such as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). These various scenarios may provide SPs with different levels of control over shared infrastructure, and with a varying set of privileges over a network.
  • a connectivity provider may be an example of a cloud based ownership model, where an SP (e.g., which does not own infrastructure) may function as a connectivity broker for end SPs.
  • FIG. 3 depicts three example dimensions (network infrastructure capabilities, provider, service requirements) of innovation in 5G Networks. Each dimension may realize a variety of 5G network features. Different use cases may be formed based on user requirements and 5G network features. The elasticity of the business models in 5G networks may provide a another aspect for consideration in 5G networks.
  • Example 5G network features may include, without limitation: (i) flexibility and scalability (e.g., connection attributes such as mobility, security, privacy, reliability, latency, etc., may be enabled/disabled/modified and controlled in a programmable and switchable manner that may depend on use-cases, subscription details and associated policies defined by operators);
  • flexibility and scalability e.g., connection attributes such as mobility, security, privacy, reliability, latency, etc., may be enabled/disabled/modified and controlled in a programmable and switchable manner that may depend on use-cases, subscription details and associated policies defined by operators
  • context-awareness that may allow customization or creation of an application to match preferences of a user, e.g., based on current context such as location, time, activities and services;
  • fixed-mobile convergence where 5G may support fixed and mobile convergence, for example, to provide a seamless customer experience in fixed and mobile domains (e.g., a unified user authentication, RAN and CN independence);
  • energy and cost efficiency e.g., energy and cost efficiency;
  • operations awareness and efficiency e.g., availability and reliability (Resilience Networks);
  • 5G security may protect user privacy according to different contexts and applications.
  • Network Slicing is used, for example, to offer more granular control of performance and network features based on applications or services being used.
  • Network Slicing generally refers to providing isolated subnetworks that may be optimized for specific types of traffic characteristics.
  • An example network slice may have its own set of security and quality of service (QoS) requirements.
  • QoS quality of service
  • Some or all slices may be (e.g., completely) isolated from other slices.
  • some or all network functionalities may be virtualized and may be shared by mobile network operators (e.g., using Network Function Virtualization (NFV) and other virtualization techniques). For example, by using a more software-centric approach, costs may be shared and network utilization may be optimized.
  • 5G networks may implement novel architectures and technologies in the communications industry. Virtualization and NFV may be enablers for NS.
  • Network slices may enable a wide spectrum of use-cases in 5G.
  • a slice may refer to a set of features that achieves a use-case, for example, by taking into consideration the capabilities of the operator(s) that provide a service.
  • 5G networks may support dedicated vertical use cases, such as intelligent transportation, gaming, remote machinery and virtual reality, and the like, which may have different service requirements.
  • Virtual slices of a network may support differentiated application and services. Virtual Slices may be logical instantiations of network resources. Operators and/or service providers may support slicing, for example, by using automated management based on NFV technologies.
  • FIG. 4 depicts an example of Network Slicing.
  • a network operator may use a Network Slice Blueprint to create a Network Slice Instance.
  • An example Network Slice Instance may provide network characteristics (e.g., including layers from the Radio Access layer up to the service layer) required or utilized by a Service Instance.
  • a Network Slice Instance may also be shared across multiple Service Instances provided by a network operator.
  • Network Function Virtualization may permit building an end-to-end network infrastructure with evolving standard IT virtualization technology, for example, to enable consolidation of heterogeneous network devices onto standard high-volume servers, switches, and storage. Virtual network functionality of a network device may be implemented as a software package.
  • a Virtual Network Function may run on a (e.g., one) Virtual Machine (VM) as a VNF Instance (VNFI), or more than one VM as a VNF Component Instance (VNFCI).
  • VM Virtual Machine
  • VNFCI VNF Component Instance
  • OPEX and CAP EX may be greatly reduced, for example, as compared to current approaches, given that network functions may be executed on standard servers without requiring expensive function-dedicated devices (e.g., Media Gateways, Firewalls, etc.).
  • HW dedicated Hardware
  • SW pure software
  • Generic architectures which may accommodate some level of hardware acceleration and programmability (e.g., FPGA) may be implemented.
  • Crypto- accelerators and FPGA may be (e.g., alternatively) included in default COTS HW
  • introducing or testing a network function may be performed, in some cases, by installing or upgrading a software package that runs on network servers.
  • FIG. 5 depicts an example of NFV Layers in an example NFV architecture.
  • NFVI Network Function Virtual infrastructure
  • virtual machines are created on high-volume hardware servers and storage devices that may be connected by high-volume network switches, and organized by an orchestration (e.g., Hypervisor).
  • orchestration e.g., Hypervisor
  • NFV allows for the separation of software that defines network functions for network devices from generic hardware.
  • NFV allows for Management and Orchestration (MANO), which may automate installation and management of virtualized network functions on generic hardware.
  • MANO Management and Orchestration
  • NFV technology may permit carriers to build and operate flexible and highly configurable networks with reduced equipment costs and reduced power consumption, for example, by consolidating equipment and exploiting the economies of scale of the information technology (IT).
  • Management and Orchestration (MANO) within NFV manages
  • NFV Infrastructure to perform resource allocations for various network services
  • VNFs VNFs.
  • MANO may be involved in the management and orchestration of Network Functions
  • Virtualization Infrastructure Components that may be managed may be virtualized or partially - virtualized resources such as, for example: (i) computing infrastructure that may include computing machines and/or virtual machines having one or more CPUs and memory; (ii) storage
  • VNFs Virtualized Network Functions
  • FCAPS fault, configuration, accounting, provisioning and security
  • MANO may instantiate, scale, upgrade, and terminate VNFs.
  • MANO may be involved in the management and orchestration of Network Services, such as managing the lifecycle of network services, which may include instantiation of services, scaling (elasticity), termination of services, etc.
  • MANO may be involved in the management and orchestration of miscellaneous aspects, such as policy management and interactions with legacy or new Operations Support Systems/Business Support Systems (OSS/BSS).
  • OSS/BSS Operations Support Systems/Business Support Systems
  • FIG. 6 depicts an example NFV-MANO Architecture 600.
  • an example NFV Architectural Framework may include multiple an NFV Orchestrator (NFVO) 602, a VNF Manager (VNFM) 604, and a Virtualized Infrastructure Manager (VIM) 606.
  • the NFVO 602 may perform orchestration functions of NFVI resources across multiple VIMs and lifecycle management of network services.
  • the VNFM 604 may perform orchestration and management functions of VNFs.
  • the VIM 606 may perform orchestration and management functions of NFVI resources within a domain.
  • the NFVO 602 may interact with an OSS/BSS 608 (e.g., legacy system), for example, for provisioning, configuration, capacity management and policy-based management.
  • OSS/BSS 608 e.g., legacy system
  • the VNFM 604 may interact with an Element Manager (EM) 610 and a VNF 612, for example, for provisioning, configuration, and fault and alarm management.
  • the VIM 606 may interact with an NFVI 614 for the management and orchestration of virtualized resources.
  • SDN Software Defined Networking
  • NFV Network Function Virtualization
  • a user plane a user plane
  • a management plane for NFV.
  • SDN enables network function virtualization and network programmability, which may be protocol building blocks for the next generation of 5G networks.
  • FIG. 7 depicts an example of SDN Layering.
  • an example SDN network architecture 700 may include a centralized network controller 702 in a control plane
  • the controller 702 may be responsible for allocating traffic to network elements in a separated data plane of a network.
  • the network controller 702 may (e.g., centrally) maintain the intelligence and state of a network.
  • the network controller 702 may output fine granular flow routing control rules to heterogeneous network devices 705, which may be from different vendors.
  • the network controller 702 may provide (e.g., through a northbound interface 706) a global united view and resources of a network to upper layer network applications 708 as a single, logical switch. Network applications 708 may be created, tested, and deployed in a short time.
  • SDN protocols may enable control-plane management and may be separated from a data/user plane.
  • Open flow which is defined by Open Networking Foundation (ONF)
  • Open Flow is an example of an SDN protocol in a southbound interface 710 between the network controller 702 and network devices 705.
  • Open Flow may be supported by various device manufacturers, service providers, and operators. SDN protocols may also be provided for the northbound interface 706.
  • a WTRU or network entity may be explicitly authorized before granted access to a particular resource or service.
  • implicit authorization is assumed for a WTRU once successfully authenticated in a network.
  • associated traffic user or control plane
  • Implicit authorization may also be provided to a network function to use other resources or network functions within the same network domain, for example, based on the implied trust within an MNO predefined security perimeter.
  • FIG. 8 depicts an example of ProSe Non-Roaming Reference Architecture.
  • Proximity Services may implement explicit authorization for a WTRU for Device to Device (D2D) discovery and communication services.
  • D2D Device to Device
  • the OAuth framework may enable Clients to obtain access to one or more services from a Service Provider (SP) by leveraging trust relationships with a trusted third party.
  • the protocol includes various roles, such as a Service/ Application Owner (SO), Service Provider (SP), Authorization Server (AS), and/or Client (C).
  • SO Service/ Application Owner
  • SP Service Provider
  • AS Authorization Server
  • C Client
  • a Client may be authorized to access a service for a limited amount of time, after which the access may be revoked.
  • a given SP does not provide the Client with a common set of long-term credentials, but may provide the Client with unique temporary credentials for the client to access one or more services.
  • a trusted third-party may enable a Client to obtain access to a sub-set of services and may be restricted from accessing a complete set of services.
  • an Authorization layer separates the role of the Client from a resource owner.
  • a Client may obtain authorization, for example in the form of an Authorization Token (AT), from an Authorization Server (AS). ATs may be issued by an AS, for example, based on the approval of a Service/ Application Owner (SO).
  • a Client may use an AT to obtain access to a resource.
  • FIG. 9 depicts an example of an OAUTH protocol flow.
  • a Client 902 requests authorization from an SO 904, at 1.
  • a request by the Client 902 may be made directly to the SO 904 or indirectly via an AS 906.
  • the Client 902 may receive an authorization grant from the SO 904, at 2.
  • the SO 904 may provide grants using one or more procedures.
  • a grant type may be an authorization code (e.g., using implicit means), a service owner's password credentials, and/or Client credentials.
  • the Client 902 may request an access token from the AS 906, for example, after presenting an authorization grant (at 3) obtained from the SO 904.
  • the Client 902 and the AS 906 may authenticate one another as part of an AT request.
  • the AS 906 may issue an AT to the Client 902, for example, after verifying the authorization grant.
  • the Client 902 may request access to a service by presenting the AT to an SP 908.
  • the SP 908 may validate the AT and may (e.g., when deemed valid) provide the Client 902 with access to the service, at 6.
  • FIG. 10 depicts an example of a PUSH Authorization Model.
  • a Push model may be viewed as a more pro-active approach for obtaining authorization.
  • the Client 902 requests an AT from the AS 906 for access to service(s) offered by the SP 908.
  • the AS 906 may send the AT to the Client 902, at 2.
  • the Client 902 and the AS 906 may mutually authenticate one another, for example, before the AT is sent to the Client 902.
  • the AT may be sent over a secure connection.
  • the Client 902 may send the AT, for example using a Service Access Request, to the SP 908.
  • the SP 902 may verify the AT and may return a Service Access Response to the Client (at 4).
  • FIG. 11 depicts an example of a PULL Authorization Model. Interactions in a PULL model may be performed via the SP 908.
  • the PULL model may follow a general service access process (e.g., WiFi Access Request). In some cases, this is not suitable when the SP 908 is constrained.
  • the Client 902 tries to access service(s) provided by the SP 908.
  • the SP 908 may communicate with the AS 906 to request authorization of the Client 902.
  • the SP 908 may belong to the same administrative domain as the AS 906 or have a strong trust relationship with the AS 906.
  • the AS 906 may grant or reject the authorization.
  • the AS 906 may perform an authentication with the Client 902. Communications between the Client 902 and the AS may be traversed through the SP 908.
  • the SP 908 may grant or reject access to the service based on the response from the AS 906.
  • FIG. 12 depicts an example of an Agent Authorization Model.
  • the Client 902 may request access to a resource with an AS 906.
  • the Client 902 may have a strong trust relationship with the AS 906.
  • the AS 906 may be the identity provider for the
  • the Client 902 forwards a resource access request to the AS 906.
  • the AS 906 checks the access rights of the Client 902 and may send the service access request to the SP 908.
  • the AS 906 may include an AT within its request to the SP 908.
  • the SP 908 may verify the AT and may respond with a service access response containing one or more resources to the AS 906.
  • the AS 906 forwards the response to the Client 902.
  • FIG. 13 depicts an example of a PUSH Confirm Authorization Model.
  • the Client 902 sends a request to obtain an AT from the AS 906.
  • the AS 906 may send an AT identifier to the Client 902, for example, after an optional authentication with the Client 902.
  • the Client 902 may send an AT identifier to the SP 908.
  • the SP 908 may submit the AT identifier to the AS 906, for example, to obtain the AT from the AS 906.
  • the AS 906 may check the AT identifier and may respond to the SP 908 with the associated AT.
  • the SP verifies the AT and may send a response with an
  • the response may indicate successful access to the service.
  • FIG. 14 depicts an example of an Indirect PUSH Authorization Model.
  • the Client 902 sends to the AS 906 an authorization request for a particular resource.
  • the AS 906 may verify the request and may send an AT to the SP 908.
  • the SP 908 may store the AT and may send a response to the AS 906.
  • the AS 906 may send an authorization response to the Client 902.
  • the Client 902 may send to the SP 908 a service access request, which may contain an AT identifier.
  • the SP 908 may verify the request and the AT identifier, and may respond to the Client 902 with an
  • 5G network access control and authorization mechanisms may operate at a much more granular level (e.g., compared to other wireless communication systems), for example, based on a variety of 5G network business models and architectures that accommodate a wide diversity of 5G network services.
  • deployments models permit a network to be sliced.
  • Network functions may be deployed in realtime with network functions spanning several locations and on a variety of infrastructure, e.g., owned, leased and/or shared by third parties.
  • tremendous diversity of deployments, and variability in the services offered and the procedures for accounting and charging for the services rendered may place a burden on operators and infrastructure suppliers to provide standardized accounting and billing mechanisms that operate at a granular level of the services being offered.
  • standardizing security procedures (such as authorization) on an individual type of service or use case basis may be valuable for 5G networks, among others.
  • FIG. 15 illustrates examples of dynamic authorization triggers.
  • FIG. 15 shows an example of a service authorization state machine from the perspective of a user.
  • FIG. 15 depicts various examples of transitioning the user from an un-authorized to an authorized entity, and visa-versa, for example, to permit and deny access to a service.
  • a service is first provisioned by an operator for a user. The service at a minimum may permit an association to a particular subscription (e.g., for billing purposes).
  • Examples of dynamic authorization state transitions include, without limitation time-based, location-based, application request, service provider (SP) offer/user input, network operational thresholds, payment and group-based (role-based) authorization state transitions.
  • SP service provider
  • a WTRU may be authorized to use a service based on specific time intervals.
  • a user may be automatically authorized to use a service from 6pm-8am on week-days.
  • a user may be provided authorization for a fixed time duration (e.g., following a completed payment). For example, when the time duration during which the user is authorized expires, the authorization may be automatically revoked.
  • a WTRU may be authorized to use a service, for example, when entering and while in a given validity area.
  • a user may be automatically authorized to use a service when the user is within a specific geographic location (e.g., latitude, longitude and radius) or a Cell or WLAN coverage area.
  • Authorization to access the service may be revoked, for example, when the user leaves the particular area.
  • an application may be granted access to a network service on behalf of a user upon request.
  • an authorized third party application may obtain automatically an authorization on behalf of a user to use a service via an API call.
  • an SP triggers an instant message or in-app push notification to invite a user to use a service for free or for a fee.
  • the user may be allowed to use the network service upon a positive reply or completion of a payment.
  • a network operational threshold dynamic authorization state transition access to a network service that is reaching a pre-determined peak load (e.g., due to very high usage, such as in a stadium full of users) may be temporarily denied, for example, based on a user request to use that service. Permission to use the service may be granted for eligible users upon request, for example, when a network load falls back below a safe usage threshold.
  • a network service peak load condition may lead to revoking authorization for some active users while maintaining it for others, for example, based on a tiered system of access rules, such as by revoking authorization for some active (“bronze”) users while maintaining authorization for other active (“gold”) users.
  • a WTRU is authorized to access a service based upon a payment or subscription that an entity (e.g., user or organization) performs.
  • entity e.g., user or organization
  • an entity e.g., WTRU
  • WTRU is part of a group (e.g., admin/user group).
  • the WTRU may be automatically authorized to access a service when the WTRU is added to the group.
  • a WTRU may be added to a group, for example, based on a subscription to the group or a change in status of the WTRU (e.g., change of groups).
  • WTRUs/users assume roles (e.g., super user role, manager role, etc.) that provide different privileges based on role type. Appropriate revocation or addition of authorization privileges may be carried out, for example, when a role change occurs.
  • FIG. 16 depicts an example scenario in which a WTRU accesses a network service.
  • network service usage is restricted to authorized WTRUs/ Applications.
  • an illegitimate (unauthorized) user might be able to utilize a network service normally restricted to a certain type of users (e.g., paying subscribers, public safety agents).
  • FIG. 17 depicts an example use case in which WTRUs access one or more Network Functions (NFs).
  • NFs Network Functions
  • access to a NF be is restricted to authorized WTRUs in a multi-purpose network (e.g., slice).
  • a multi-purpose deployment may provide cost-savings as compared to legacy network functions.
  • a network serves mobile broadband and stationary low cost devices, and a stationary rogue device utilizes (hijacks) NF3 that is reserved for mobile devices.
  • FIG. 18 depicts an example use case in which a slice accesses another slice.
  • Slice 1 may be a slice with common functions that may communicate with dedicated functions of one or more other slices (e.g., common control functions communicating with user plane forwarding functions).
  • FIG. 19 depicts an example use case in which a WTRU accesses a network slice. Unauthorized access by WTRUs to a slice may be prevented in a multi-slice environment.
  • a network serves mobile broadband and stationary low cost devices, and a rogue stationary device utilizes (hijacks) slice 2 that is reserved for mobile devices.
  • authorization capabilities are scalable. For example, signaling storms (e.g., due to authentication/authorization messaging) may be prevented. Further, in accordance with various embodiments, authorization is flexible, such that authorization may be provided for highly variable security or service requirements in next generation networks. For example, a flexible authorization scheme may accommodate different granularity levels for access control, such as coarse-grained (e.g., per subscription profile/PLMN) and fine-grained (e.g., per WTRU/ Application and Network Service or NF) levels. In an example, access to a WTRU for a particular service (or slice, NF) based on events (e.g., time, location) or actions (e.g., operator, user, application) may be dynamically granted and revoked.
  • coarse-grained e.g., per subscription profile/PLMN
  • fine-grained e.g., per WTRU/ Application and Network Service or NF
  • WTRU access to a network service is provided by explicit authorization through a service specific function.
  • a dedicated function may be used to handle explicit authorization for a WTRU/ Application to use a service.
  • a dedicated Authorization Function 2002 controls access to a specific Network Service X, such that a rogue device 2004 is denied access to the functions of Service X when the device 2004 tries to utilize the network service.
  • the service request message from the device 2004 is dropped by the Authorization Function 2002.
  • WTRU access to a network service may be provided, for example, by explicit authorization through a generic framework.
  • an Authorization Function (AF or AuthF) 2102 can control access to any Network Service.
  • a rogue device 2104 is denied access to one or more network services (e.g., Service X and Service Y).
  • the AF 2102 may utilize a combination of subscription information (e.g., via HSS 2106) and access policy rules 2108 (e.g., via PCRF).
  • the AF 2102 may support faster authorization mechanism roll-out for new services as compared to current approaches.
  • the AF 2102 may provide a central view of authorization policies across services within slices or an entire network 2110.
  • An AF architecture may be flexible and extensible enough to accommodate a multitude of current and future services.
  • a WTRU that is roaming my receive access to a network service by explicit authorization through a service specific function.
  • the function may be an HPLMN interfaced with equivalent in VPLMN.
  • a dedicated function and procedure e.g., ProSe
  • ProSe may be used to handle explicit authorization procedures for a roaming WTRU/ Application to use a service.
  • a WTRU that is roaming may receive access to a network service by explicit authorization through a generic framework.
  • an Authorization Function 2202 authorizes a roaming WTRU (UE 1) for access to network services X and Y.
  • authorization is provided by an AF 2202a within a home network 2204 in collaboration with an AF 2202b in a visited network 2206.
  • the home AF 2202b may, for example, merge access policy rules from both networks 2204 and 2206, and may provide WTRU network credentials to the visited AF 2202b, for example, for billing purposes.
  • a given WTRU may be provided access to a network function (NF) via implicit authorization with sub-networking.
  • NF network function
  • an example network 2300 may be separated into separate slices or sub-networks 2300a and 2300b. Network attachment may be anchored accordingly to provide security by isolation.
  • the network 2300 (also depicted in FIG. 17) is divided into one or more mobile sub-networks (e.g., sub-network 2300a) and one or more stationary subnetworks (e.g., sub-network 2300b).
  • a network wide Authentication Function (AuF) 2302 may grant or deny access to an appropriate sub-network when devices connect to the network 2300.
  • AuF Application Function
  • sub-slices or sub-networks may maintain implicit authorization, and additional authorization processing might not be required.
  • implicit authorization with sub-networking may result in function duplication.
  • Network slicing using newer NFV/SDN techniques may depend on operator network capabilities and deployment context.
  • Network partitioning e.g., VLAN
  • a given WTRU may be provided access to a network function (NF) via explicit authorization through a generic framework.
  • an Authorization Function (AF) 2402 controls access (e.g., as an SDN control application) to a plurality of network functions, for instance each NF, within a network 2400.
  • the AF 2402 denies access to NF3
  • the AF 2402 may utilize a combination of subscription information (e.g., via HSS 2406) and access policy rules 2408 (e.g., standalone database or via HSS).
  • explicit authorization through a generic framework may accommodate single, multi-slice, and other network deployments, given that it does not dictate a network deployment model.
  • a "dynamic authorization ready" architecture e.g., via the AF 2402, in contrast with static authorization
  • Explicit authorization through a generic framework may be deployed with additional functions described herein.
  • a network slice is provided access to another network slice via implicit authorization, wherein a network 2500 is configured such that its slices are isolated from each other.
  • inter-slice switching/routing may be governed by a pre-defined configuration (e.g., SDN forwarding rules) that allow specific source-destination communication channels. For example, data traffic between NFb in Slice 1 and NF3 in Slice 2 is blocked.
  • implicit authorization with slice isolation may be "free" where inter-slice traffic might not be required, given that strict isolation recommendations and best practices may be applied for overall network security, such as prevention of side channel attacks and establishment of a minimum security baseline for slices to prevent attacks via a "weakest link" slice.
  • a network slice is provided access to another network slice via explicit authorization through a generic framework.
  • an authorization function 2602 authorizes access to a network slice (e.g., Slice 1) of a network 2600 by another network slice (e.g., Slice 2) of the network 2600.
  • the Authorization Function (AF) 2602 may control access to Network Slices as an SDN control application.
  • the AF 2602 may use operator defined slice access policy rules 2604 to block traffic, for example, from NFb/Slicel to NF3/Slice.
  • an explicit authorization may support controlled access in a slice without imposing a secure communication path across slices, for example, when using a proper decoupling of authorization and other types of traffic (e.g., control, data).
  • Similar building blocks e.g., AF
  • AF may be leveraged and generalized to control access to a slice.
  • a given WTRU may be provided access to a network slice or a predetermined group of slices via explicit authorization.
  • access may be granted for a common control plane (CP) Slice and one or more designated user plane (UP) slices.
  • CP common control plane
  • UP designated user plane
  • Access to slices by a WTRU may be determined, for example, when a WTRU attaches to the network.
  • the decision to authorize access is based on a comparison between authorization decision information and the request from the WTRU to use a service provided by a network slice.
  • the decision to authorize access may be based on the comparison of a WTRU provided Service Descriptor Document (SDD), which may also be referred as Network Slice Selection Assistance
  • SDD Service Descriptor Document
  • an Authorization Function 2702 controls access to one or more slices per WTRU.
  • the AF 2702 may be part of a default slice and/or a common portion of a set of slices in a network.
  • the AF 2702 may also be outside the MNO network.
  • the AF 2702 may be part of a third party domain, for instance controlled and hosted by a trusted third party.
  • the AF 2702 may use a combination of subscription information and access policy data to authorize access.
  • WTRU access to a network slice may be provided via explicit authorization per individual slice.
  • Access to an individual slice by a WTRU may be determined, for example, when a WTRU sends a service request to the network specifying a single NSSAI (S-NSSAI).
  • the decision to authorize access may be based on the comparison of the request to authorization decision information.
  • the request may include a requested individual slice identifier, QoS, or security level, which may be compared to one or more slices allowed at the time of network attachment, to determine a slice that can deliver the requested QoS, security level, etc.
  • the request in particular the information in the request, may further be compared to subscription profile information and local Operator policies.
  • AF 2702 may be split between a part common to several slices and a part specific to a particular slice.
  • a first level of authorization may be performed at the common part level to a check whether the WTRU can access the requested slice at a network level.
  • a second level of authorization may be performed at the individual slice level, for example, to check that the WTRU can use the service of the slice in accordance with the request (e.g., the requested QoS, etc).
  • implicit authorization includes the exchange of an authentication context object between the network and a WTRU.
  • the network may generate and provide a WTRU with a secure context object containing authentication (e.g., implicit authorization) information, for example, the first time the WTRU successfully accesses the network.
  • a network may subsequently utilize the context object provided by the WTRU, for example, to reduce or eliminate the amount of signaling when the WTRU attempts to access or re-access the network.
  • the network may generate and provide a WTRU with a secure context object containing
  • Authorization information may contain granular access permission data as needed (e.g., Slice, Network Service, NFs).
  • a network may subsequently utilize the context object provided by the WTRU to reduce or eliminate the amount of signaling when the WTRU attempts to access or re-access the network.
  • a central and generic Authorization Function may handle authorization for a plurality of services.
  • the AF may perform a bulk retrieval and caching of authorization information for one or more services (e.g., Services X, Y, and Z) for a particular user from a subscription information database (e.g., HSS), for example, the first time a WTRU requests access to a service (e.g., Service X).
  • a subscription information database e.g., HSS
  • the AF can skip requesting the subscription information database again, for example, when the WTRU requests authorization for another service (e.g., Service Y).
  • a logical Security Tag e.g., when associated with one or more Provider Entities (PEs), such as NF(s), Network Service(s) or Slice(s)
  • PEs Provider Entities
  • NF(s) Network Service
  • NF(s) Network Service
  • Slice(s) Network Service
  • a WTRU may be assigned a set of tags that correspond to PEs the WTRU can access, for example, when the WTRU successfully attaches to the network.
  • an Authorization Function (AF) 2802 with example
  • the Security Tags may enable any of the explicit authorization examples described herein, such as Network Service or
  • Tags may be assigned to NFs, for example, by programming tag information into network control functions (e.g., SDN Controller) in charge of switching traffic to those NFs.
  • tags may be assigned to NFs via network control messages (e.g., at la/b/c), which may be automated by an orchestration platform (e.g., NF deployment time or during live operation).
  • Tags may be sent over the air via control plane messages (e.g., 2a/b/c) to a WTRU/ Application to convey authorization contextual information that may help achieve a degree of network authorization statelessness.
  • An exchange may occur, for example, upon WTRU network connection, or may be triggered by an application for on- demand access.
  • Tag information may be carried in a user data packets encapsulation (e.g., 3a/b/c), for example, to assist routing of traffic towards NFs or chaining them together according to a tag driven path.
  • a Consumer Entity is granted access to a PE when they both have at least one matching tag. For example, a message sent by NF1 toward NF2 may be accepted or rejected, respectively, when NF1 does or does not have a matching tag with NF2.
  • a set of different PEs and CEs assigned with the same tag may be viewed as part of the same Logical Security Group (LSG). For example, several NFs across different slices may be grouped into the same LSG.
  • LSG Logical Security Group
  • a tag may be granted or revoked at any time from a CE or PE based on various factors (e.g., WTRU capabilities, user subscription, operator policy, operational constraints, etc.).
  • a tag may take the form of a string label (e.g., for quick lookup matching) and/or a more information rich object (e.g., JSON encoded) to convey additional attributes.
  • a tag definition may include additional information, such as authorization data, authorized QoS (e.g., allowed max bit rate, bandwidth cap, number of messages sent), a time, location scoped validity, or the like.
  • a tag and framework built around it is secured, for example, to prevent interception, tampering, or unauthorized manipulation (e.g., create, read, write, cloning, grant/revoke).
  • a tag transmitted across network locations e.g., across Internet
  • a flexible framework using tags decouples the notion of the tag from the entities to which it applies.
  • a tagged entity such as an NF may be oblivious to the fact it is tagged.
  • tag management may be centralized in the network management plane (e.g., LSG creation, application) and/or network control routing entities (e.g., LSG constrained routing). Confining tag awareness to a tag functional layer may help achieve decoupling and increase security by reducing the dissemination of tags (e.g., in transit or stored) among a limited number of actors and possible attacks around tags.
  • Explicit authorization by means of logical Security Tags applied to resources and consumers of those resources may enable authorization to be dynamic.
  • an explicit AF architecture may be realized with Security Tags that enable dynamic authorization, for example, by network propagation of tag updates.
  • Tag updates may be based on, for example and without limitation: (i) time events, (ii) location events, (iii) policy controlled events, and/or (iv) operator or user actions.
  • a time event a time of day policy event may cause authorization to a service to be enabled or disabled.
  • a geo-fence crossing event is one example of a location event.
  • a detection that an NF security is compromised causes removal of its associated tags.
  • a user is authorized to use a service in real time after the user completes a payment.
  • the system 2900 includes a Basic Connectivity Slice (BCS) 2902, which may provide basic 3G or 4G radio link connectivity and services and access to emergency services.
  • the BSC 2902 may invoke services from Common Security Functions (CSF) 2904 and/or Common Control Functions Slice 2906 (e.g., mobility/session management).
  • CSF Common Security Functions
  • SC Common Control Functions
  • a Slice Classifier (SC) 2908 may be used to select network slices 2909, for example, based on the type of service or application requested by a given WTRU 2910.
  • Slice(s) that may be assigned to a WTRU may include an IoT slice 2909a, Ultra-reliable and Critical Communications slice (URLL) 2909b, enhanced Mobile Broadband slice (eMBB) 2909c, or a default slice 2909d.
  • the CSF 2904 may be enhanced to accommodate security requirements for 5G systems, such as those described herein.
  • FIG. 30 depicts an example of a Security Functions Toolbox for
  • the Common Security Functions (CSF) 2904 functions may include, for example and without limitation: HSS/AuC 3002, EAP Function 3004, Bootstrapping Function (BF) 3006, Platform Validation Function (PVF) 3008, PKI 3010, Public Key Management Function (PKMF) 3012, Authorization Function (AF) 3014, Dynamic Access Control Policies (DACP) 3016, Token Generation Function (TGF) 3018, and Security Tag Generation Function (STGF) 3020.
  • HSS/AuC 3002 EAP Function 3004
  • Bootstrapping Function BF
  • PVF Platform Validation Function
  • PKMF Public Key Management Function
  • AF Authorization Function
  • DCP Dynamic Access Control Policies
  • TGF Token Generation Function
  • STGF Security Tag Generation Function
  • the HSS/AuC 3002 may be enhanced to accommodate 5G WTRU systems.
  • the HSS/AuC 3002 may store slice information and security properties associated with a given WTRU.
  • the EAP Function 3004 may provide an ability to perform EAP transport for authentications, e.g., using TLS, AKA, AKA' and TTLS or other procedures that may be supported by a network.
  • the Bootstrapping Function (BF) 3006 may provide for authentication and may enable setting up a secure communication channel between a Network Application
  • a Generic Bootstrapping Server may be implemented as part of a CSF.
  • the Platform Validation Function (PVF) 3008 may be used for remote platform validation of a WTRU or may enable local validation of a WTRU.
  • a PVF may be used to verify a trust- worthiness of a WTRU's platform.
  • the PKI functionality 3010 may be part of a CSF. PKI may provide an ability for a WTRU and/or applications in a WTRU, for example, to use X.509 certificates for authentication and establishment of a secure communications channel (e.g., TLS/DTLS).
  • the Public Key Management Function (PKMF) 3012 may be used for registration, generation, distribution, and management of raw public keys. This function may enable providing forward secrecy.
  • the Authorization Function (AF) 3014 may perform authorization of WTRUs to access services, for example, based on policies that have been created by the service provider.
  • the Dynamic Access Control Policies (DACP) 3016 may store policies that may be static and/or dynamic. Dynamic access policies may be updated based on a successful on-demand authorization. A given DACP may be updated, for example, when an authorization has expired.
  • a PoA e.g., token or signed message
  • a given DACP may (e.g., based on the indication) be updated and access control rules may be purged when an authorization has expired.
  • the Token Generation Function (TGF) 3018 may generate tokens (e.g., JWT, SAML) using cryptographic mechanisms. In some examples, the TGF 3018 may interact with the AF 3014 to determine the type and contents of a token.
  • the Security Tag Management Function (STMF) 3020 generates and manages security tags, for example, based on policies associated with the generation of tags. Tags may be cryptographically protected for integrity and/or confidentiality.
  • the framework 3100 includes an authorization function 3102. In some cases, authorization policies and procedures may be pre-provisioned to the authorization function 3102. External or internal authorization systems may be used with the PAF 3100.
  • the PAF 3100 includes an Access Control Policy
  • ACPF Active Function
  • policies may be updated on a regular basis (e.g., based on operator policies) and may be uploaded to one or more Authorization
  • the Authorization Function (AuthF) 3102 performs authorization based on a request from a subscriber. Authorization decisions may be based on access control policies provisioned by the ACPF 3104.
  • the AuthF 3102 may issue a "Proof-of-Authorization" to a subscriber, for example, based on authorization checks (e.g., platform attestations, authentication, etc.).
  • the AuthF 3102 may be located, for example, in a trusted third party (e.g.,
  • OTT OTT 3106 or in the MNO 3108.
  • the example Entity A may comprise a WTRU, sensor device, subscriber, or the like, which may request access to services and/or slices.
  • the PAF 3100 further includes a Service/Slice Information DB (SIDB) 3110 that may contain details concerning services/slices, such as slice- id, risk associated with access to a given slice, VNFs that form part of a slice, etc.
  • SIDB Service/Slice Information DB
  • the PAF 3100 also may include a Subscriber Profile DB (SDB) 3112 that may store a subscriber's profile information, which may include, for example, a subscriber's identity, credential-id, risk-posture associated with subscriber, preferences, subscriptions (services/slices), etc.
  • SDB Subscriber Profile DB
  • the PAF 3100 further includes one or more Enforcement Functions.
  • a given Enforcement Function may enforce policies relating to access control to services/slices.
  • the policies may be based on a Proof-of-Authorization.
  • the EFs are gate keepers that are used to perform access control to a service.
  • an EF is part of a VNF that performs certain network functions, such as malware analysis.
  • an EF may be an entity that does not part of a VNF, but performs access control policy enforcement.
  • An EF may be hosted on various network devices, such as a gateway/server (e.g., WiFi Access Point, Relying Party etc.).
  • An EF may, in some cases, be used to perform enforcement for more than one service/slice.
  • an EF is implemented as part of an Application-Specific Gateway (e.g., similar to SIP gateway or WiFi access point) or Firewall.
  • the ACPF 3104 may be provisioned with general operator policies, relevant subscriber information, and/or information on services/slices offered to subscribers, which may be collectively referred to as authorization decision information.
  • General operator policies may determine the type of slices that would be accessible, class of subscribers, type of authorization mechanisms (e.g., proof-of- Authorization), interpretation of risk to appropriate assessment mechanisms, the length of authorization etc.
  • Relevant subscriber information e.g., IMSI, subscription information, preferences and/or default services
  • Relevant information e.g., all relevant information
  • the ACPF 3104 may be able to generate authorization policies before-hand.
  • Detailed slice/services information may be provided to the ACPF 3104. Details about the slices may contain information, for example, concerning EF-Ids, and concerning a risk posture associated with the slice and/or risk posture associated with each VNF that may be access controlled by an EF. In some cases, granular authorization information associated each slice may be provided. [00170] At 1, the ACPF 3104 may generate detailed authorization rules, for example, based on subscriber information, slice information, risks associated with a slice, VNFs in a slice, etc. In an example, an authorization rule indicates that a given WTRU that belongs to certain class of device should be authenticated and that authorization should be provided to access a particular slice.
  • the ACPF 3104 may provide policy rules for the generation of a Proof-of- Authorization to a WTRU.
  • Policies may be communicated to the AuthF 3012, at 1.
  • the Auth 3012 may obtain authorization decision information.
  • Policies may be communicated between the ACPF and the AuthF using, for example, secure communications (e.g., TLS), which may involve one or more back and forth messages.
  • a WTRU requests authorization with the AuthF 3102.
  • the AuthF 3102 may receive a request from a device to use a service provided by at least one network slice.
  • the WTRU may request authorization directly or may be re-directed by a Serving Network (SN) to the AuthF 3102, for example, when the WTRU requests access to services/slices in the SN.
  • the AuthF 3102 (e.g., based on policies) may perform one or more authorization checks (e.g., authentications, platform assessments, etc.) as described herein. For example, the AuthF 3102 may compare the authorization decision to the request.
  • the request may include, for example, an identifier of the slice, a requested QoS, or a requested security level.
  • the AuthF 3102 may generate authorization information, which may be sent to the WTRU, directly or via an access control device.
  • Authorization checks may be based on the risk associated with the service(s)/slices requested by the WTRU. In an example, one or more supplemental authorization checks may be performed based on the comparison between the authorization decision information and the request.
  • the AuthF 3102 may issue one or more Proof-of- Authorizations to a WTRU. In some cases, the AuthF may only provide a Proof-of- Authorization identifier (PoA ID) that identifies a particular Proof-of- Authorization.
  • PoA ID Proof-of- Authorization identifier
  • the WTRU may submit the Proof-of-Authorization to one or more EFs.
  • submission of the Proof-of-Authorization may be performed, for example, in a serial manner.
  • the EFs e.g., EF1, EF2, and EF3
  • the Proof-of-Authorization may be processed by relevant EFs.
  • the WTRU is provided access (e.g., to a slice) once the Proof-of-Authorization (PoA) has been verified.
  • FIG. 32 An example alternative deployment model is depicted in FIG. 32, in confirmation and verification is performed at 4. Further, the issuance of a PoA at 2b is shown. Referring to FIG. 32, at 4, the claims within the PoA may be confirmed, such that it is verified that claims that have been provisioned to the Entity A (UEAVTRU) can be actually achieved based upon resource(s) within the MNO network 3108.
  • the resources may include radio, network, service, or application layer resources.
  • EFs e.g., Service / Slice
  • the Entity A is issued with a PoA id, and then the message at 4 may be used to obtain the PoA from the MNO (ACPF or another authorized entity within the MNO network). It may be assumed, in some cases, that the MNO has been provided with the PoA by the AuthF 3102 (Trusted 3rd party) at 2.
  • the MNO may proactively push a PoA to the EF(s) even before a Request Access (message 3) has been performed by an Entity. This may be particularly useful, for example, for low-latency services so that quick service setup can be established by the service provider.
  • the issuance of the PoA may be used for various purposes as desired.
  • the MNO network 3108 may be provisioned with a copy of a PoA that has been issued to the Entity A (e.g., UEAVTRU), a copy of a PoA that may be issued to an entity in the future, and/or a PoA for which only a PoA id has been issued to an
  • the Entity A e.g., UEAVTRU
  • a copy of a PoA may be issued to an entity in the future
  • a given Entity e.g., UEAVTRU
  • a service provider e.g., visiting network
  • the FIN may pre- provision the entire Subscription Profile (SP) associated with the Entity (e.g., UEAVTRU), which may be referred to herein as the Portable Subscription Profile (PSP), or relevant parts of the SP within the PSP.
  • SP Subscription Profile
  • PSP Portable Subscription Profile
  • the PSP may be digitally signed using the UN's Private Key and stored securely on the UE.
  • the PSP may also be protected for confidentiality and against replay attacks.
  • Another example is for the FIN to only provision a globally or domain specific unique identifier of the
  • PSP which can be referred to as the PSP Id.
  • This PSP Id may be a decorated identifier (e.g., of the form PSP_Idl234@FIN.com).
  • This PS Id may also be stored securely and protected for integrity, confidentiality, and/or against replay attacks by means of secure objects.
  • the FIN may also provision the UE with the HN's Public Key / Digital Certificate.
  • the Entity e.g., UEAVTRU
  • the Entity may include the PSP as part of the request or in a following message to the service provider.
  • the enforcement function (EF) at the service provider may then inspect the authenticity of the PSP by verifying the digital signature using the FIN's public key.
  • the Entity e.g., UEAVTRU
  • a request may be performed by the EF to the Entity (e.g., UEAVTRU) or the UN or to the trusted third party (TTP) requesting for UN's Public Key/Certificate.
  • a TTP may store the PSP, which may then be provisioned to the Entity (e.g., UEAVTRU) or the EFs within the service provider network in an on-demand basis.
  • the Entity e.g., UEAVTRU
  • the Entity may present both the PoA (e.g., Access Token) as well as the PSP to the EFs within the serving network.
  • the EFs may verify the authenticity and validity of PSP using the Public Key/Certificate associated with the FIN, and may also verify the authenticity of the PoA using the Public Key/Certificate associated with the AuthF/TTP. Based upon the verification of the authenticity and validity of the both the PoA and/or the PSP, the EFs may enable access to the service for the requesting Entity (e.g., UEAVTRU).
  • the AuthF/TTP may use the PSP in order to create the PoA.
  • the signed PoA may then be presented to the EFs within the serving network.
  • the PSP may be provisioned to the TTP at 1, as shown in FIG. 32.
  • the PSP may be updated OTA periodically by the Entity (e.g., UEAVTRU) or triggered by the FIN in order to synchronize the PSP with the SP. Triggering of this update and functions (e.g., TTP, AuthF) that may be involved may be governed by FIN operator provisioned policies.
  • the Entity e.g., UEAVTRU
  • FIN FIN operator provisioned policies
  • PSP Id PSP identifier
  • the PSP Id may be a decorated identifier (e.g.,
  • PSP_Idl@ttpl.com which may indicate the location (e.g., URI / URL) of the PSP.
  • a PoA may be a decorated identifier (e.g., PoA_Id@AuthF.com).
  • the PSP Id and/or the PoA Id may then be used by the EFs, Entity (e.g., UEAVTRU), or the TTP, for example, to obtain the PSP and/or the PoA respectively, on a need-basis from the stored location.
  • a Public Key identifier or a Digital Certificate identifier associated with the FIN or the AuthF/TTP may be communicated.
  • the Public Key identifier (PK_Id@ITN.com or PK_Id@AuthF.com or DigitalCert_Id@TTP.com ) or the Digital Certificate identifier may then be used by the UE and / or the EFs to obtain the Public Key / Certificate associated with the FIN or the AuthF/TTP.
  • a PoA may be a proof by which an entity can gain access to a service/slice.
  • a PoA may be issued by an AuthF.
  • a PoA may be in the form of messages (e.g., signed or unsigned), may use object security (e.g., tokens), or may be in the form of temporary certificates.
  • An AuthF may sign an authorization message, for example, by using a digital signature or by a message authentication code.
  • a signature may be based on the type of cryptographic algorithm being used (e.g., asymmetric or symmetric mechanisms).
  • a message may carry, for example, one or more the following attributes: (i) From: AuthF, (ii) To:
  • Classifier/EF (iii) Service: service 1/Slice-Id, (iv) Validity time period: Date/time validity and/or (v) Signature/MAC.
  • a message may be sent from the AuthF to a classifier, for example, instead of an EF.
  • a single message may be sent (e.g., only) to a Classifier function, e.g., rather than send separate messages to each EF.
  • a Classifier function receiving a message may issue PoA (e.g., tokens), which may be consumed by EFs (VNFs).
  • tokens may be signed or un-signed.
  • a token may have a form similar to an OAUTH Access Token and may be encoded using JSON or XML or CBOR.
  • Tokens may be a single token or may be chained or nested.
  • FIG. 33 An example Service Access Token (SAT) is depicted in FIG. 33.
  • the JWT registered claims: “iss, “sub”, “aud”, “exp”, “iat”, “nbf ', “jti” may be used according to IETF RFC 7519/7797.
  • new custom claims may be used in accordance with various embodiments, which are defined herein and presented by way of example, without limitation:
  • authentication level (authLevel): This claim may describe the level of authentication that was achieved, the value may be qualitative (e.g., None, Low, Medium or High) or quantitative (e.g., 1 (None) -10 (High)). This indicates the "subject's” authentication and the identity it is claiming to be. For privacy reasons the "subject” (entity) may use a pseudonym and that pseudonym may be authenticated without revealing the real identity of the entity. This claim indicates the level of authentication of that real identity or pseudonym.
  • security _assurance_level (assureLevel): This claim may indicate the security assurance level and if the "subject" is the platform and then it indicates the assurance level of the platform (BIOS, firmware, OS, software, applications) of the platform as a whole. If the "subject" is a subscriber, this may indicate the "trustworthiness” of the subscriber, which may include “reputation” of the subscriber.
  • authentication factors used (authF actors): This claim may indicate the actual authentication factors that were used. These authentication factors may indicate whether the subject's device (e.g., LTE_AKA, EAP-SIM..), password, biometric (finger-print, facial, iris, palm-print etc..) etc. have been used for authenticating the "subject.”
  • authorized role (aRole): This claim may indicate whether the "subject” may be a system administrator, privileged user, privileged application, privileged machine, super- user or other roles defined within the "audience's" domain. In some cases, this may not be applicable at all.
  • authorization type (authType): This claim may indicate the type of authorization that was granted or used.
  • the values may include, for example and without limitation: “role”, “attribute-based” (ABAC), “discreationary_access_control” (DAC),
  • service_type (servType): This claim indicates the type of service that the "subject" is being authorized for: eMBB, URLL, MMTC, Voice call, Internet access, etc. This may also include one or more the service types and therefore the "subject" may be authorized to more than one service types.
  • service_specific_parameters (servParams): These claims may indicate the parameters for service class / QCI for both QoS (e.g., bandwidth, latency, jitter, etc.) as well as Security requirements for the service(s) that are being requested, such as integrity and confidentiality of control plane, integrity and confidentiality of user plane, etc.
  • service_qos_parameters may contain values for bandwidth, jitter, delay, etc for the service / slice(s), for hop— by -hop as well as end-to- end cases.
  • service_security_parameters may contain the security level required for the service such as integrity and confidentiality for the service / slice(s) from both user and control planes, requirement for security at the Access Network (RAN, WiFi access etc.), security requirements at the Core Network and security requirements for end-to-end (application to service), or at each of the OSI layers (e.g., use of (D)TLS, IPSec etc.).
  • payments_parameters (payParams): These claims may indicate the amount for which a payment has been done and the type of monetary currency that was used (e.g., US Dollar, Bitcoin etc.).
  • customized claims (custClaims): These may be claims that are custom-built based upon SLAs between a Service Provider, MNO operator, or Trusted Third Party entity. These claims may be protected for confidentiality as well, for example, so that only authorized entities are able to read these claims.
  • Tokens may be chained so that each of the VNFs within the SFC may be able to verify the token intended to that respective VNF, and process the token.
  • the tokens may also be encrypted so that only that specific VNF may be able to de-crypt the token.
  • An example chained token structure is depicted in FIG. 34.
  • the AuthF may issue one or more temporary certificates, which can be used to verify authorization and additionally authenticate the UE.
  • the UE can then use the certificate to setup secure communications channel with the Classifier and/or VNFs.
  • PoAs may be exchanged to obtain long-term or short-term security credentials.
  • a token may be exchanged to obtain a certificate and a private key associated with the credential.
  • the private key may sent to the UE using secure communications channel (e.g., setup by means of TLS with Ephemeral Diffie Hellman).
  • the token may be exchanged to setup and establish a symmetric key between the UE and a trusted entity within the service provider network. These credentials may be used to generate session keys with the service provider network functions and end entities.
  • a Proactive Authorization Framework (PAF) 3500 which includes a UEl, AuthF 3502, a VNF1 (which may include an enforcement function), and a VNF2.
  • the UEl WTRU
  • the AuthF 3502 sends an Authorization Request (e.g., containing its identity and/or the application identity) to the AuthF 3502 requesting authorization.
  • the UEl may send information about requested Service(s)/Slice-Id to the AuthF 3502, at 1.
  • the AuthF 3502 may generate one or more Challenges, for example, based on policies described herein, to determine the risk and associated authorization checks that may be carried out.
  • the AuthF 3502 may send the one or more Challenges in an Authorization Response message to the UEl .
  • the Challenges may include more than authentication checks (WTRU/user). For example,
  • Challenges may include validations checks on platform integrity.
  • the UEl computes one or more results in response to the Challenge(s). In some cases, the results may be cryptographically generated or may be responses containing validation checks.
  • the UEl may send the result(s) to the AuthF 3502, for example, in an Authorization Response message.
  • the AuthF 3502 may verify the result(s) and may generate and issue appropriate PoA(s).
  • the PoA(s) may be, for example, chained tokens or a single token, as described above.
  • the AuthF 3502 may (e.g., in addition to the PoA) generate PoA usage, which may provide details on how the PoA may be used and targeted/sent to the VNFs (e.g., EFs). A single token may be issued, for example, when a classifier is present.
  • the AuthF 3502 may send the PoA(s) and associated PoA_usage to the UE1.
  • the UE1 may use PoA_usage, for example, to determine how the PoA may be appended to a slice access request message.
  • the UE1 may send a Slice Access Request message containing the PoA(s) to the Classifier/VNFs, for instance VNFl.
  • the VNFl may (e.g., upon receiving the Slice Access Request message) verify the PoA.
  • the VNFl may process the message from the UE1. In some cases, the VNFl only processes the token associated with a particular VNF, for example, when the PoA is a chained token.
  • the VNFl may determine the next VNF (e.g., VNF2) that the message may be forwarded to (at 9c).
  • the VNF 1 forwards the message to the next VNF (VNF2), for example, based on the information provided in the SFC that may have been pre-provisioned to it by the SN.
  • VNFl may remove the token associated with it. The token might not be removed, for example, when the PoA is a nested token, given that removal may affect the overall integrity of the token.
  • the VNF2 may verify the PoA (e.g., similar to the process performed by VNFl). The VNF2 may process the token associated with the VNF2 and may then process the message.
  • the message may be forwarded to another VNF or a response may be provided, for example, when VNF2 is the last entity in the SFC,.
  • the VNF2 may send an Ack back to the VNF 1.
  • the VNF 1 may also generate an Ack (which, in accordance with the illustrated example, may include both Acks, one received from VNF2 and one generated by VNFl) and may forward it to the UE1.
  • FIG. 36 an example of a Proactive Authorization Framework 3600 is shown in which the MNO 3108 is used a Trust Anchor. MNO trust may be leveraged for access to outside services. Enforcement functions (EF1, EF2, EF3) may have a trust relationship with the MNO 3108. Policies for access control to services (e.g.., Service 1, Service 2, etc.) that may be enforced by respective EFs may be negotiated before-hand between the MNO 3108 and the service providers (e.g., service may be provided by third parties other than the MNO). A PoA may be used for authorization purposes, so that an entity (Entity A) can gain access to a service/slice.
  • EF1, EF2, EF3 may have a trust relationship with the MNO 3108.
  • Policies for access control to services e.g.., Service 1, Service 2, etc.
  • service providers e.g., service may be provided by third parties other than the MNO.
  • a PoA may be used for authorization purposes, so that an entity (Entity A) can gain
  • the Entity A may request a service (e.g., service 1) from a service provider, which may have an EF1 that performs access control on behalf of the service.
  • EF1 may (e.g., based on the request from Entity A) request authorization from the AF 3102.
  • the AF 3102 may request additional authorization information from the ACPF 3104.
  • the ACPF 3104 may create consolidated access control rules, for example, based on authorization information obtained from a WTRU/subscriber profile 3112, general operator policies (e.g., obtained from a management function), and/or service/slice information 3110. In some cases, the AF 3102 may have been pre-populated with certain authorization information before-hand.
  • the AF 3102 may determine whether the WTRU (Entity A) can be authorized to access Service 1, and may send access control rules to the EF1.
  • the EF1 may use the rules to grant or deny access to Service 1.
  • the access may include various restrictions, for example, with respect to date/time, location, role, charging, etc.
  • Access control rules may specify revocation of authorization, for example, based on a change in location, time, role and/or payment, subscription, or charging information.
  • Authorization may conversely be extended, for example, when there is a change in one or more of a payment, subscription to a service, role of subscriber/user/ WTRU, location of WTRU and/or other parameters relating to authorization.
  • a UEl/Subscriber (which may also be referred to as a WTRU1, without limitation) sends a Slice Access Request containing its identity (permanent, temporary and/or protected identity) and/or the application identity to a Service Provider Network.
  • the request may be sent to network entity that works as an EF.
  • the EF may be a router, switch, application server or anything else that may perform one or more access control function(s) and may be implemented as a VNF.
  • the EF e.g., VNFl
  • the EF may also perform the role of slice classifier/router, so that messages for a certain slice can be routed to that slice.
  • the Subscriber may also send information about requested Slice(s)/Service(s)/Slice-Id(s) to the VNFl.
  • a PoA(s) associated with such a slice(s)/service(s) may be included as part of the Request message.
  • the message may indicate the level of QoS, security level, and duration for how long the service / slices are required.
  • the UE1 may be operated by a subscriber (e.g., User) of the device and therefore the terminology subscriber may be used to refer to a device, a user, or both.
  • the VNFl upon receiving the Slice Access Request message, checks authorization for the Subscriber/UEl. If there has been no prior authorization that is active and valid, then the VNFl may issue an Authorization Request message containing an id of the Subscriber/UEl and information on Service(s)/Slice-Id(s) to an AuthF. If the PoA is a chained token, for example, then the VNFl might only process the token associated to that particular VNF. The VNFl may determine the next VNF that the message may have to be forwarded to and passes it forward, as described above. VNFl then may generate a Slice Access Response, verify the PoA(s), and then process the message from the Subscriber/UEl .
  • the AuthF sends a request to the ACPF for policies and procedures for authorizing the UE1 to access particular Slice(s)/ Service(s).
  • the AuthF may send the identity (permanent, temporary, protected identity) of the Subscriber/UE as well as information about the slice(s) / service(s), QoS level, security level, and the duration for access to slice(s) / service(s).
  • the ACPF may be viewed as a repository for policies and information and of similar functionalities as a Policy Information Point (PIP) and/or Policy Retrieval Points (PRP), or the ACPF may be viewed as an entity that is capable of querying a PIP and/or PRP.
  • PIP Policy Information Point
  • PRP Policy Retrieval Points
  • the ACPF may generate Subscriber /or UE specific policies, at 4. At 5, the ACPF may send Subscriber and/or UE-specific policies to the AuthF.
  • the AuthF may generate consolidated authorization policies, which may then determine if one or more challenge(s) have to be generated in order to establish the authorization of the Subscriber/UE.
  • a challenge that is generated may be a simple query to request PoA from a UE, or in some cases, may be used to perform additional authentication checks of the Subscriber/UE. In other cases, using the RAF model, a challenge might not be generated and only the consolidated authorization policies.
  • authorization polices are generated, which may determine if the challenge(s) have to be generated at all. If the AuthF determines that the Subscriber/UEl has been authorized, for example, then the AuthF may optionally generate a PoA.
  • the AuthF may send the generated policies within an Authorization
  • VN1/EF Response message to the VN1/EF. If Challenge(s) were generated, for example, then they may be sent to the VNF1-EF as well. Also, if PoA(s) were generated, then they may be sent to the VN1/EF.
  • the EF/VNF1 may store the consolidated authorization policies and if PoA(s) were sent by the AuthF, then they may be stored as well. If the authorization policies do not require performing additional authorization checks, then the message flow may jump to illustrated Step 13 in accordance with an example.
  • a challenge is presented to the Subscriber/UEl.
  • the EF/VNF1 may send the challenge within an Slice Access Response message.
  • the UEl may compute the Result(s) using the Challenge(s).
  • Results may be cryptographically generated or may be responses containing validation checks.
  • the UEl may send the Result(s) to the AuthF in a Slice Access Request message.
  • the Results may be sent in the form of one or more PoA(s), which may be signed by a private key within the secure element (e.g., UICC, TPM, TEE) present within the UEl.
  • the VNF1/EF may verify the Result(s) using the previously stored authorization policies.
  • the VNF1 may forward the message to the next VNF (at 12c) based upon the information provided in an SFC that may have been pre-provisioned to it by the SN.
  • the VNF1 may send a message (at 12b) to the appropriate Core Network (CN) Function and/or Access Network (AN) Functions indicating reservation of appropriate network resources in order to be able to serve UEl/Subscriber's' service access request.
  • the message may optionally contain one or more PoA(s), or it may send appropriate resource reservation messages to the CN and/or AN functions.
  • the VNF may send a Slice Access Response message indicating successful authorization.
  • service(s) may then be offered via slice(s) to the
  • FIG. 39 shows another example of high-level authorization procedures described herein.
  • a high-level authorization procedure may be implemented in a distributed or centralized manner.
  • Functionalities described herein may be implemented, for example, by enhancing functionality in a variety of authorization architectures to provide authorization for 5G systems using dynamic authorization schemes.
  • a Policy Information Point may contain information about various attributes that may be used for determining authorization.
  • attributes may include, for example, subscriber profile information, slice/service information, device information, etc.
  • the PIP may include, for example, HSS, NSMF, etc.
  • a Policy Retrieval Point may be a function used by an entity that hosts one or more of general operator policies, slice/service policies, subscriber and device policies, general security policies (e.g., authorization/authentication), etc.
  • a PRP may be, for example, a
  • a PRP may aggregate various policies for slice/service access, for example, to create a policy rule that may be used by a PDP.
  • a Policy Decision Point may be a function that makes a decision based on authorization decision information, for example different policy rules generated by the PRP, or WTRU subscription information. An authorization decision may be made by comparing the authorization decision information to a WTRU's request.
  • a PDP function may be performed by an AF.
  • An AF may be, for example, a ProSe Function.
  • a PDP/AF may generate, for example, based on authorization checks, an authorization decision output or authorization information.
  • the authorization information may be sent to the WTRU that requests access to a slice, for instance directly to the WTRU or via an access control device.
  • the authorization information may include a proof-of-authorization or an authorization grant decision.
  • the authorization information may be in the form of a PoA, or may include an acceptance or denial of the access request, or may include a request for additional information, which may be in the form of a PoA, an acceptance/denial of access or a request for additional information.
  • a PDP may be located in the domain of the Operator or may be part of a Trusted Third party network.
  • a Policy Enforcement Point may be a function that enforces policies.
  • a PEP may provide access to a service, e.g., based on verifying PoA.
  • an eNB or MME may be the entity that provides PEP.
  • PEP functionality may be performed by a WiFi access point, e.g., for WiFi access.
  • the WTRU may request authorization for access to a service (e.g., Prose Direct Discovery and/or Direct Communication) from the AF.
  • a request may be sent during and/or after WTRU attachment to the network.
  • a request (response) may be transported over a signaling protocol (e.g., NAS) or over the user plane (e.g., IP), for example, when a WTRU was granted an appropriate bearer (e.g., default bearer) in a prior attachment.
  • a signaling protocol e.g., NAS
  • IP user plane
  • the PDP/AF may obtain authorization rules from a PRP (e.g., PCRF).
  • the AF may request authorization rules using a reactive process.
  • the request for rules may be formed after receiving an authorization request from a WTRU.
  • the PDP may create a specific request to the PRP (PCRF), for example, based on the request from the WTRU.
  • Authorization rules may be generated beforehand, e.g., in a proactive manner. Rules may be pre-populated or subsequently populated.
  • a PRP may obtain policies, subscriber information, device information, slice/service information etc. from PIP, which may involve various data sources (e.g., HSS, HSS
  • the PRP may aggregate various policies and generate authorization rules.
  • the process may be a pro-active process or may be a reactive process.
  • the PCRF may have generated rules beforehand and may provide the rules to the PDP.
  • the PRP may perform the generation of rules based on a request from the PDP.
  • an authorization decision may be made by comparing a request for service access to one or more of policies or rules.
  • an AF uses an Access Control List (ACL) to perform a first level of authorization.
  • the ACL may be created by the ACPF or by the AF.
  • the ACL may be included in one or more of a UE subscription profile, types of service access information, slice information, or general operator policies.
  • the AF may check the ACL to determine if a UE should be allowed access to the requested service.
  • the AF may provide authorization information that indicates an authorization grant decision.
  • the indication of the authorization grant decision may comprise a binary authorization to allow access or not.
  • the ACL may also include supplementary information that indicates whether supplementary authorization checks, for instance a supplemental dynamic authorization, should be carried out.
  • supplemental authorization may include, for example, checking the various requested service parameters against those available from one or more slices, performing or verifying authentication of the UE's platform identity, determining the integrity or trustworthiness of the UE's platform (e.g., verifying the software version, patches installed, etc), performing or verifying a user authentication, determining the subscription of the UE, soliciting a pre-payment for the requested service, determining a risk associated with the UE accessing the requested service, etc.
  • the AF/UE may invoke the services of other functions to perform the authorization checks.
  • the secondary (supplemental) authorization checks may result in allowing the UE to access the requested service from one or more NSs, and each NS may be authorized independently. In some cases, if one or more of the checks fail, the ultimate authorization decision may be to deny access.
  • the result(s) of the authorization checks which may be generally referred to as authorization information, may be returned in a response message to the
  • the authorization information that is sent to the UE includes a PoA, which may capture the authorization result as well as include additional information elements that may provide more granular information with respect to the authorization.
  • a given PoA may be required to be consumed immediately to consume a service, or a given PoA may be permitted to be used at a later time to consume the requested service.
  • the AF may (e.g., based on rules obtained by the AF) perform one or more additional or supplementary authorization checks.
  • a WTRU may be
  • the WTRU's platform may be checked for integrity, a subscriber may be authenticated (e.g., using multi-factor authentication mechanisms) and/or the subscriber may be requested to show proof of payment or subscription.
  • the procedure may be based on the risk assessment associated with the service request.
  • the AF may (e.g., based on the results of the authorization checks) provide a PoA to the WTRU.
  • the PoA may be in the form of one or more Access Tokens (e.g., chained, nested), a signed message or a digital certificate.
  • the type of PoA may be based on the capabilities associated with the PEP (e.g., eNB, MME) in the service provider network.
  • a signed message may be provided by the AF to the EF using secondary channels, for example, when the eNB is unable to process an Access Token.
  • a signed message may be sent, for example, using a backbone network without involving a WTRU.
  • a WTRU may be able to request a certain type of PoA based on limitations/capabilities of the WTRU.
  • a PoA may be provided to the WTRU using a secure communications channel.
  • the AF may request the PRP/PCRF to update the subscription profile of the WTRU with the new authorization results.
  • the subscription profile may be stored in HSS.
  • the WTRU may store the PoA, for example, depending on the type and validity of the PoA.
  • the PoA may be usable one or more times and may (e.g., in certain cases) be used with different EFs.
  • the scope of a PoA may be enumerated in the PoA.
  • the scope and usage of an access token may be described in the token using JSON encoding.
  • the PoA may be stored in a secure manner.
  • the WTRU may present the PoA to the PEP/EF (e.g., eNB, MME).
  • PEP/EF e.g., eNB, MME
  • an EF may be an entity in the RAN, such as an enhanced eNB that may be able to process the PoA.
  • An EF may be an entity in the core network (e.g., MME function) that may be able to process the PoA.
  • a WTRU may not present the PoA.
  • the PoA may be provided to the EF by the AF using a backbone/core network (secondary channels).
  • the PoA may apply to the serving PLMNs and to PLMNs determined by the HPLMN as local PLMNs.
  • a WTRU may present the PoA to the EF using a secure communications channel.
  • a request may (e.g., alternatively) be sent during and/or after WTRU attachment to the network.
  • the request (response) may be transported over a signaling protocol (e.g., NAS) or over the user plane (e.g., IP), for example, when the WTRU was granted an appropriate bearer (e.g., default bearer) in a prior attachment.
  • a signaling protocol e.g., NAS
  • the user plane e.g., IP
  • the EF may verify the PoA and may determine the type of service access that has to be provided to the WTRU.
  • the EF and AF may share a trust relationship.
  • the EF may be able to verify signatures generated by an AF.
  • the EF may be provisioned with the public key/certificate of the AF or they may have established a symmetric key with one another, e.g., with a certain lifetime.
  • the EF may optionally create an Access Control Policy local to the EF, e.g., based on the information provided as part of the access token.
  • the ACP may be used for future service access requests by the same WTRU.
  • Future requests for service access by WTRU may not have to undergo the whole authorization procedure(s), for example, when the EF has a valid ACP (e.g., an ACP that is accurate and has not expired).
  • the WTRU may not have to present access token(s), for example, when a valid ACP is present.
  • the creation of ACP may reduce the overall messaging overhead on the WTRU and AF.
  • the EF may manage the ACPs, which may become cumbersome, for example, when there are a very large number of WTRUs that request a wide range of services. Managing and use of ACPs may be determined based on policies of the service provider.
  • the WTRU/ Application on WTRU/Subscriber may be provided access to the service, for example, after the EF verifies the PoA.
  • a service may be restricted.
  • a service may be a discovery service (e.g., of ProSe) rather than an announced service.
  • FIG. 40 depicts an example of a Proof-of-Authorization (PoA), in particular a Service Access Token.
  • PoA Service Access Token
  • a token may comprise a header, claims, and signature fields.
  • fields may include one or more of the following: typ, kid, alg, iss, sub, aud, exp, iat and/or jti.
  • a "typ" field may indicate that a token is encoded based on the JSON Web Token (JWT) standard or CBOR Web Token (CWT).
  • JWT JSON Web Token
  • CWT CBOR Web Token
  • a CWT may be used, for example, for WTRUs that may have constrained resources for computing, memory and/or battery.
  • a "kid" field may indicate a credential identifier associated with the AF and may indicate either a certificate id, public key identifier and/or public key may be used as the kid.
  • the kid may be a credential identifier associated with a symmetric key.
  • the kid may uniquely identify a public key credential associated with AF.
  • a kid may identify a credential associated with the AF and the eNB/MME.
  • An “alg” field may represent the type of algorithm to be used to generate the signature.
  • "RS256” may indicate that it uses the RSA algorithm using a 256 bit hash.
  • An "iss" field may indicate that the issuer is an AF located or associated with ttp.com (trusted third party).
  • a "sub" field may indicate the actual subject requesting authorization.
  • a subject requesting authorization may be WTRUl@att.com.
  • This field or attribute may contain the IMSI, temporary ids (e.g., TID), etc.
  • An "aud” field may indicate an intended audience of the token.
  • the audience may be eNBl@att.com, eNB2@att.com or MMEl@att.com.
  • the "aud” may, for example, imply that WTRU1 has been authorized to access the service using eNBl, eNB2 or MME1 that resides in the ATT trust domain.
  • the "aud” may be a list of EFs.
  • the "aud” may have values that may belong to a different operator (e.g., Visited PLMN), which may indicate that a WTRU has been authorized to access services using eNB in a different PLMN.
  • Visited PLMN Visited PLMN
  • An "exp" field may indicate when access to a service may expire.
  • An "iat" field may indicate an issuing date by the AF for an access token.
  • a "jti" field may indicate a unique token id.
  • Claims may be referred to as Service-Specific Claims (SSC).
  • SSC Service-Specific Claims
  • claims are used for access control for a particular class of service and/or individual service(s).
  • a token may describe claims related to a ProSe service.
  • the token structure is generic enough so that it may be tailored to individual services.
  • SSCs may include one or more of the following: serv, pro-app code and pro code suf. Security specific claim relating to authenticity of the token by including one or more signatures represented by "sig.”
  • a "serv" claim is a custom claim that indicates the service for which the WTRU has been authorized. This may include a list of one or more services. Examples of services that may be authorized include, without limitation, ProSe Discovery, which may be indicated by prose disc, ProSe Announce, which may be indicated by prose annoc, etc. A claim may contain multiple services, such as ProSe, real-time video, MBMS, etc.
  • a "pro app code” claim may be specific to ProSe and may contain the ProSe application that has been authorized.
  • a custom claim relating to MBMS may (e.g., similarly) be included (e.g., in addition or alternative to ProSe).
  • a "pro code suf' claim may be similar to a "pro app code” claim.
  • a "pro code suf ' claim may be specific to ProSe and may be used for performing access control by the EF (e.g., eNB, MME).
  • a Service Access Token contains various security claims.
  • a "sig" claim may indicate a signature of the message generated by the AF.
  • the signature may be created by hashing the token claims using hashing algorithm (e.g., SHA-256) as inputs and digitally signing the hash using a private key associated with the AF's public key.
  • hashing algorithm e.g., SHA-256
  • Token/claims may be transmitted as a JSON object used as the payload of a JSON Web Signature (JWS) or as the plaintext of a JSON Web Encryption (JWE) structure, which may be digitally signed or integrity protected using a Message Authentication Code (MAC) and/or encrypted.
  • JWS JSON Web Signature
  • JWE JSON Web Encryption
  • the token may alternatively be transmitted using a secure connection channel (e.g., TLS).
  • FIG. 41 illustrates an example of an authorization architecture 4100 for a plurality of independent MNO services (Services X, Y, etc.) with caching capabilities, for example, by a centralized AF 4102.
  • a tiered authorization is provided for each service.
  • the AF 4102 may act as a central anchor point for MNO services basic level authorization (Tier 1) and application level authorization by a third party Application Server (Tier 2).
  • Tier 1 authorization may bind MNO service usage to a particular subscription, which may be conditional based on device capabilities.
  • Tier 2 authorization may bind a particular application session (e.g., mobile app session) to an MNO service session and associated network resources that may have been allocated for it (e.g., radio resources).
  • authorization may be provided (e.g., generically) for MNO services and applications enabled by MNO services, e.g., in contrast to ProSe, which may be specific to a particular MNO proximity service.
  • the AF 4102 may obtain access subscription information from a Subscription Database (SDB) 4104.
  • the AF 4102 may obtain services information from a Service Directory (SD) 4106.
  • SD Service Directory
  • the SD 4106 and the SDB 4104 may be integrated with each other (e.g., evolved HSS augmented rich service data description).
  • a separate SD may offload a critical node (e.g., SDB) for service details storage and maintenance.
  • the AF 4102 may interact with the SDB 4104 and the SD 4106 via a Subscription and Services Information Broker (SSIB) 4108.
  • SSIB Subscription and Services Information Broker
  • the AF 4102 and the SSIB 4108 may be co-located/integrated.
  • the SSIB 4108 may act as a facade of the SDB 4104 and/or the SD 4106 for the AF 4102.
  • the AF may use a Service Authorization Cache (SAC) 4110, which may contain authorization information derived from SDB/SD data.
  • the SAC 4110 may enable faster authorization operation and/or reduce signaling overhead towards the SDB/SD.
  • a WTRU (UE) 4112 may use an operator service enabled application with an Application Server (AS) (e.g., AS 4114a and AS 4114b) to communicate with the AF 4102.
  • AS Application Server
  • the AF 4102 may authorize/configure the UE 4112 for a particular operator service (e.g., Tier 1 authorization), for example, based on: (i) user authorization information and/or (ii) Access Policy Rules 4114 that may include device capabilities criteria.
  • a particular operator service e.g., Tier 1 authorization
  • the AF 4102 may grant a WTRU/ Application access to a particular operator service (e.g., Tier 2 authorization) based on, for example and without limitation: (i) prior WTRU Tier 1 authorization context and/or (ii) authorization verification conducted with the AS for the application.
  • the AS may maintain a binding between the operator service and application sessions.
  • FIG. 42 shows an example of a tiered authorization 4200 is shown.
  • Fig. 42 shows an example of a tiered authorization for a plurality of independent MNO services (X, Y, etc.) with caching capabilities provided by the Centralized AF 4102.
  • the example authorization may include a user subscription being provisioned (e.g., on the network side) with a list of services (Services X, Y, etc.)
  • an application may be pre-configured on the UE 4112 (e.g., App installed on phone, user signed in with Application Server 4114).
  • the UE 4112 may consume a service, for example, when the UE 4112 is pre-configured by an operator with Service authorization and configuration information (e.g., in ME/UICC).
  • Service authorization and configuration information e.g., in ME/UICC
  • An example use case this consumption may be for Public Safety WTRUs in ProSe with direct communication/discovery capabilities "out of the box" without the need for additional OTA authorization/configuration.
  • Authorization Enforcement points may be setup in the network (e.g., in the
  • the UE 4112 requests authorization to use Service X on behalf of the user.
  • An MNO User Id may be, for example, an IMSI.
  • Service X may be a name or object describing a service (e.g., "ProSe").
  • a request may be triggered by an application (e.g., fresh start) or implicitly by a middleware or an OS service (e.g., at device boot) on behalf of one or more applications that might use a common service on a device.
  • a request may also be triggered to renew an expiring or expired
  • the AF 4102 may look up the SAC 4110 for an entry associated with a particular user to check whether the user is authorized to use service X. An entry might not be found, for example, when it is the first time connecting (e.g., new activation), or when the cache entry has expired (e.g., out of coverage for a long time, no authorization renewal in validity period).
  • a pre-caching of service authorization information for the user may be (e.g., alternatively) performed, for example, when a user first authenticates with the network. This may be realized, for example, by a notification from the Subscription and Service Information Broker (SSIB) 4108 toward the AF 4102 during a network attachment procedure.
  • SSIB Subscription and Service Information Broker
  • the AF 4102 may request the SSIB 4108 for a particular user and service.
  • a flag for bulk retrieval may be set to retrieve other services that may be provisioned to the user.
  • the SSIB 4108 may forward the request to the SDB 4104, which may return the list of services authorized for the user.
  • the SSIB 4108 may request detailed service information for one or more of the services from the SD 4106.
  • the SD 4106 may return the list of detailed service information, which may contain the list of applications authorized to utilize a particular service.
  • Application information may contain its unique id, a third party AS address (e.g., URL) and/or additional elements, such as application supported service enabled commands (e.g., ProSe "announce," "monitor").
  • An AS address may be implicit in an application (e.g., a decorated app name).
  • the SSIB 4108 may return to the AF 4102 the list of detailed service information authorization for the User.
  • the AF 4102 may write user service information into the SAC 4110.
  • Cache entries may be assigned an expiration, for example, based on caching configuration and/or operator policy.
  • the AF 4102 may generate a Service Unique Id (UID) for the service session, which it may map to the MNO User Id (e.g., IMSI).
  • User Id e.g., IMSI
  • Authorization Enforcement points may be setup in the network (e.g., in the RAN/eNodeB via MME and/or in the Core via PCRF).
  • the AF 4102 may return an authorization response to the UE 4112.
  • a response may contain, for example, the Service UID and a service session validity time.
  • a response may contain other configuration elements, such as a validity area (e.g., authorized
  • the UE 4112 may communicate the Service UID to an application server, for instance AS 4112a. Communication may be application/service specific.
  • the AS 4112a may return an App UID to the UE 4112 and may keep a mapping to Service UID.
  • the UE 4112 may request authorization to use Service X by a particular application.
  • a request may be triggered, for example, by a user interacting with the application or by an IoT device on an environmental trigger (e.g., sensor).
  • Parameters provided may include an application Id, which may allow the AF to know which AS to reach), the application supported service enabled command (e.g., ProSe "announce,” “monitor”) and/or the App UID (e.g., when previously obtained from the Application Server).
  • the App Context/ API Object parameter may, for example, be encoded using JSON or XML to accommodate a multitude of different services and their specific commands.
  • the AF 4102 may look up the SAC 4110 for an entry associated with a particular user, for example, to check whether the user is authorized to use service X.
  • SAC 4110 may return an entry that confirms the user is authorized to use Service X with a particular Application.
  • the AF 4102 may request (e.g., based on AF policy and API object content) further authorization from the AS 4114a associated with the particular application (at 11a).
  • the AS 4114a may return an authorization response that may include the Service UID corresponding to the App UID, for example, when the App UID was provided in the request.
  • the AF 4102 may check whether a service UID is associated with a particular user, for example, when the Service UID is present in the response.
  • the AF 4102 may cache AS authorization data into the SAC 4110. A cached entry may be exploited for subsequent requests, for example, to avoid requesting the AS again (e.g., app restart).
  • Authorization Enforcement points may be setup in the network (e.g., in the RAN/eNodeB via MME and/or in the Core via PCRF).
  • the AF 4102 may return an authorization response to the UE 4112.
  • a positive response may constitute a Proof of
  • PoA Policy/Demand Generation
  • PLMN Public Land Mobile Network
  • the App Context Response may, for example, be encoded using JSON or XML to accommodate a multitude of different services and their specific response.
  • the UE 4112 may consume the service with App A. It will be understood, as depicted at 14-17, that the UE 4112 may access another Service (Service Y) sought by another application (App B) that is associated with a different AS (AS 4141b).
  • Service Y Service Y
  • AS 4141b AS 4141b
  • Table 1 shows an example mapping of parameters between a generic tiered authorization procedure and ProSe.
  • the update/revocation 4300 may be triggered by a subscription update, for instance an update to the user subscriber profile in the SDB 4104.
  • Service authorization or revocation may be carried out automatically, for example, based on change in status of the WTRU/user/application. Examples of change in status may involve, for example, change in location of the WTRU (which may be inferred using GPS location information), depletion of credit (e.g., dollar amount), date/time, change in role, etc.
  • the UE 4112 may be authorized and configured for MNO Service X, for example according to an authorization 4200.
  • MNO Service X with other services related subscription data may be updated (e.g., change of PLMN or Region where service is authorized or service subscription termination).
  • the SDB 4104 may send a Service Subscription Update Notification for the User to the SSIB 4108.
  • the SSIB 4108 may retrieve (e.g., from the SD 4106) detailed data associated with affected Services.
  • the SSIB 4108 may send (e.g., to the AF 4102) a Service Information Update Notification for the User.
  • the AF may update related data in the SAC 4110.
  • the AF 4102 detects that the user has an active authorization for Service X.
  • the AF 4102 may send a Service Information Update Notification to the UE 4112, for example, immediately or when the UE 4112 communicates with the AF 4102 again, for example, based on Access Policy Rules to update or revoke authorization information.
  • the UE 4112 (WTRU) may update authorization information accordingly.
  • FIG. 44 depicts another example of an Authorization Update/Revocation 4400 that is triggered by the AF 4102 (e.g., Operator Policy).
  • the AF 4102 may update authorization data for a User for Service X, for example, in response to operator policy.
  • the AF may update related data in the SAC 4110.
  • the AF 4102 may send a Service Information Update message to the SSIB 4108 for the impacted User.
  • the SSIB may forward the message to the SDB 4104, which may update service subscription data accordingly.
  • Multi- domain authorization with distributed enforcement may be applied to CP/UP traffic flows, using an SDN architecture 4500.
  • the example SDN architecture includes a distributed AF 4502 for CP/UP access control enforcement.
  • the a centralized AF 4502 may handle authorization for a WTRU 4504.
  • the centralized AF 4502 may be implemented, for example, by an Access Control Policy Function (ACPF) 4506 and Enforcement Function (EF) 4508 sitting on top of an SDN infrastructure 4510.
  • ACPF Access Control Policy Function
  • EF Enforcement Function
  • distributed authorization enforcement may be applied to a network.
  • the WTRU 4504 may access a service provided by a Network Slice (NS) that spans across multiple Network Domains.
  • NS Network Slice
  • Slice #1 spans across two different Network Domains (ND #1 and ND #2).
  • the network domains may have a master-slave relationship.
  • ND #1 may act as the master domain.
  • the AF 4502, within ND#1) may handle authorization to access a service (e.g., slice) on behalf of the WTRU 4504.
  • the AF 4502 may be a third party application server (e.g., outside the operator network domain).
  • the ACPF 4506 (e.g., PCRF in ND#1 and ND#2) may control and centralize the policy decision with regard to slice/service access control.
  • the ACPF 4506 may use one or more input parameters (e.g., operator defined polices, network real-time operational status, user subscription, device capabilities, etc.), for example, to generate policy rules that may be provided to the EF 4508 for enforcement.
  • input parameters e.g., operator defined polices, network real-time operational status, user subscription, device capabilities, etc.
  • the EF 4508 may enforce traffic handling policy rules received from the PCRF on data forwarding infrastructure, which may be realized by an SDN Switch Fabric 4510 (e.g., one SDN Controller per domain with a set of Routers/Switches).
  • the EF 4508 may act as an SDN Application on top of an SDN Controller
  • a central User/WTRU DB 4512 (e.g., UUDB or HSS in ND#1) may be queried by the ACPF 4506 for user/device identification and profile information.
  • a central User/WTRU DB 4512 e.g., UUDB or HSS in ND#1
  • ACPF 4506 may be queried by the ACPF 4506 for user/device identification and profile information.
  • Network Slice Management Function (NSMF) 4514 (e.g., ETSI MANO in ND#1 and ND#2) may be in charge of NS deployment/management (e.g., M messages).
  • NSMF Network Slice Management Function
  • OCS 4514 may provide real-time charging, for example, using session events or flow data usage counters from the ACPF/EF, or by enabling dynamic authorization policies in ACPF based on real-time credit control.
  • the UE 4504 sends a request to a network to use or access a particular service in Slice#l .
  • a request may be sent during and/or after UE attachment to the network (e.g., in a 3 GPP network).
  • the request may be transported over a signaling protocol (e.g., NAS) or over the user plane (e.g., IP), for example, when the WTRU is granted an appropriate bearer (e.g., default bearer) in a prior attachment.
  • the request may be forwarded to the AF 4502 in ND#1.
  • Request forwarding may be accomplished (e.g., in a 3GPP network), for example, by the serving eNodeB, which may query a DNS service for AF selection.
  • the AF 4502 may forward the authorization request to the ACPF 4506 to verify User and/or Device authorization for the particular Service.
  • the ACPF 4506 may verify against the UUDB 4512 for User/Device authentication and authorization.
  • the ACPF 4506 may also verify against a CF, for example, to make a policy decision based on a subscriber charging status (e.g., user spending limit).
  • the ACPF 4506 may obtain from the NSMF 4514 detailed information concerning how the service is realized in the network infrastructure.
  • the detailed information may include, for example and without limitation, Service Function Paths (SFPs) rendering the chaining of the CP and UP NFs that may provide the service to the WTRU.
  • SFPs Service Function Paths
  • the detailed information may include, for example, Real-time network usage data, e.g., to check that enough network resources may be available to provide the desired QoS to the user.
  • the ACPF 4506 may generate a unique Security Tag per traffic type (CP or UP), e.g., to assist with subsequent SDN based traffic labelling/routing enforcement.
  • CP or UP unique Security Tag per traffic type
  • a Security Tag may be signed and bound to a WTRU (e.g., UE 4504), and may use the ACPF's private key for added security, e.g., to provide integrity/authenticity to the tags.
  • CP and/or UP traffic may be transmitted using a secure communications channel such as IPsec connection, which may provide integrity and/or confidentiality, for example, when the connection spans more than one administration domain.
  • the tag may be bound to contextual information to form an overall Authorization Context Information (ACI).
  • ACI Authorization Context Information
  • Contextual information to which a tag may be bound may include, for example: (i) User/Device Identification (e.g., IMSI, IMEI, IP address, etc.) and/or (ii) End-to- end SFP (CP or UP) in the slice providing the service (e.g., ordered set of NFs in the NS).
  • User/Device Identification e.g., IMSI, IMEI, IP address, etc.
  • End-to- end SFP CP or UP
  • the ACPF 2506 (in ND# 1 ) may detect from the NSMF 4514 information that a portion of the SFPs (e.g., CP-NF2, UP-NF3) may be under the control of another domain (e.g.,
  • the ACPF 2506 may send an authorization request to the appropriate remote ACPF in ND#2.
  • the request may include, for example, full ACI for cross domain consistency (e.g., same tag for traffic labeling, uniform user identification for charging (e.g., IMSI or WTRU source IP)).
  • ACPF-ACPF communication across domains may be secured (e.g., using IP sec tunnels).
  • the ACPF in ND#2 may retrieve related network/slice information from an NSMF in ND#2 to validate the request from ACPF 2506 in ND#1 against network resource availability and in accordance with operator policies and QoS requirements.
  • the ACPF in ND#2 may return an authorization response to the ND#1 ACPF 2506.
  • the ACPF in each domain may, when access is granted across domains, send traffic handling policy rules with associated ACI to its respective EF. Actions performed by the ACPFs may occur in parallel with each other.
  • the EF 4508 may program the policy rules into the SDN Controller in the form of classification and flow forwarding rules (e.g., ⁇ match, action> pairs), respectively (e.g., invoking appropriate NBI commands).
  • the EF in ND#2 may perform the same action in its domain.
  • the SDN Controller may push classification and flow forwarding rules to the Classifier and Switches (e.g., using OpenFlow commands).
  • the ACPF 2506 sends an authorization response to the AF 4502.
  • a code describing a reason for the authorization decision may be provided, for example, when access is denied.
  • a session starting event may be communicated to the CF, e.g., for charging purposes.
  • a Security Tag may be used for correlation between the various functions (ACPF/EF/CF) and may enable charging granularity on an individual data flow basis.
  • the AF 4502 may forward to the UE 4504 an authorization response (e.g., with PoA).
  • the UE 4512 may generate CP related traffic (e.g., mobility tracking).
  • the Classifier may (e.g., upon receiving a first CP packet of a flow) inspect the CP packet to detect the source User/Device, e.g., to try to match it with its classification rules.
  • the classifier may (e.g., when a matching rule is found for an authorized packet) label an authorized packet with a corresponding CP Security Tag and may be forwarded to the next hop switch.
  • the classifier may (e.g., when no match is found) drop the packet or forward it to a predetermined destination, e.g., for network forensics purposes.
  • a switch may receive a packet and try to match it against its flow rules.
  • a switch may (e.g., when a matching rule is found for an authorized packet (e.g., a Security Tag in packet matches a flow entry)), forward an authorized packet to the next hop switch or NF according to the specified SFP.
  • a switch may (e.g., when no match is found) drop the packet or forward it to a predetermined destination, e.g., for network forensics purposes.
  • Examples of data the EF 4508 may collect in real-time from the SDN
  • Controller to be forwarded to the CF includes, without limitation: (i) initial packet events for session or time based charging; and (ii) per CP/UP flow data usage counters for volume based charging.
  • the UE 4504 may generate UP related traffic (e.g., application data).
  • the Classifier may (e.g., upon receiving a first UP packet of a flow) inspect the UP packet to detect the source User/Device, e.g., to try to match it with its classification rules.
  • a classifier may (e.g., when a matching rule is found for an authorized packet) label an authorized packet with a corresponding UP Security Tag and forward to the next hop switch. When no match is found, the classifier may drop the packet or forward it to a predetermined destination, e.g., for network forensics purposes.
  • a switch may receive a packet and may try to match it against its flow rules.
  • a switch may (e.g., when a matching rule is found for an authorized packet (e.g., a Security Tag in packet matches a flow entry)), forward an authorized packet to the next hop switch or NF according to the specified SFP.
  • a switch may (e.g., when no match is found) drop the packet or forward it to a predetermined destination, e.g., for network forensics purposes.
  • CP and/or UP traffic may be transported in secure tunnels that may be established through dedicated secure gateways on domain edges or through the NFs themselves (e.g., CP-NF1 ⁇ -> CP-NF2).
  • the AF 4502 may revoke authorization by canceling it via the ACPF 4506 through the EF 4508, which may clear the SFP authorization rules programming from the SDN Controller, which may, in turn, delete related classification/flow entries from the classifier/switches.
  • the AF 4502 may dynamically update authorization information for an active session through the ACPF 4506, which may ensure the update trickles down through Classifier/switches (e.g., add/remove an NF in the SFP).
  • Processes and instrumentalities described herein may apply in any combination and may apply to other networks and wireless technologies. Although features and elements (including procedural steps) described herein in various examples may be shown or described in particular combinations and/or orders, each feature and element may be used alone or in any combination and in any order with and without other features and elements. Although examples provided herein may pertain to New Radio (NR) or 5G-specific protocols, subject matter described herein is not limited to provided examples or referenced communication technologies. Subject matter herein is applicable to a wider variety of examples and implementations, including in other wireless systems.
  • NR New Radio
  • 5G-specific protocols subject matter described herein is not limited to provided examples or referenced communication technologies. Subject matter herein is applicable to a wider variety of examples and implementations, including in other wireless systems.
  • a WTRU or UE may refer to an identity of the physical device, or to the user's identity such as subscription related identities, e.g., MSISDN, SIP URI, etc.
  • WTRU may refer to application-based identities, e.g., user names that may be used per application.
  • the processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor.
  • Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or computer-readable storage media.
  • Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as CD-ROM disks, and/or digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Systems, procedures, and instrumentalities are disclosed for an adaptive authorization framework for networks, for instance 5G networks. In some examples, an application or device, or a network function or service, may be dynamically authorized to access a network resource or service. Authorization information may be defined, provisioned, and/or updated specific to an application, device, network function, or service.

Description

ADAPTIVE AUTHORIZATION FRAMEWORK
FOR COMMUNICATION NETWORKS
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62/362,895, filed July 15, 2016 and U.S. Provisional Patent Application No. 62/451,414 filed January 27, 2017, the disclosures of each of which are incorporated by reference in their entireties.
BACKGROUND
[0002] Mobile communications continue to evolve. A fifth generation of networks is generally referred to as 5G. Mobile phones have evolved from voice centric monochrome devices with minuscule screens and little processing power to devices with high resolution, palm sized screens, and data processing power rivaling laptop computers. This transformation, coupled with an expanding cache of bandwidth hungry applications, have triggered demands for higher data rates. Mobile data traffic reportedly grew more than 24-fold between 2010 and 2015 and may grow more than 500-fold between 2010 and 2020. This has, in turn, propelled the uptake of 4G network equipment contracts and driven operators worldwide to deploy 4G networks. 4G supports high data rates (e.g., up to 1 Gbit/s) on the downlink.
[0003] Attention is turning from 4G toward next generation (e.g., 5G) technologies. Use cases that may influence a 5G system architecture include Enhanced Mobile Broadband (eMBB) connectivity, Massive Machine Type Communications (mMTC) and Ultra-Reliable Critical Communications (URCC) services.
SUMMARY
[0004] Systems, procedures, and instrumentalities are disclosed for an adaptive authorization framework for networks, for instance 5G networks. In some examples, an application or device, or a network function or service, may be dynamically authorized to access a network resource or service. Authorization information may be defined, provisioned, and/or updated specific to an application, device, network function, or service. [0005] In one example, an authorization node or function receives a request from a device to use a service provided by at least one Network Slice (NS). The authorization node obtains authorization decision information that includes at least one of: information related to a subscription, the service, or the at least one network slice; one or more operator policies; or information related to the device. The authorization decision information is compared to the request. Based on the comparison between the authorization decision information and the request, the authorization function generates authorization information, and sends the authorization information to the device. The authorization information may include at least one of a proof of authorization or an indication of an authorization grant decision. The proof of authorization or the indication of the authorization grant decision may include an access token that indicates at least one of: 1) an authentication level that was achieved; 2) an identity proof of the device; 3) a security assurance level; 4) one or more authentication factors used; 5) an authorization role associated with the device; 6) an authorized access time period; 7) a service type that is authorized; 8) one or more service specific parameters; and 9) one or more payment parameters.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.
[0007] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A.
[0008] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. lA.
[0009] FIG. ID is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. lA.
[0010] FIG. IE is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. lA.
[0011] FIG. 2 depicts an example of different business models in 5G Networks.
[0012] FIG. 3 depicts an example of dimensions of innovation in 5G Networks. [0013] FIG. 4 depicts an example of Network Slicing.
[0014] FIG. 5 depicts an example of NFV Layers in an example NFV architecture.
[0015] FIG. 6 depicts an example of an NFV-MANO Architecture.
[0016] FIG. 7 depicts an example of SDN Layering.
[0017] FIG. 8 depicts an example of ProSe Non-Roaming Reference Architecture.
[0018] FIG. 9 is an example of an OAUTH protocol flow.
[0019] FIG. 10 is a call flow that depicts an example of a PUSH Authorization Model.
[0020] FIG. 11 is a call flow that depicts an example of a PULL Authorization Model.
[0021] FIG. 12 is a call flow that depicts an example of an Agent Authorization Model.
[0022] FIG. 13 is a call flow that depicts an example of a PUSH Confirm Authorization
Model.
[0023] FIG. 14 is a call flow that depicts an example of an Indirect PUSH
Authorization Model.
[0024] FIG. 15 is a state diagram that illustrates examples of dynamic authorization triggers.
[0025] FIG. 16 depicts
[0026] FIG. 17 depicts
[0027] FIG. 18 depicts
[0028] FIG. 19 depicts
[0029] FIG. 20 depicts
a network service.
[0030] FIG. 21 depicts an example of an authorization function for providing access to a network service.
[0031] FIG. 22 depicts an example of an authorization function for providing access for a roaming WTRU to access a network service.
[0032] FIG. 23 depicts an example of sub-networking with implicit authorization for WTRU access to a network function.
[0033] FIG. 24 depicts an example of an authorization function for WTRU access to a network function.
[0034] FIG. 25 depicts an example of implicit authorization and slice isolation by network configuration for access to a network slice by a network slice.
[0035] FIG. 26 depicts an example of an authorization function for access to a network slice by a network slice. [0036] FIG. 27 depicts an example of authorization functions for WTRU access to multiple slices.
[0037] FIG. 28 depicts an example of an authorization function with tags applied to resources and consumers of those resources.
[0038] FIG. 29 depicts an example of generic security functions in a sliced network architecture.
[0039] FIG. 30 depicts an example of a Security Functions Toolbox for
Generic/Dynamic Authorization.
[0040] FIG. 31 depicts an example of a Proactive Authorization Framework.
[0041] FIG. 32 depicts an example of a Trusted Third Party Authorization Architecture.
[0042] FIG. 33 depicts an example of a Service Access Token.
[0043] FIG. 34 depicts an example of a chained token structure.
[0044] FIG. 35 depicts another example of a Proactive Authorization Framework
[0045] FIG. 36 depicts an example of a Proactive Authorization Framework using MNO as a Trust Anchor.
[0046] FIG. 37 depicts an example of a Reactive Authorization Framework.
[0047] FIG. 38 is an example call flow performed within the Reactive Authorization Framework.
[0048] FIG. 39 depicts an example of high-level authorizations.
[0049] FIG. 40 depicts an example of a Proof-of-Authorization, e.g., a Service Access
Token.
[0050] FIG. 41 depicts an example of a multi service authorization with caching architecture.
[0051] FIGs. 42A and 42B depict an example of a tiered authorization procedure.
[0052] FIG. 43 depicts an example of an authorization update/revocation procedure.
[0053] FIG. 44 depicts an example of an authorization update/revocation procedure.
[0054] FIG. 45 depicts an example of distributed AF using an SDN infrastructure for CP/UP access control enforcement.
DETAILED DESCRIPTION
[0055] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.
[0056] As an initial matter, it is recognized herein that new radio (NR) networks (which can be referred to herein, without limitation, as 5G) may support higher data rates for uplink (UL) and downlink (DL) as compared to legacy networks. For example, uplink data throughput may be as high as or may exceed downlink data throughput. 5G may improve coverage and user experience as compared to legacy systems, for example, with higher data rate, lower latency and improved energy efficiency. IEEE 802.11 High Efficiency Wireless (HEW) may increase the presence of cellular operators, which may amalgamate different access technologies developed in different Standards Development Organizations (SDOs) to support future connectivity and data rates. 5G throughput and connectivity may be provided by multiple interconnected
communication standards, which may, for example, range from wireless metropolitan area networks down to wireless personal area networks and wired networks.
[0057] Massive connectivity may be driven by a variety of things or objects (e.g., RFID tags, sensors, actuators and mobile phones) in the environment, which may be referred to generally as the Internet of Things (IoT). Objects or devices may interact with each other in a variety of ways and may generate huge amounts of data. The IoT and the Internet have converged and may continue converging with a multitude and variety of service scenarios. 5G systems may connect smart objects (e.g., M2M or IoT devices) and may enable them to interact with other objects, for example, to yield productivity and automation gains through predictive, actionable intelligence. By way of example, mobile devices may adopt a silent mode when entering a meeting room per a request of a meeting moderator (e.g., indicated in a policy), may alert a user to and/or turn off the radio on the user's mobile phone before entering sensitive medical areas, or may detect when a user enters a car and automatically connect to its sound system. By way of further example, wireless sensors may let people check where their pet is in real-time, and may control the temperature for each room of their home while they are out. Emergency services may be remotely and automatically alerted, for example, when a fire is detected in a building or when a patient's medical parameters shift beyond a critical threshold.
[0058] 5G may provide increased service reliability for mission critical
communications services such as intelligent transportation systems. 5G systems may provide resiliency and reliability. 5G wireless systems may improve data rates, efficiencies, and may enable new IoT services. 5G technologies may support traffic growth of 1000 times, for example, without a corresponding increase in CAPEX and OPEX costs. 5G system architecture may reduce costs for Mobile Operators or Service Providers. Cost reduction and flexibility for wireless networks may be achieved, for example, by reducing dependency on dedicated network functions and switching to generic COTS platforms, such as cloud computing utilizing virtualization technologies. 5G systems may provide automation and remote interaction, but it is recognized herein that security and privacy issues may be introduced by and associated with 5G networks.
[0059] 5G networks may be designed to connect industries, such as manufacturing and processing, intelligent transportation, smart grids and e-health. Different environments may cause issues for speed, latency and heterogeneity. Interaction by different platforms may mean different protocols, different interfaces and different policies (e.g., QoS requirements). Diverse service contexts may introduce various security and privacy considerations. For example, an e- health information system may have more privacy than a Home Automation System (HAS) that may have more security for Control Plane (CP) signaling. Network data handling capabilities may be improved to accommodate a large volume of data transported, stored and/or processed in 5G systems. Radio Network equipment that supports higher frequencies (e.g., Millimeter wave (mmW) 30GHz+) and core networks that store, forward and process data may be deployed, which may increase CAPEX and associated OPEX expenditures by mobile network service providers.
[0060] FIG. 1A is a diagram of an example communications system 100 in which one or more embodiments disclosed herein may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.
[0061] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs), e.g., WTRUs, 102a, 102b, 102c and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
[0062] The communications system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
[0063] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in some embodiments, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
[0064] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).
[0065] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA,
TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the
RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as
Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
[0066] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE- A).
[0067] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
[0068] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In some embodiments, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.
[0069] The RAN 103/104/105 may be in communication with the core network
106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b,
102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
Although not shown in FIG. 1 A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.
[0070] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.
[0071] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
[0072] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB or HeNodeB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.
[0073] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of
microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
[0074] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface
115/116/117. For example, in some embodiments, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
[0075] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some embodiments, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
[0076] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
[0077] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128
(e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad
126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
[0078] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
[0079] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination implementation while remaining consistent with an embodiment.
[0080] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
[0081] FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115. The
RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the
RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115.
The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
[0082] As shown in FIG. 1C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.
[0083] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
[0084] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
[0085] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0086] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
[0087] FIG. ID is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107. [0088] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some embodiments, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
[0089] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and/or downlink (DL), and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
[0090] The core network 107 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
[0091] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S I interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer
activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
[0092] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
[0093] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP- enabled devices. [0094] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
[0095] FIG. IE is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.
[0096] As shown in FIG. IE, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some embodiments, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.
[0097] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for
authentication, authorization, IP host configuration management, and/or mobility management. [0098] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.
[0099] As shown in FIG. IE, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
[00100] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
[00101] Although not shown in FIG. IE, RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks. [00102] FIG. 2 depicts different example business models in 5G Networks. In some cases, different Mobile Network Operators (MNOs) may have different business models, and may provide different services to end users. In accordance with the illustrated example, an MNO may be an Asset Provider, Connectivity Provider, or Partner Service Provider. An Asset Provider may own a certain function of a network (e.g., partially/fully sharing the radio access network (RAN) and/or the core network). A connectivity provider may be an MNO that provides network (e.g., IP) connectivity for consumers, businesses, or a wholesale/Mobile Virtual Network Operator (MVNO). A partner service provider may benefit from the service features offered by a third party operator that may own mobile connectivity capabilities (e.g., customers of smart wearable devices with services of a remote health monitoring company).
[00103] An Asset Owner generally refers to a model where a service provider (SP) partially or fully owns infrastructure. For example, an SP may own a core network while sharing a RAN with other SPs. In an example cloud based scenario, an SP shares infrastructure with other SPs. Business models in 5G networks may include implementations ranging from dedicated hardware (HAV) through to cloud-based services, such as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). These various scenarios may provide SPs with different levels of control over shared infrastructure, and with a varying set of privileges over a network. A connectivity provider may be an example of a cloud based ownership model, where an SP (e.g., which does not own infrastructure) may function as a connectivity broker for end SPs.
[00104] FIG. 3 depicts three example dimensions (network infrastructure capabilities, provider, service requirements) of innovation in 5G Networks. Each dimension may realize a variety of 5G network features. Different use cases may be formed based on user requirements and 5G network features. The elasticity of the business models in 5G networks may provide a another aspect for consideration in 5G networks.
[00105] Example 5G network features may include, without limitation: (i) flexibility and scalability (e.g., connection attributes such as mobility, security, privacy, reliability, latency, etc., may be enabled/disabled/modified and controlled in a programmable and switchable manner that may depend on use-cases, subscription details and associated policies defined by operators);
(ii) context-awareness that may allow customization or creation of an application to match preferences of a user, e.g., based on current context such as location, time, activities and services; (iii) fixed-mobile convergence where 5G may support fixed and mobile convergence, for example, to provide a seamless customer experience in fixed and mobile domains (e.g., a unified user authentication, RAN and CN independence); (iv) energy and cost efficiency; (v) operations awareness and efficiency; (vi) availability and reliability (Resilience Networks); (vii) enhanced network security with security protocols to adapt to use-cases, e.g., mMTC, and comply with security requirements defined in 3GPP standards and/or (viii) enhanced user security and privacy. It is recognized herein that 5G business models may make users more vulnerable to security and privacy breaches, for example due to different levels of trust and security in different models. Thus, in some cases, 5G security may protect user privacy according to different contexts and applications.
[00106] There may be a diversity of applications and associated network service requirements (e.g., QoS, speed, latency, security). In some cases, Network Slicing (NS) is used, for example, to offer more granular control of performance and network features based on applications or services being used. Network Slicing generally refers to providing isolated subnetworks that may be optimized for specific types of traffic characteristics. An example network slice may have its own set of security and quality of service (QoS) requirements. Some or all slices may be (e.g., completely) isolated from other slices.
[00107] In some cases, some or all network functionalities may be virtualized and may be shared by mobile network operators (e.g., using Network Function Virtualization (NFV) and other virtualization techniques). For example, by using a more software-centric approach, costs may be shared and network utilization may be optimized. 5G networks may implement novel architectures and technologies in the communications industry. Virtualization and NFV may be enablers for NS.
[00108] Network slices may enable a wide spectrum of use-cases in 5G. A slice may refer to a set of features that achieves a use-case, for example, by taking into consideration the capabilities of the operator(s) that provide a service. 5G networks may support dedicated vertical use cases, such as intelligent transportation, gaming, remote machinery and virtual reality, and the like, which may have different service requirements. Virtual slices of a network may support differentiated application and services. Virtual Slices may be logical instantiations of network resources. Operators and/or service providers may support slicing, for example, by using automated management based on NFV technologies.
[00109] FIG. 4 depicts an example of Network Slicing. A network operator may use a Network Slice Blueprint to create a Network Slice Instance. An example Network Slice Instance may provide network characteristics (e.g., including layers from the Radio Access layer up to the service layer) required or utilized by a Service Instance. A Network Slice Instance may also be shared across multiple Service Instances provided by a network operator. [00110] Network Function Virtualization (NFV) may permit building an end-to-end network infrastructure with evolving standard IT virtualization technology, for example, to enable consolidation of heterogeneous network devices onto standard high-volume servers, switches, and storage. Virtual network functionality of a network device may be implemented as a software package. In some cases, a Virtual Network Function (VNF) may run on a (e.g., one) Virtual Machine (VM) as a VNF Instance (VNFI), or more than one VM as a VNF Component Instance (VNFCI). OPEX and CAP EX may be greatly reduced, for example, as compared to current approaches, given that network functions may be executed on standard servers without requiring expensive function-dedicated devices (e.g., Media Gateways, Firewalls, etc.). In some cases, some dedicated Hardware (HW) functionality (e.g., crypto-accelerators) is efficiently implemented in pure software (SW). Generic architectures, which may accommodate some level of hardware acceleration and programmability (e.g., FPGA) may be implemented. Crypto- accelerators and FPGA may be (e.g., alternatively) included in default COTS HW
configurations. It is recognized herein that introducing or testing a network function may be performed, in some cases, by installing or upgrading a software package that runs on network servers.
[00111] FIG. 5 depicts an example of NFV Layers in an example NFV architecture. In an example Network Function Virtual infrastructure (NFVI), virtual machines are created on high-volume hardware servers and storage devices that may be connected by high-volume network switches, and organized by an orchestration (e.g., Hypervisor). In some cases, NFV allows for the separation of software that defines network functions for network devices from generic hardware. In some cases, NFV allows for Management and Orchestration (MANO), which may automate installation and management of virtualized network functions on generic hardware. It is recognized herein that NFV technology may permit carriers to build and operate flexible and highly configurable networks with reduced equipment costs and reduced power consumption, for example, by consolidating equipment and exploiting the economies of scale of the information technology (IT).
[00112] In an example, Management and Orchestration (MANO) within NFV manages
NFV Infrastructure (NFVI) to perform resource allocations for various network services and
VNFs. MANO may be involved in the management and orchestration of Network Functions
Virtualization Infrastructure. Components that may be managed may be virtualized or partially - virtualized resources such as, for example: (i) computing infrastructure that may include computing machines and/or virtual machines having one or more CPUs and memory; (ii) storage
(e.g., non-volatile secure storage); and/or (iii) network (e.g., subnets, ports, networks, etc.). [00113] MANO may be involved in the management and orchestration of Virtualized Network Functions (VNFs), such as management and orchestration of VNFs pertaining to fault, configuration, accounting, provisioning and security (FCAPS). In some cases, MANO may instantiate, scale, upgrade, and terminate VNFs. MANO may be involved in the management and orchestration of Network Services, such as managing the lifecycle of network services, which may include instantiation of services, scaling (elasticity), termination of services, etc. MANO may be involved in the management and orchestration of miscellaneous aspects, such as policy management and interactions with legacy or new Operations Support Systems/Business Support Systems (OSS/BSS).
[00114] FIG. 6 depicts an example NFV-MANO Architecture 600. As shown, an example NFV Architectural Framework may include multiple an NFV Orchestrator (NFVO) 602, a VNF Manager (VNFM) 604, and a Virtualized Infrastructure Manager (VIM) 606. The NFVO 602 may perform orchestration functions of NFVI resources across multiple VIMs and lifecycle management of network services. The VNFM 604 may perform orchestration and management functions of VNFs. The VIM 606 may perform orchestration and management functions of NFVI resources within a domain. The NFVO 602 may interact with an OSS/BSS 608 (e.g., legacy system), for example, for provisioning, configuration, capacity management and policy-based management. The VNFM 604 may interact with an Element Manager (EM) 610 and a VNF 612, for example, for provisioning, configuration, and fault and alarm management. The VIM 606 may interact with an NFVI 614 for the management and orchestration of virtualized resources.
[00115] In some cases, Software Defined Networking (SDN) is a complementary technology to NFV. SDN may enable realization of a control plane, a user plane, and a management plane for NFV. In some cases, SDN enables network function virtualization and network programmability, which may be protocol building blocks for the next generation of 5G networks.
[00116] FIG. 7 depicts an example of SDN Layering. A shown, an example SDN network architecture 700 may include a centralized network controller 702 in a control plane
704. The controller 702 may be responsible for allocating traffic to network elements in a separated data plane of a network. The network controller 702 may (e.g., centrally) maintain the intelligence and state of a network. The network controller 702 may output fine granular flow routing control rules to heterogeneous network devices 705, which may be from different vendors. The network controller 702 may provide (e.g., through a northbound interface 706) a global united view and resources of a network to upper layer network applications 708 as a single, logical switch. Network applications 708 may be created, tested, and deployed in a short time. SDN protocols may enable control-plane management and may be separated from a data/user plane.
[00117] Open flow, which is defined by Open Networking Foundation (ONF), is an example of an SDN protocol in a southbound interface 710 between the network controller 702 and network devices 705. Open Flow may be supported by various device manufacturers, service providers, and operators. SDN protocols may also be provided for the northbound interface 706.
[00118] With respect to authorization in 4G/LTE, a WTRU or network entity (e.g., in a mobile network) may be explicitly authorized before granted access to a particular resource or service. In some cases, implicit authorization is assumed for a WTRU once successfully authenticated in a network. In an example, associated traffic (user or control plane) may be automatically allowed to flow through an S/P-GW, for example, immediately after a WTRU is authenticated through eNB, MME, and HSS. Implicit authorization may also be provided to a network function to use other resources or network functions within the same network domain, for example, based on the implied trust within an MNO predefined security perimeter.
[00119] FIG. 8 depicts an example of ProSe Non-Roaming Reference Architecture. Proximity Services (ProSe) may implement explicit authorization for a WTRU for Device to Device (D2D) discovery and communication services. It is recognized herein that the OAuth framework may enable Clients to obtain access to one or more services from a Service Provider (SP) by leveraging trust relationships with a trusted third party. The protocol includes various roles, such as a Service/ Application Owner (SO), Service Provider (SP), Authorization Server (AS), and/or Client (C). A Client may be authorized to access a service for a limited amount of time, after which the access may be revoked. In some cases, a given SP does not provide the Client with a common set of long-term credentials, but may provide the Client with unique temporary credentials for the client to access one or more services. A trusted third-party may enable a Client to obtain access to a sub-set of services and may be restricted from accessing a complete set of services. In an example, an Authorization layer separates the role of the Client from a resource owner. A Client may obtain authorization, for example in the form of an Authorization Token (AT), from an Authorization Server (AS). ATs may be issued by an AS, for example, based on the approval of a Service/ Application Owner (SO). A Client may use an AT to obtain access to a resource.
[00120] FIG. 9 depicts an example of an OAUTH protocol flow. In accordance with the example, a Client 902 requests authorization from an SO 904, at 1. A request by the Client 902 may be made directly to the SO 904 or indirectly via an AS 906. The Client 902 may receive an authorization grant from the SO 904, at 2. The SO 904 may provide grants using one or more procedures. A grant type may be an authorization code (e.g., using implicit means), a service owner's password credentials, and/or Client credentials. The Client 902 may request an access token from the AS 906, for example, after presenting an authorization grant (at 3) obtained from the SO 904. The Client 902 and the AS 906 may authenticate one another as part of an AT request. At 4, in accordance with the illustrated example, the AS 906 may issue an AT to the Client 902, for example, after verifying the authorization grant. At 5, the Client 902 may request access to a service by presenting the AT to an SP 908. The SP 908 may validate the AT and may (e.g., when deemed valid) provide the Client 902 with access to the service, at 6.
[00121] FIG. 10 depicts an example of a PUSH Authorization Model. A Push model may be viewed as a more pro-active approach for obtaining authorization. In the illustrated example messaging, at 1, the Client 902 requests an AT from the AS 906 for access to service(s) offered by the SP 908. The AS 906 may send the AT to the Client 902, at 2. The Client 902 and the AS 906 may mutually authenticate one another, for example, before the AT is sent to the Client 902. The AT may be sent over a secure connection. At 3, the Client 902 may send the AT, for example using a Service Access Request, to the SP 908. The SP 902 may verify the AT and may return a Service Access Response to the Client (at 4).
[00122] FIG. 11 depicts an example of a PULL Authorization Model. Interactions in a PULL model may be performed via the SP 908. The PULL model may follow a general service access process (e.g., WiFi Access Request). In some cases, this is not suitable when the SP 908 is constrained. In the illustrated example messaging, at 1, the Client 902 tries to access service(s) provided by the SP 908. At 2, the SP 908 may communicate with the AS 906 to request authorization of the Client 902. The SP 908 may belong to the same administrative domain as the AS 906 or have a strong trust relationship with the AS 906. At 3, the AS 906 may grant or reject the authorization. The AS 906 may perform an authentication with the Client 902. Communications between the Client 902 and the AS may be traversed through the SP 908. At 4, the SP 908 may grant or reject access to the service based on the response from the AS 906.
[00123] FIG. 12 depicts an example of an Agent Authorization Model. In an example, the Client 902 may request access to a resource with an AS 906. The Client 902 may have a strong trust relationship with the AS 906. The AS 906 may be the identity provider for the
Client 902. In the illustrated example messaging, at 1, the Client 902 forwards a resource access request to the AS 906. At 2, the AS 906 checks the access rights of the Client 902 and may send the service access request to the SP 908. The AS 906 may include an AT within its request to the SP 908. At 3, the SP 908 may verify the AT and may respond with a service access response containing one or more resources to the AS 906. At 4, in accordance with the illustrated example, the AS 906 forwards the response to the Client 902.
[00124] FIG. 13 depicts an example of a PUSH Confirm Authorization Model. In the illustrated example messaging, the Client 902 sends a request to obtain an AT from the AS 906. At 2, the AS 906 may send an AT identifier to the Client 902, for example, after an optional authentication with the Client 902. At 3, the Client 902 may send an AT identifier to the SP 908. At 4, the SP 908 may submit the AT identifier to the AS 906, for example, to obtain the AT from the AS 906. At 5, the AS 906 may check the AT identifier and may respond to the SP 908 with the associated AT. At 6, the SP verifies the AT and may send a response with an
acknowledgement to the Client 902. The response may indicate successful access to the service.
[00125] FIG. 14 depicts an example of an Indirect PUSH Authorization Model. In the illustrated example messaging, at 1, the Client 902 sends to the AS 906 an authorization request for a particular resource. At 2, the AS 906 may verify the request and may send an AT to the SP 908. At 3, the SP 908 may store the AT and may send a response to the AS 906. At 4, the AS 906 may send an authorization response to the Client 902. At 5, the Client 902 may send to the SP 908 a service access request, which may contain an AT identifier. At 6, the SP 908 may verify the request and the AT identifier, and may respond to the Client 902 with an
acknowledgement that indicates successful access to the service.
[00126] It is recognized herein that 5G network access control and authorization mechanisms may operate at a much more granular level (e.g., compared to other wireless communication systems), for example, based on a variety of 5G network business models and architectures that accommodate a wide diversity of 5G network services. In some cases, deployments models permit a network to be sliced. Network functions may be deployed in realtime with network functions spanning several locations and on a variety of infrastructure, e.g., owned, leased and/or shared by third parties. It is recognized herein that tremendous diversity of deployments, and variability in the services offered and the procedures for accounting and charging for the services rendered may place a burden on operators and infrastructure suppliers to provide standardized accounting and billing mechanisms that operate at a granular level of the services being offered. It is further recognized herein that standardizing security procedures (such as authorization) on an individual type of service or use case basis may be valuable for 5G networks, among others.
[00127] It is further recognized herein that a design approach built around modular and reusable authorization functions and/or procedures across multiple services may support dynamic service provisioning, for example, to allow flexibility in deployments and independent scalability of such functions. In various examples described herein, an over-arching framework is provided for scaling and deploying authorization mechanisms for multiple services, e.g., in 5G networks.
[00128] Turning now to an example dynamic authorization use case, dynamic authorization (e.g., dynamic WTRU access to a network service) may be triggered in different ways. FIG. 15 illustrates examples of dynamic authorization triggers. FIG. 15 shows an example of a service authorization state machine from the perspective of a user. FIG. 15 depicts various examples of transitioning the user from an un-authorized to an authorized entity, and visa-versa, for example, to permit and deny access to a service. In an example, a service is first provisioned by an operator for a user. The service at a minimum may permit an association to a particular subscription (e.g., for billing purposes).
[00129] Examples of dynamic authorization state transitions include, without limitation time-based, location-based, application request, service provider (SP) offer/user input, network operational thresholds, payment and group-based (role-based) authorization state transitions.
[00130] Turning now to an example time-based dynamic authorization state transition, a WTRU may be authorized to use a service based on specific time intervals. By way of example, a user may be automatically authorized to use a service from 6pm-8am on week-days. In another example, a user may be provided authorization for a fixed time duration (e.g., following a completed payment). For example, when the time duration during which the user is authorized expires, the authorization may be automatically revoked.
[00131] In an example of a location-based dynamic authorization state transition, a WTRU may be authorized to use a service, for example, when entering and while in a given validity area. For example, a user may be automatically authorized to use a service when the user is within a specific geographic location (e.g., latitude, longitude and radius) or a Cell or WLAN coverage area. Authorization to access the service may be revoked, for example, when the user leaves the particular area.
[00132] In an example of an application request dynamic authorization state transition, an application may be granted access to a network service on behalf of a user upon request. For example, an authorized third party application (app) may obtain automatically an authorization on behalf of a user to use a service via an API call.
[00133] In an example of a Service Provider (SP) offer/User input dynamic authorization state transition, an SP triggers an instant message or in-app push notification to invite a user to use a service for free or for a fee. In some cases, the user may be allowed to use the network service upon a positive reply or completion of a payment. [00134] In an example of a network operational threshold dynamic authorization state transition, access to a network service that is reaching a pre-determined peak load (e.g., due to very high usage, such as in a stadium full of users) may be temporarily denied, for example, based on a user request to use that service. Permission to use the service may be granted for eligible users upon request, for example, when a network load falls back below a safe usage threshold. In another example, a network service peak load condition may lead to revoking authorization for some active users while maintaining it for others, for example, based on a tiered system of access rules, such as by revoking authorization for some active ("bronze") users while maintaining authorization for other active ("gold") users.
[00135] In an example of a payment-based dynamic authorization state transition, a WTRU is authorized to access a service based upon a payment or subscription that an entity (e.g., user or organization) performs.
[00136] In an example of a group-based (role-based) dynamic authorization state transition, an entity (e.g., WTRU) is part of a group (e.g., admin/user group). In some cases, the WTRU may be automatically authorized to access a service when the WTRU is added to the group. A WTRU may be added to a group, for example, based on a subscription to the group or a change in status of the WTRU (e.g., change of groups). In some cases, WTRUs/users assume roles (e.g., super user role, manager role, etc.) that provide different privileges based on role type. Appropriate revocation or addition of authorization privileges may be carried out, for example, when a role change occurs.
[00137] Turning now to example access control use cases, FIG. 16 depicts an example scenario in which a WTRU accesses a network service. In some cases, network service usage is restricted to authorized WTRUs/ Applications. In some examples, however, an illegitimate (unauthorized) user might be able to utilize a network service normally restricted to a certain type of users (e.g., paying subscribers, public safety agents).
[00138] FIG. 17 depicts an example use case in which WTRUs access one or more Network Functions (NFs). In some cases, access to a NF be is restricted to authorized WTRUs in a multi-purpose network (e.g., slice). A multi-purpose deployment may provide cost-savings as compared to legacy network functions. In the example use case illustrated in FIG. 17, a network serves mobile broadband and stationary low cost devices, and a stationary rogue device utilizes (hijacks) NF3 that is reserved for mobile devices.
[00139] FIG. 18 depicts an example use case in which a slice accesses another slice.
Unauthorized access from one slice to another may be prevented in a multi-slice environment. In the example use case illustrated in FIG. 18, an illegitimate access occurs between NFb in Slice 1 and NF3 in Slice 2. Slice 1 may be a slice with common functions that may communicate with dedicated functions of one or more other slices (e.g., common control functions communicating with user plane forwarding functions).
[00140] FIG. 19 depicts an example use case in which a WTRU accesses a network slice. Unauthorized access by WTRUs to a slice may be prevented in a multi-slice environment. In the example use case illustrated in FIG. 19, a network serves mobile broadband and stationary low cost devices, and a rogue stationary device utilizes (hijacks) slice 2 that is reserved for mobile devices.
[00141] In accordance with various embodiments now described, authorization capabilities are scalable. For example, signaling storms (e.g., due to authentication/authorization messaging) may be prevented. Further, in accordance with various embodiments, authorization is flexible, such that authorization may be provided for highly variable security or service requirements in next generation networks. For example, a flexible authorization scheme may accommodate different granularity levels for access control, such as coarse-grained (e.g., per subscription profile/PLMN) and fine-grained (e.g., per WTRU/ Application and Network Service or NF) levels. In an example, access to a WTRU for a particular service (or slice, NF) based on events (e.g., time, location) or actions (e.g., operator, user, application) may be dynamically granted and revoked.
[00142] In another example, WTRU access to a network service is provided by explicit authorization through a service specific function. For example, a dedicated function may be used to handle explicit authorization for a WTRU/ Application to use a service. Referring now to FIG. 20, a dedicated Authorization Function 2002 controls access to a specific Network Service X, such that a rogue device 2004 is denied access to the functions of Service X when the device 2004 tries to utilize the network service. In an example, the service request message from the device 2004 is dropped by the Authorization Function 2002.
[00143] Referring now to FIG. 21, WTRU access to a network service may be provided, for example, by explicit authorization through a generic framework. In accordance with the illustrated example, an Authorization Function (AF or AuthF) 2102 can control access to any Network Service. A rogue device 2104 is denied access to one or more network services (e.g., Service X and Service Y). The AF 2102 may utilize a combination of subscription information (e.g., via HSS 2106) and access policy rules 2108 (e.g., via PCRF). The AF 2102 may support faster authorization mechanism roll-out for new services as compared to current approaches. The AF 2102 may provide a central view of authorization policies across services within slices or an entire network 2110. An AF architecture may be flexible and extensible enough to accommodate a multitude of current and future services.
[00144] In an example, a WTRU that is roaming my receive access to a network service by explicit authorization through a service specific function. In an example, the function may be an HPLMN interfaced with equivalent in VPLMN. In an example, a dedicated function and procedure (e.g., ProSe) may be used to handle explicit authorization procedures for a roaming WTRU/ Application to use a service. In another example, a WTRU that is roaming may receive access to a network service by explicit authorization through a generic framework.
[00145] Referring now to FIG. 22, an Authorization Function 2202 authorizes a roaming WTRU (UE 1) for access to network services X and Y. In accordance with the example, authorization is provided by an AF 2202a within a home network 2204 in collaboration with an AF 2202b in a visited network 2206. The home AF 2202b may, for example, merge access policy rules from both networks 2204 and 2206, and may provide WTRU network credentials to the visited AF 2202b, for example, for billing purposes.
[00146] Referring now to FIG. 23, in an example, a given WTRU may be provided access to a network function (NF) via implicit authorization with sub-networking. As shown, an example network 2300 may be separated into separate slices or sub-networks 2300a and 2300b. Network attachment may be anchored accordingly to provide security by isolation. In accordance with the illustrated example, the network 2300 (also depicted in FIG. 17) is divided into one or more mobile sub-networks (e.g., sub-network 2300a) and one or more stationary subnetworks (e.g., sub-network 2300b). A network wide Authentication Function (AuF) 2302 may grant or deny access to an appropriate sub-network when devices connect to the network 2300. Thus, in accordance with the illustrated example, sub-slices or sub-networks may maintain implicit authorization, and additional authorization processing might not be required. In some cases, implicit authorization with sub-networking may result in function duplication. Network slicing using newer NFV/SDN techniques may depend on operator network capabilities and deployment context. Network partitioning (e.g., VLAN) may be implemented by provisioning statically separate physical sub-networks (e.g., core network instances).
[00147] Referring now to FIG. 24, in accordance with another example, a given WTRU may be provided access to a network function (NF) via explicit authorization through a generic framework. In accordance with the illustrated example, an Authorization Function (AF) 2402 controls access (e.g., as an SDN control application) to a plurality of network functions, for instance each NF, within a network 2400. In the example, the AF 2402 denies access to NF3
(e.g., traffic dropped on the data path) by a rogue device 2404. The AF 2402 may utilize a combination of subscription information (e.g., via HSS 2406) and access policy rules 2408 (e.g., standalone database or via HSS). In some cases, explicit authorization through a generic framework may accommodate single, multi-slice, and other network deployments, given that it does not dictate a network deployment model. Thus, a "dynamic authorization ready" architecture (e.g., via the AF 2402, in contrast with static authorization) may be implemented. Explicit authorization through a generic framework may be deployed with additional functions described herein.
[00148] Referring now to FIG. 25, in accordance with another example, a network slice is provided access to another network slice via implicit authorization, wherein a network 2500 is configured such that its slices are isolated from each other. In accordance with the illustrated example, inter-slice switching/routing may be governed by a pre-defined configuration (e.g., SDN forwarding rules) that allow specific source-destination communication channels. For example, data traffic between NFb in Slice 1 and NF3 in Slice 2 is blocked. In some cases, implicit authorization with slice isolation may be "free" where inter-slice traffic might not be required, given that strict isolation recommendations and best practices may be applied for overall network security, such as prevention of side channel attacks and establishment of a minimum security baseline for slices to prevent attacks via a "weakest link" slice.
[00149] Referring now to FIG. 26, in accordance with an embodiment, a network slice is provided access to another network slice via explicit authorization through a generic framework. In accordance with the illustrated example, an authorization function 2602 authorizes access to a network slice (e.g., Slice 1) of a network 2600 by another network slice (e.g., Slice 2) of the network 2600. The Authorization Function (AF) 2602 may control access to Network Slices as an SDN control application. The AF 2602 may use operator defined slice access policy rules 2604 to block traffic, for example, from NFb/Slicel to NF3/Slice. In accordance with the illustrated example, an explicit authorization may support controlled access in a slice without imposing a secure communication path across slices, for example, when using a proper decoupling of authorization and other types of traffic (e.g., control, data). Similar building blocks (e.g., AF) may be leveraged and generalized to control access to a slice.
[00150] Referring now to FIG. 27, in accordance with another example, a given WTRU may be provided access to a network slice or a predetermined group of slices via explicit authorization. In an example, access may be granted for a common control plane (CP) Slice and one or more designated user plane (UP) slices. Access to slices by a WTRU may be determined, for example, when a WTRU attaches to the network. In an example, the decision to authorize access is based on a comparison between authorization decision information and the request from the WTRU to use a service provided by a network slice. For example, the decision to authorize access may be based on the comparison of a WTRU provided Service Descriptor Document (SDD), which may also be referred as Network Slice Selection Assistance
Information (NSSAI), and which may specify a set of slices the UE may wish to access, to the slices the UE is allowed to access in accordance with its subscription profile information and one or more operator polices. Operator policies, information related to a device making the request, and information related to a subscription, service, or slice may be collectively referred to as authorization decision information. In accordance with the illustrated example, an Authorization Function 2702 controls access to one or more slices per WTRU. The AF 2702 may be part of a default slice and/or a common portion of a set of slices in a network. The AF 2702 may also be outside the MNO network. For example, the AF 2702 may be part of a third party domain, for instance controlled and hosted by a trusted third party. The AF 2702 may use a combination of subscription information and access policy data to authorize access.
[00151] In another example, WTRU access to a network slice may be provided via explicit authorization per individual slice. Access to an individual slice by a WTRU may be determined, for example, when a WTRU sends a service request to the network specifying a single NSSAI (S-NSSAI). The decision to authorize access may be based on the comparison of the request to authorization decision information. In particular, the request may include a requested individual slice identifier, QoS, or security level, which may be compared to one or more slices allowed at the time of network attachment, to determine a slice that can deliver the requested QoS, security level, etc. The request, in particular the information in the request, may further be compared to subscription profile information and local Operator policies. In some cases, the functionality of AF 2702 may be split between a part common to several slices and a part specific to a particular slice. In an example, a first level of authorization may be performed at the common part level to a check whether the WTRU can access the requested slice at a network level. A second level of authorization may be performed at the individual slice level, for example, to check that the WTRU can use the service of the slice in accordance with the request (e.g., the requested QoS, etc).
[00152] Turning now to scalability of embodiments described herein, in an example, implicit authorization includes the exchange of an authentication context object between the network and a WTRU. The network may generate and provide a WTRU with a secure context object containing authentication (e.g., implicit authorization) information, for example, the first time the WTRU successfully accesses the network. A network may subsequently utilize the context object provided by the WTRU, for example, to reduce or eliminate the amount of signaling when the WTRU attempts to access or re-access the network.
[00153] With respect to scalability in an explicit authorization example that includes the exchange of an authorization context object between the network and a given WTRU, the network may generate and provide a WTRU with a secure context object containing
authentication/authorization information, for example, the first time the WTRU successfully accesses the network. Authorization information may contain granular access permission data as needed (e.g., Slice, Network Service, NFs). A network may subsequently utilize the context object provided by the WTRU to reduce or eliminate the amount of signaling when the WTRU attempts to access or re-access the network.
[00154] With respect to scalability in an explicit authorization with network authorization information caching, a central and generic Authorization Function (AF) may handle authorization for a plurality of services. As further described below, the AF may perform a bulk retrieval and caching of authorization information for one or more services (e.g., Services X, Y, and Z) for a particular user from a subscription information database (e.g., HSS), for example, the first time a WTRU requests access to a service (e.g., Service X). In some cases, the AF can skip requesting the subscription information database again, for example, when the WTRU requests authorization for another service (e.g., Service Y).
[00155] Turning now to flexibility, explicit authorization by logical Security Tags may be applied to resources and consumers of those resources. For example, a logical Security Tag (e.g., when associated with one or more Provider Entities (PEs), such as NF(s), Network Service(s) or Slice(s)) may specify the scope of access a WTRU is granted in the network. In an example, a WTRU may be assigned a set of tags that correspond to PEs the WTRU can access, for example, when the WTRU successfully attaches to the network.
[00156] Referring now to FIG. 28, an Authorization Function (AF) 2802 with example
Tags applied to resources and consumers of those resources is shown. The Security Tags may enable any of the explicit authorization examples described herein, such as Network Service or
Slice level access control for example. Tags may be assigned to NFs, for example, by programming tag information into network control functions (e.g., SDN Controller) in charge of switching traffic to those NFs. In some cases, tags may be assigned to NFs via network control messages (e.g., at la/b/c), which may be automated by an orchestration platform (e.g., NF deployment time or during live operation). Tags may be sent over the air via control plane messages (e.g., 2a/b/c) to a WTRU/ Application to convey authorization contextual information that may help achieve a degree of network authorization statelessness. An exchange may occur, for example, upon WTRU network connection, or may be triggered by an application for on- demand access. Tag information may be carried in a user data packets encapsulation (e.g., 3a/b/c), for example, to assist routing of traffic towards NFs or chaining them together according to a tag driven path.
[00157] In some cases, a Consumer Entity (CE) is granted access to a PE when they both have at least one matching tag. For example, a message sent by NF1 toward NF2 may be accepted or rejected, respectively, when NF1 does or does not have a matching tag with NF2.
[00158] In some cases, a set of different PEs and CEs assigned with the same tag may be viewed as part of the same Logical Security Group (LSG). For example, several NFs across different slices may be grouped into the same LSG.
[00159] In an example, a tag may be granted or revoked at any time from a CE or PE based on various factors (e.g., WTRU capabilities, user subscription, operator policy, operational constraints, etc.). In some examples, a tag may take the form of a string label (e.g., for quick lookup matching) and/or a more information rich object (e.g., JSON encoded) to convey additional attributes. For example, a tag definition may include additional information, such as authorization data, authorized QoS (e.g., allowed max bit rate, bandwidth cap, number of messages sent), a time, location scoped validity, or the like.
[00160] In some examples, a tag and framework built around it is secured, for example, to prevent interception, tampering, or unauthorized manipulation (e.g., create, read, write, cloning, grant/revoke). For example, a tag transmitted across network locations (e.g., across Internet) may be signed for integrity and/or may be encrypted for confidentiality, such as when the tag (as an object) may carry sensitive or private user information and may provide protection against replay attacks.
[00161] In some cases, a flexible framework using tags decouples the notion of the tag from the entities to which it applies. For example, in some cases, a tagged entity such as an NF may be oblivious to the fact it is tagged. For example, tag management may be centralized in the network management plane (e.g., LSG creation, application) and/or network control routing entities (e.g., LSG constrained routing). Confining tag awareness to a tag functional layer may help achieve decoupling and increase security by reducing the dissemination of tags (e.g., in transit or stored) among a limited number of actors and possible attacks around tags.
[00162] Explicit authorization by means of logical Security Tags applied to resources and consumers of those resources may enable authorization to be dynamic. For example, an explicit AF architecture may be realized with Security Tags that enable dynamic authorization, for example, by network propagation of tag updates. Tag updates may be based on, for example and without limitation: (i) time events, (ii) location events, (iii) policy controlled events, and/or (iv) operator or user actions. In an example of a time event, a time of day policy event may cause authorization to a service to be enabled or disabled. A geo-fence crossing event is one example of a location event. In an example of a policy controlled event, a detection that an NF security is compromised causes removal of its associated tags. In an example of an operator or user action, a user is authorized to use a service in real time after the user completes a payment.
[00163] Referring now to FIG. 29, an example high-level architecture of a 5G system 2900 is shown. The system 2900 includes a Basic Connectivity Slice (BCS) 2902, which may provide basic 3G or 4G radio link connectivity and services and access to emergency services. The BSC 2902 may invoke services from Common Security Functions (CSF) 2904 and/or Common Control Functions Slice 2906 (e.g., mobility/session management). A Slice Classifier (SC) 2908 may be used to select network slices 2909, for example, based on the type of service or application requested by a given WTRU 2910. Slice(s) that may be assigned to a WTRU may include an IoT slice 2909a, Ultra-reliable and Critical Communications slice (URLL) 2909b, enhanced Mobile Broadband slice (eMBB) 2909c, or a default slice 2909d. In some cases, the CSF 2904 may be enhanced to accommodate security requirements for 5G systems, such as those described herein.
[00164] FIG. 30 depicts an example of a Security Functions Toolbox for
Generic/Dynamic Authorization described herein. In some examples, 4G system security functions are enhanced to meet 5G security, and are accompanied by additional security functions. The Common Security Functions (CSF) 2904 functions may include, for example and without limitation: HSS/AuC 3002, EAP Function 3004, Bootstrapping Function (BF) 3006, Platform Validation Function (PVF) 3008, PKI 3010, Public Key Management Function (PKMF) 3012, Authorization Function (AF) 3014, Dynamic Access Control Policies (DACP) 3016, Token Generation Function (TGF) 3018, and Security Tag Generation Function (STGF) 3020.
[00165] The HSS/AuC 3002 may be enhanced to accommodate 5G WTRU systems.
For example, the HSS/AuC 3002 may store slice information and security properties associated with a given WTRU. The EAP Function 3004 may provide an ability to perform EAP transport for authentications, e.g., using TLS, AKA, AKA' and TTLS or other procedures that may be supported by a network. The Bootstrapping Function (BF) 3006 may provide for authentication and may enable setting up a secure communication channel between a Network Application
Function (NAF) and a WTRU. A Generic Bootstrapping Server (BSF) may be implemented as part of a CSF. The Platform Validation Function (PVF) 3008 may be used for remote platform validation of a WTRU or may enable local validation of a WTRU. A PVF may be used to verify a trust- worthiness of a WTRU's platform. The PKI functionality 3010 may be part of a CSF. PKI may provide an ability for a WTRU and/or applications in a WTRU, for example, to use X.509 certificates for authentication and establishment of a secure communications channel (e.g., TLS/DTLS). The Public Key Management Function (PKMF) 3012 may be used for registration, generation, distribution, and management of raw public keys. This function may enable providing forward secrecy.
[00166] As described in detail herein, the Authorization Function (AF) 3014 may perform authorization of WTRUs to access services, for example, based on policies that have been created by the service provider. The Dynamic Access Control Policies (DACP) 3016 may store policies that may be static and/or dynamic. Dynamic access policies may be updated based on a successful on-demand authorization. A given DACP may be updated, for example, when an authorization has expired. A PoA (e.g., token or signed message) may carry an indication on the validity of the authorization. In some cases, a given DACP may (e.g., based on the indication) be updated and access control rules may be purged when an authorization has expired. The Token Generation Function (TGF) 3018 may generate tokens (e.g., JWT, SAML) using cryptographic mechanisms. In some examples, the TGF 3018 may interact with the AF 3014 to determine the type and contents of a token. The Security Tag Management Function (STMF) 3020 generates and manages security tags, for example, based on policies associated with the generation of tags. Tags may be cryptographically protected for integrity and/or confidentiality.
[00167] Referring now to FIG. 31, an example Proactive Authorization Framework
(PAF) 3100 is shown, in accordance with an example embodiment. The framework 3100 includes an authorization function 3102. In some cases, authorization policies and procedures may be pre-provisioned to the authorization function 3102. External or internal authorization systems may be used with the PAF 3100. The PAF 3100 includes an Access Control Policy
Function (ACPF) 3104, which may generate policies used to perform subscriber/user (e.g., Entity
A) authorizations to slices and/or services. In some cases, policies may be updated on a regular basis (e.g., based on operator policies) and may be uploaded to one or more Authorization
Functions. In some examples, the Authorization Function (AuthF) 3102 performs authorization based on a request from a subscriber. Authorization decisions may be based on access control policies provisioned by the ACPF 3104. The AuthF 3102 may issue a "Proof-of-Authorization" to a subscriber, for example, based on authorization checks (e.g., platform attestations, authentication, etc.). The AuthF 3102 may be located, for example, in a trusted third party (e.g.,
OTT) 3106 or in the MNO 3108. It will be understood that the example Entity A may comprise a WTRU, sensor device, subscriber, or the like, which may request access to services and/or slices.
[00168] Still referring to the FIG. 31, the PAF 3100 further includes a Service/Slice Information DB (SIDB) 3110 that may contain details concerning services/slices, such as slice- id, risk associated with access to a given slice, VNFs that form part of a slice, etc. The PAF 3100 also may include a Subscriber Profile DB (SDB) 3112 that may store a subscriber's profile information, which may include, for example, a subscriber's identity, credential-id, risk-posture associated with subscriber, preferences, subscriptions (services/slices), etc. The PAF 3100 further includes one or more Enforcement Functions. A given Enforcement Function (EF) may enforce policies relating to access control to services/slices. The policies may be based on a Proof-of-Authorization. In some cases, the EFs are gate keepers that are used to perform access control to a service. In an example, an EF is part of a VNF that performs certain network functions, such as malware analysis. Alternatively, an EF may be an entity that does not part of a VNF, but performs access control policy enforcement. An EF may be hosted on various network devices, such as a gateway/server (e.g., WiFi Access Point, Relying Party etc.). An EF may, in some cases, be used to perform enforcement for more than one service/slice. In some examples, an EF is implemented as part of an Application-Specific Gateway (e.g., similar to SIP gateway or WiFi access point) or Firewall.
[00169] Still referring to FIG. 31, in accordance with the illustrated example, at 0, the ACPF 3104 may be provisioned with general operator policies, relevant subscriber information, and/or information on services/slices offered to subscribers, which may be collectively referred to as authorization decision information. General operator policies may determine the type of slices that would be accessible, class of subscribers, type of authorization mechanisms (e.g., proof-of- Authorization), interpretation of risk to appropriate assessment mechanisms, the length of authorization etc. Relevant subscriber information (e.g., IMSI, subscription information, preferences and/or default services) may be pre-provisioned or provisioned on request. Relevant information (e.g., all relevant information) may be proactively provisioned to the ACPF 3104. In some cases, the ACPF 3104 may be able to generate authorization policies before-hand.
Detailed slice/services information may be provided to the ACPF 3104. Details about the slices may contain information, for example, concerning EF-Ids, and concerning a risk posture associated with the slice and/or risk posture associated with each VNF that may be access controlled by an EF. In some cases, granular authorization information associated each slice may be provided. [00170] At 1, the ACPF 3104 may generate detailed authorization rules, for example, based on subscriber information, slice information, risks associated with a slice, VNFs in a slice, etc. In an example, an authorization rule indicates that a given WTRU that belongs to certain class of device should be authenticated and that authorization should be provided to access a particular slice. The ACPF 3104 may provide policy rules for the generation of a Proof-of- Authorization to a WTRU. Policies may be communicated to the AuthF 3012, at 1. Thus, the Auth 3012 may obtain authorization decision information. Policies may be communicated between the ACPF and the AuthF using, for example, secure communications (e.g., TLS), which may involve one or more back and forth messages.
[00171] At 2, in accordance with the illustrated example, a WTRU (Entity A) requests authorization with the AuthF 3102. In an example, the AuthF 3102 may receive a request from a device to use a service provided by at least one network slice. The WTRU may request authorization directly or may be re-directed by a Serving Network (SN) to the AuthF 3102, for example, when the WTRU requests access to services/slices in the SN. The AuthF 3102 (e.g., based on policies) may perform one or more authorization checks (e.g., authentications, platform assessments, etc.) as described herein. For example, the AuthF 3102 may compare the authorization decision to the request. The request may include, for example, an identifier of the slice, a requested QoS, or a requested security level. Based on the comparison between the authorization decision and the request, the AuthF 3102 may generate authorization information, which may be sent to the WTRU, directly or via an access control device. Authorization checks may be based on the risk associated with the service(s)/slices requested by the WTRU. In an example, one or more supplemental authorization checks may be performed based on the comparison between the authorization decision information and the request. Based on the checks, the AuthF 3102 may issue one or more Proof-of- Authorizations to a WTRU. In some cases, the AuthF may only provide a Proof-of- Authorization identifier (PoA ID) that identifies a particular Proof-of- Authorization.
[00172] At 3a-c, the WTRU may submit the Proof-of-Authorization to one or more EFs. In some cases, submission of the Proof-of-Authorization may be performed, for example, in a serial manner. The EFs (e.g., EF1, EF2, and EF3) may be accessed one after the other in a Service Function Chain. The Proof-of-Authorization may be processed by relevant EFs. In an example, the WTRU is provided access (e.g., to a slice) once the Proof-of-Authorization (PoA) has been verified.
[00173] An example alternative deployment model is depicted in FIG. 32, in confirmation and verification is performed at 4. Further, the issuance of a PoA at 2b is shown. Referring to FIG. 32, at 4, the claims within the PoA may be confirmed, such that it is verified that claims that have been provisioned to the Entity A (UEAVTRU) can be actually achieved based upon resource(s) within the MNO network 3108. The resources may include radio, network, service, or application layer resources. At 4, EFs (e.g., Service / Slice) may validate the resource requirements from the respective stake-holders (e.g., MNO network 3108).
[00174] In some cases, the Entity A is issued with a PoA id, and then the message at 4 may be used to obtain the PoA from the MNO (ACPF or another authorized entity within the MNO network). It may be assumed, in some cases, that the MNO has been provided with the PoA by the AuthF 3102 (Trusted 3rd party) at 2.
[00175] In some cases, the MNO (e.g., ACPF ) may proactively push a PoA to the EF(s) even before a Request Access (message 3) has been performed by an Entity. This may be particularly useful, for example, for low-latency services so that quick service setup can be established by the service provider.
[00176] Still referring to FIG. 32, at 2b, the issuance of the PoA may be used for various purposes as desired. For example, the MNO network 3108 may be provisioned with a copy of a PoA that has been issued to the Entity A (e.g., UEAVTRU), a copy of a PoA that may be issued to an entity in the future, and/or a PoA for which only a PoA id has been issued to an
Entity. In an alternative example, a given Entity (e.g., UEAVTRU) may request the same services and privileges with a service provider (e.g., visiting network) as the Entity (e.g.,
UEAVTRU) enjoys when it is in its home network (FIN). In an example, the FIN may pre- provision the entire Subscription Profile (SP) associated with the Entity (e.g., UEAVTRU), which may be referred to herein as the Portable Subscription Profile (PSP), or relevant parts of the SP within the PSP. The PSP may be digitally signed using the UN's Private Key and stored securely on the UE. The PSP may also be protected for confidentiality and against replay attacks. Another example is for the FIN to only provision a globally or domain specific unique identifier of the
PSP, which can be referred to as the PSP Id. This PSP Id may be a decorated identifier (e.g., of the form PSP_Idl234@FIN.com). This PS Id may also be stored securely and protected for integrity, confidentiality, and/or against replay attacks by means of secure objects. The FIN may also provision the UE with the HN's Public Key / Digital Certificate. When an Entity (e.g.,
UEAVTRU) requests for a service, the Entity (e.g., UEAVTRU) may include the PSP as part of the request or in a following message to the service provider. The enforcement function (EF) at the service provider may then inspect the authenticity of the PSP by verifying the digital signature using the FIN's public key. In some instances, the Entity (e.g., UEAVTRU) may send both the PSP as well as the Public Key/Certificate of its FIN to the EFs. In other instances, a request may be performed by the EF to the Entity (e.g., UEAVTRU) or the UN or to the trusted third party (TTP) requesting for UN's Public Key/Certificate. In certain other cases, a TTP may store the PSP, which may then be provisioned to the Entity (e.g., UEAVTRU) or the EFs within the service provider network in an on-demand basis.
[00177] In scenarios where the Entity (e.g., UEAVTRU) requests the AuthF/TTP for authorization for service access, the Entity (e.g., UEAVTRU) may present both the PoA (e.g., Access Token) as well as the PSP to the EFs within the serving network. The EFs may verify the authenticity and validity of PSP using the Public Key/Certificate associated with the FIN, and may also verify the authenticity of the PoA using the Public Key/Certificate associated with the AuthF/TTP. Based upon the verification of the authenticity and validity of the both the PoA and/or the PSP, the EFs may enable access to the service for the requesting Entity (e.g., UEAVTRU).
[00178] Alternatively, the AuthF/TTP may use the PSP in order to create the PoA. The signed PoA may then be presented to the EFs within the serving network. The PSP may be provisioned to the TTP at 1, as shown in FIG. 32.
[00179] In some cases, the PSP may be updated OTA periodically by the Entity (e.g., UEAVTRU) or triggered by the FIN in order to synchronize the PSP with the SP. Triggering of this update and functions (e.g., TTP, AuthF) that may be involved may be governed by FIN operator provisioned policies.
[00180] In certain cases, only a PSP identifier (PSP Id) that identifies the location of the PSP may be communicated. The PSP Id may be a decorated identifier (e.g.,
PSP_Idl@ttpl.com), which may indicate the location (e.g., URI / URL) of the PSP. Similarly, a PoA may be a decorated identifier (e.g., PoA_Id@AuthF.com). The PSP Id and/or the PoA Id may then be used by the EFs, Entity (e.g., UEAVTRU), or the TTP, for example, to obtain the PSP and/or the PoA respectively, on a need-basis from the stored location.
[00181] Similarly, in certain cases, only a Public Key identifier or a Digital Certificate identifier associated with the FIN or the AuthF/TTP may be communicated. The Public Key identifier (PK_Id@ITN.com or PK_Id@AuthF.com or DigitalCert_Id@TTP.com ) or the Digital Certificate identifier may then be used by the UE and / or the EFs to obtain the Public Key / Certificate associated with the FIN or the AuthF/TTP.
[00182] A PoA may be a proof by which an entity can gain access to a service/slice. A PoA may be issued by an AuthF. A PoA may be in the form of messages (e.g., signed or unsigned), may use object security (e.g., tokens), or may be in the form of temporary certificates. [00183] An AuthF may sign an authorization message, for example, by using a digital signature or by a message authentication code. A signature may be based on the type of cryptographic algorithm being used (e.g., asymmetric or symmetric mechanisms). A message may carry, for example, one or more the following attributes: (i) From: AuthF, (ii) To:
Classifier/EF, (iii) Service: service 1/Slice-Id, (iv) Validity time period: Date/time validity and/or (v) Signature/MAC.
[00184] A message may be sent from the AuthF to a classifier, for example, instead of an EF. A single message may be sent (e.g., only) to a Classifier function, e.g., rather than send separate messages to each EF. A Classifier function receiving a message may issue PoA (e.g., tokens), which may be consumed by EFs (VNFs).
[00185] Referring now to FIG. 33, tokens may be signed or un-signed. A token may have a form similar to an OAUTH Access Token and may be encoded using JSON or XML or CBOR. Tokens may be a single token or may be chained or nested.
[00186] An example Service Access Token (SAT) is depicted in FIG. 33. The JWT registered claims: "iss, "sub", "aud", "exp", "iat", "nbf ', "jti" may be used according to IETF RFC 7519/7797. In addition, new custom claims may be used in accordance with various embodiments, which are defined herein and presented by way of example, without limitation:
• "authentication level" (authLevel): This claim may describe the level of authentication that was achieved, the value may be qualitative (e.g., None, Low, Medium or High) or quantitative (e.g., 1 (None) -10 (High)). This indicates the "subject's" authentication and the identity it is claiming to be. For privacy reasons the "subject" (entity) may use a pseudonym and that pseudonym may be authenticated without revealing the real identity of the entity. This claim indicates the level of authentication of that real identity or pseudonym.
• "identity _proofing_lev el" (idProofingLevel): This claim may indicate whether the actual identity of the "subject" has been authenticated and the level of authentication that was carried out. This claim may be subsumed as part of the authLevel claim if a pseudonym was not used. This may have values: high, medium, low or not applicable, for example.
• "security _assurance_level" (assureLevel): This claim may indicate the security assurance level and if the "subject" is the platform and then it indicates the assurance level of the platform (BIOS, firmware, OS, software, applications) of the platform as a whole. If the "subject" is a subscriber, this may indicate the "trustworthiness" of the subscriber, which may include "reputation" of the subscriber. "authentication factors used" (authF actors): This claim may indicate the actual authentication factors that were used. These authentication factors may indicate whether the subject's device (e.g., LTE_AKA, EAP-SIM..), password, biometric (finger-print, facial, iris, palm-print etc..) etc. have been used for authenticating the "subject."
"authorized role" (aRole): This claim may indicate whether the "subject" may be a system administrator, privileged user, privileged application, privileged machine, super- user or other roles defined within the "audience's" domain. In some cases, this may not be applicable at all.
"authorization type" (authType): This claim may indicate the type of authorization that was granted or used. The values may include, for example and without limitation: "role", "attribute-based" (ABAC), "discreationary_access_control" (DAC),
"mandatory _access_control" (MAC), "rule_based_access_control" etc.
"service_type" (servType): This claim indicates the type of service that the "subject" is being authorized for: eMBB, URLL, MMTC, Voice call, Internet access, etc. This may also include one or more the service types and therefore the "subject" may be authorized to more than one service types.
"service_specific_parameters" (servParams): These claims may indicate the parameters for service class / QCI for both QoS (e.g., bandwidth, latency, jitter, etc.) as well as Security requirements for the service(s) that are being requested, such as integrity and confidentiality of control plane, integrity and confidentiality of user plane, etc.
"service_qos_parameters" (servQoSParams): These parameters may contain values for bandwidth, jitter, delay, etc for the service / slice(s), for hop— by -hop as well as end-to- end cases.
"service_security_parameters" (servSecParams): These parameters may contain the security level required for the service such as integrity and confidentiality for the service / slice(s) from both user and control planes, requirement for security at the Access Network (RAN, WiFi access etc.), security requirements at the Core Network and security requirements for end-to-end (application to service), or at each of the OSI layers (e.g., use of (D)TLS, IPSec etc.).
"payment_parameters" (payParams): These claims may indicate the amount for which a payment has been done and the type of monetary currency that was used (e.g., US Dollar, Bitcoin etc.). • "customized claims" (custClaims): These may be claims that are custom-built based upon SLAs between a Service Provider, MNO operator, or Trusted Third Party entity. These claims may be protected for confidentiality as well, for example, so that only authorized entities are able to read these claims.
[00187] Tokens may be chained so that each of the VNFs within the SFC may be able to verify the token intended to that respective VNF, and process the token. The tokens may also be encrypted so that only that specific VNF may be able to de-crypt the token. An example chained token structure is depicted in FIG. 34.
[00188] As an alternative, the AuthF may issue one or more temporary certificates, which can be used to verify authorization and additionally authenticate the UE. The UE can then use the certificate to setup secure communications channel with the Classifier and/or VNFs.
[00189] PoAs may be exchanged to obtain long-term or short-term security credentials. As an example, a token may be exchanged to obtain a certificate and a private key associated with the credential. The private key may sent to the UE using secure communications channel (e.g., setup by means of TLS with Ephemeral Diffie Hellman). Alternatively, the token may be exchanged to setup and establish a symmetric key between the UE and a trusted entity within the service provider network. These credentials may be used to generate session keys with the service provider network functions and end entities.
[00190] Referring now to FIG. 35, another example of a Proactive Authorization Framework (PAF) 3500 is shown, which includes a UEl, AuthF 3502, a VNF1 (which may include an enforcement function), and a VNF2. In accordance with the example embodiment, at 1, the UEl (WTRU) sends an Authorization Request (e.g., containing its identity and/or the application identity) to the AuthF 3502 requesting authorization. The UEl may send information about requested Service(s)/Slice-Id to the AuthF 3502, at 1. At 2b, the AuthF 3502 may generate one or more Challenges, for example, based on policies described herein, to determine the risk and associated authorization checks that may be carried out. At 3, the AuthF 3502 may send the one or more Challenges in an Authorization Response message to the UEl . In some cases, the Challenges may include more than authentication checks (WTRU/user). For example,
Challenges may include validations checks on platform integrity. At 4, in accordance with the illustrated example, the UEl computes one or more results in response to the Challenge(s). In some cases, the results may be cryptographically generated or may be responses containing validation checks. At 5, in accordance with the illustrated example, the UEl may send the result(s) to the AuthF 3502, for example, in an Authorization Response message. [00191] Still referring to FIG. 35, in accordance with the illustrated example, at 6, the AuthF 3502 may verify the result(s) and may generate and issue appropriate PoA(s). The PoA(s) may be, for example, chained tokens or a single token, as described above. The AuthF 3502 may (e.g., in addition to the PoA) generate PoA usage, which may provide details on how the PoA may be used and targeted/sent to the VNFs (e.g., EFs). A single token may be issued, for example, when a classifier is present. At 7, the AuthF 3502 may send the PoA(s) and associated PoA_usage to the UE1. At 8, the UE1 may use PoA_usage, for example, to determine how the PoA may be appended to a slice access request message. At 8, the UE1 may send a Slice Access Request message containing the PoA(s) to the Classifier/VNFs, for instance VNFl.
[00192] At 9a, the VNFl may (e.g., upon receiving the Slice Access Request message) verify the PoA. At 9b, the VNFl and may process the message from the UE1. In some cases, the VNFl only processes the token associated with a particular VNF, for example, when the PoA is a chained token. The VNFl may determine the next VNF (e.g., VNF2) that the message may be forwarded to (at 9c).
[00193] At 10, the VNF 1 forwards the message to the next VNF (VNF2), for example, based on the information provided in the SFC that may have been pre-provisioned to it by the SN. In some cases, the VNFl may remove the token associated with it. The token might not be removed, for example, when the PoA is a nested token, given that removal may affect the overall integrity of the token. At 1 la, the VNF2 may verify the PoA (e.g., similar to the process performed by VNFl). The VNF2 may process the token associated with the VNF2 and may then process the message. At 1 lb, the message may be forwarded to another VNF or a response may be provided, for example, when VNF2 is the last entity in the SFC,.
[00194] At 12, the VNF2 may send an Ack back to the VNF 1. The VNF 1 may also generate an Ack (which, in accordance with the illustrated example, may include both Acks, one received from VNF2 and one generated by VNFl) and may forward it to the UE1.
[00195] Referring now to FIG. 36 an example of a Proactive Authorization Framework 3600 is shown in which the MNO 3108 is used a Trust Anchor. MNO trust may be leveraged for access to outside services. Enforcement functions (EF1, EF2, EF3) may have a trust relationship with the MNO 3108. Policies for access control to services (e.g.., Service 1, Service 2, etc.) that may be enforced by respective EFs may be negotiated before-hand between the MNO 3108 and the service providers (e.g., service may be provided by third parties other than the MNO). A PoA may be used for authorization purposes, so that an entity (Entity A) can gain access to a service/slice. [00196] Referring now to FIG. 37, an example Reactive Authorization Framework (RAF) 3700 is shown. The Entity A may request a service (e.g., service 1) from a service provider, which may have an EF1 that performs access control on behalf of the service. EF1 may (e.g., based on the request from Entity A) request authorization from the AF 3102. The AF 3102 may request additional authorization information from the ACPF 3104. The ACPF 3104 may create consolidated access control rules, for example, based on authorization information obtained from a WTRU/subscriber profile 3112, general operator policies (e.g., obtained from a management function), and/or service/slice information 3110. In some cases, the AF 3102 may have been pre-populated with certain authorization information before-hand. The AF 3102 may determine whether the WTRU (Entity A) can be authorized to access Service 1, and may send access control rules to the EF1. The EF1 may use the rules to grant or deny access to Service 1. The access may include various restrictions, for example, with respect to date/time, location, role, charging, etc. Access control rules may specify revocation of authorization, for example, based on a change in location, time, role and/or payment, subscription, or charging information. Authorization may conversely be extended, for example, when there is a change in one or more of a payment, subscription to a service, role of subscriber/user/ WTRU, location of WTRU and/or other parameters relating to authorization.
[00197] Referring now to FIG. 38, in accordance with the illustrated example, at 1, a UEl/Subscriber (which may also be referred to as a WTRU1, without limitation) sends a Slice Access Request containing its identity (permanent, temporary and/or protected identity) and/or the application identity to a Service Provider Network. The request may be sent to network entity that works as an EF. The EF may be a router, switch, application server or anything else that may perform one or more access control function(s) and may be implemented as a VNF. In a 5G network, the EF (e.g., VNFl) may also perform the role of slice classifier/router, so that messages for a certain slice can be routed to that slice. As part of the message, the Subscriber may also send information about requested Slice(s)/Service(s)/Slice-Id(s) to the VNFl. In certain cases, if there is a pre-existing and active (fresh and valid) authorization for example, then a PoA(s) associated with such a slice(s)/service(s), may be included as part of the Request message. The message may indicate the level of QoS, security level, and duration for how long the service / slices are required. The UE1 may be operated by a subscriber (e.g., User) of the device and therefore the terminology subscriber may be used to refer to a device, a user, or both.
[00198] At 2, the VNFl, upon receiving the Slice Access Request message, checks authorization for the Subscriber/UEl. If there has been no prior authorization that is active and valid, then the VNFl may issue an Authorization Request message containing an id of the Subscriber/UEl and information on Service(s)/Slice-Id(s) to an AuthF. If the PoA is a chained token, for example, then the VNFl might only process the token associated to that particular VNF. The VNFl may determine the next VNF that the message may have to be forwarded to and passes it forward, as described above. VNFl then may generate a Slice Access Response, verify the PoA(s), and then process the message from the Subscriber/UEl .
[00199] In some cases, if a prior authorization that is valid and active is available at the VNFl, then it might not generate an Authorization Request message. The process may jump to 12, where a "success" value within the Slice Access Response message is issued.
[00200] In accordance with the illustrated example, at 3, the AuthF sends a request to the ACPF for policies and procedures for authorizing the UE1 to access particular Slice(s)/ Service(s). The AuthF may send the identity (permanent, temporary, protected identity) of the Subscriber/UE as well as information about the slice(s) / service(s), QoS level, security level, and the duration for access to slice(s) / service(s). In some cases, the ACPF may be viewed as a repository for policies and information and of similar functionalities as a Policy Information Point (PIP) and/or Policy Retrieval Points (PRP), or the ACPF may be viewed as an entity that is capable of querying a PIP and/or PRP. In some cases, it may be assumed that the ACPF has an interface to the Subscriber Profile DB and Slice/Service information DB.
[00201] Based upon the request from the AuthF and the information that was obtained by the ACPF using the Subscriber DB and Slice DB, the ACPF may generate Subscriber /or UE specific policies, at 4. At 5, the ACPF may send Subscriber and/or UE-specific policies to the AuthF.
[00202] At 6, based upon the Subscriber / UE-specific policies, the AuthF may generate consolidated authorization policies, which may then determine if one or more challenge(s) have to be generated in order to establish the authorization of the Subscriber/UE. A challenge that is generated may be a simple query to request PoA from a UE, or in some cases, may be used to perform additional authentication checks of the Subscriber/UE. In other cases, using the RAF model, a challenge might not be generated and only the consolidated
authorization polices are generated, which may determine if the challenge(s) have to be generated at all. If the AuthF determines that the Subscriber/UEl has been authorized, for example, then the AuthF may optionally generate a PoA.
[00203] At 7, the AuthF may send the generated policies within an Authorization
Response message to the VN1/EF. If Challenge(s) were generated, for example, then they may be sent to the VNF1-EF as well. Also, if PoA(s) were generated, then they may be sent to the
VNFl/ EF as well. At 8, the EF/VNF1 may store the consolidated authorization policies and if PoA(s) were sent by the AuthF, then they may be stored as well. If the authorization policies do not require performing additional authorization checks, then the message flow may jump to illustrated Step 13 in accordance with an example.
[00204] If additional authorization checks are required by the authorization policies, at 9, a challenge is presented to the Subscriber/UEl. The EF/VNF1 may send the challenge within an Slice Access Response message. At 10, the UEl may compute the Result(s) using the Challenge(s). Results may be cryptographically generated or may be responses containing validation checks. At 11, the UEl may send the Result(s) to the AuthF in a Slice Access Request message. The Results may be sent in the form of one or more PoA(s), which may be signed by a private key within the secure element (e.g., UICC, TPM, TEE) present within the UEl. At 12a, the VNF1/EF may verify the Result(s) using the previously stored authorization policies. If a Classifier is present, then the VNF1 may forward the message to the next VNF (at 12c) based upon the information provided in an SFC that may have been pre-provisioned to it by the SN. The VNF1 may send a message (at 12b) to the appropriate Core Network (CN) Function and/or Access Network (AN) Functions indicating reservation of appropriate network resources in order to be able to serve UEl/Subscriber's' service access request. The message may optionally contain one or more PoA(s), or it may send appropriate resource reservation messages to the CN and/or AN functions. At 13, the VNF may send a Slice Access Response message indicating successful authorization. At 14, service(s) may then be offered via slice(s) to the
UEl/Subscriber.
[00205] FIG. 39 shows another example of high-level authorization procedures described herein. A high-level authorization procedure may be implemented in a distributed or centralized manner. Functionalities described herein may be implemented, for example, by enhancing functionality in a variety of authorization architectures to provide authorization for 5G systems using dynamic authorization schemes.
[00206] For example, a Policy Information Point (PIP) may contain information about various attributes that may be used for determining authorization. Examples of attributes may include, for example, subscriber profile information, slice/service information, device information, etc. The PIP may include, for example, HSS, NSMF, etc.
[00207] A Policy Retrieval Point (PRP) may be a function used by an entity that hosts one or more of general operator policies, slice/service policies, subscriber and device policies, general security policies (e.g., authorization/authentication), etc. A PRP may be, for example, a
Policy and Charging Rules Function (PCRF). A PRP may aggregate various policies for slice/service access, for example, to create a policy rule that may be used by a PDP. [00208] A Policy Decision Point (PDP) may be a function that makes a decision based on authorization decision information, for example different policy rules generated by the PRP, or WTRU subscription information. An authorization decision may be made by comparing the authorization decision information to a WTRU's request. In an example, a PDP function may be performed by an AF. An AF may be, for example, a ProSe Function. A PDP/AF may generate, for example, based on authorization checks, an authorization decision output or authorization information. The authorization information may be sent to the WTRU that requests access to a slice, for instance directly to the WTRU or via an access control device. The authorization information may include a proof-of-authorization or an authorization grant decision. For example, the authorization information may be in the form of a PoA, or may include an acceptance or denial of the access request, or may include a request for additional information, which may be in the form of a PoA, an acceptance/denial of access or a request for additional information. A PDP may be located in the domain of the Operator or may be part of a Trusted Third party network.
[00209] A Policy Enforcement Point (PEP) may be a function that enforces policies. A PEP may provide access to a service, e.g., based on verifying PoA. In an example (e.g., ProSe), an eNB or MME may be the entity that provides PEP. PEP functionality may be performed by a WiFi access point, e.g., for WiFi access.
[00210] Still referring to FIG. 39, the WTRU (UE) may request authorization for access to a service (e.g., Prose Direct Discovery and/or Direct Communication) from the AF. A request may be sent during and/or after WTRU attachment to the network. A request (response) may be transported over a signaling protocol (e.g., NAS) or over the user plane (e.g., IP), for example, when a WTRU was granted an appropriate bearer (e.g., default bearer) in a prior attachment.
[00211] The PDP/AF may obtain authorization rules from a PRP (e.g., PCRF). The AF may request authorization rules using a reactive process. The request for rules may be formed after receiving an authorization request from a WTRU. The PDP may create a specific request to the PRP (PCRF), for example, based on the request from the WTRU. Authorization rules may be generated beforehand, e.g., in a proactive manner. Rules may be pre-populated or subsequently populated.
[00212] A PRP may obtain policies, subscriber information, device information, slice/service information etc. from PIP, which may involve various data sources (e.g., HSS,
NSMF). The PRP may aggregate various policies and generate authorization rules. The process may be a pro-active process or may be a reactive process. In an example of a proactive process, the PCRF may have generated rules beforehand and may provide the rules to the PDP. In an example of a reactive process, the PRP may perform the generation of rules based on a request from the PDP.
[00213] As described herein, an authorization decision may be made by comparing a request for service access to one or more of policies or rules. In one example authorization flow, an AF uses an Access Control List (ACL) to perform a first level of authorization. The ACL may be created by the ACPF or by the AF. The ACL may be included in one or more of a UE subscription profile, types of service access information, slice information, or general operator policies. During this authorization check, the AF may check the ACL to determine if a UE should be allowed access to the requested service. Accordingly, the AF may provide authorization information that indicates an authorization grant decision. For example, the indication of the authorization grant decision may comprise a binary authorization to allow access or not.
[00214] The ACL may also include supplementary information that indicates whether supplementary authorization checks, for instance a supplemental dynamic authorization, should be carried out. In one example, when a check against an ACL indicates that access is not allowed, a further level of authorization checks (supplemental authorization) may be performed. The supplemental authorization may include, for example, checking the various requested service parameters against those available from one or more slices, performing or verifying authentication of the UE's platform identity, determining the integrity or trustworthiness of the UE's platform (e.g., verifying the software version, patches installed, etc), performing or verifying a user authentication, determining the subscription of the UE, soliciting a pre-payment for the requested service, determining a risk associated with the UE accessing the requested service, etc. As part of the supplementary checks, in some cases, the AF/UE may invoke the services of other functions to perform the authorization checks. The secondary (supplemental) authorization checks may result in allowing the UE to access the requested service from one or more NSs, and each NS may be authorized independently. In some cases, if one or more of the checks fail, the ultimate authorization decision may be to deny access.
[00215] In some cases, the result(s) of the authorization checks, which may be generally referred to as authorization information, may be returned in a response message to the
UE, such that access to the service is granted or defined. In an example, the authorization information that is sent to the UE includes a PoA, which may capture the authorization result as well as include additional information elements that may provide more granular information with respect to the authorization. By way of example, a given PoA may be required to be consumed immediately to consume a service, or a given PoA may be permitted to be used at a later time to consume the requested service.
[00216] The AF may (e.g., based on rules obtained by the AF) perform one or more additional or supplementary authorization checks. In an example, a WTRU may be
authenticated with a higher degree of assurance, the WTRU's platform may be checked for integrity, a subscriber may be authenticated (e.g., using multi-factor authentication mechanisms) and/or the subscriber may be requested to show proof of payment or subscription. The procedure may be based on the risk assessment associated with the service request.
[00217] The AF may (e.g., based on the results of the authorization checks) provide a PoA to the WTRU. The PoA may be in the form of one or more Access Tokens (e.g., chained, nested), a signed message or a digital certificate. The type of PoA may be based on the capabilities associated with the PEP (e.g., eNB, MME) in the service provider network. A signed message may be provided by the AF to the EF using secondary channels, for example, when the eNB is unable to process an Access Token. A signed message may be sent, for example, using a backbone network without involving a WTRU. A WTRU may be able to request a certain type of PoA based on limitations/capabilities of the WTRU. A PoA may be provided to the WTRU using a secure communications channel. The AF may request the PRP/PCRF to update the subscription profile of the WTRU with the new authorization results. The subscription profile may be stored in HSS.
[00218] The WTRU (UE) may store the PoA, for example, depending on the type and validity of the PoA. The PoA may be usable one or more times and may (e.g., in certain cases) be used with different EFs. The scope of a PoA may be enumerated in the PoA. The scope and usage of an access token may be described in the token using JSON encoding. The PoA may be stored in a secure manner.
[00219] The WTRU (UE) may present the PoA to the PEP/EF (e.g., eNB, MME). In an example (e.g., ProSe), an EF may be an entity in the RAN, such as an enhanced eNB that may be able to process the PoA. An EF may be an entity in the core network (e.g., MME function) that may be able to process the PoA. In an example, a WTRU may not present the PoA. The PoA may be provided to the EF by the AF using a backbone/core network (secondary channels). The PoA may apply to the serving PLMNs and to PLMNs determined by the HPLMN as local PLMNs. A WTRU may present the PoA to the EF using a secure communications channel. A request may (e.g., alternatively) be sent during and/or after WTRU attachment to the network. The request (response) may be transported over a signaling protocol (e.g., NAS) or over the user plane (e.g., IP), for example, when the WTRU was granted an appropriate bearer (e.g., default bearer) in a prior attachment.
[00220] The EF may verify the PoA and may determine the type of service access that has to be provided to the WTRU. The EF and AF may share a trust relationship. The EF may be able to verify signatures generated by an AF. The EF may be provisioned with the public key/certificate of the AF or they may have established a symmetric key with one another, e.g., with a certain lifetime. The EF may optionally create an Access Control Policy local to the EF, e.g., based on the information provided as part of the access token. The ACP may be used for future service access requests by the same WTRU. Future requests for service access by WTRU may not have to undergo the whole authorization procedure(s), for example, when the EF has a valid ACP (e.g., an ACP that is accurate and has not expired). The WTRU may not have to present access token(s), for example, when a valid ACP is present. The creation of ACP may reduce the overall messaging overhead on the WTRU and AF. The EF may manage the ACPs, which may become cumbersome, for example, when there are a very large number of WTRUs that request a wide range of services. Managing and use of ACPs may be determined based on policies of the service provider.
[00221] The WTRU/ Application on WTRU/Subscriber may be provided access to the service, for example, after the EF verifies the PoA. A service may be restricted. In an example (e.g., ProSe), a service may be a discovery service (e.g., of ProSe) rather than an announced service.
[00222] FIG. 40 depicts an example of a Proof-of-Authorization (PoA), in particular a Service Access Token. The PoA (Service Access Token) may be issued by an AF. A token may comprise a header, claims, and signature fields. In an example, fields may include one or more of the following: typ, kid, alg, iss, sub, aud, exp, iat and/or jti.
[00223] A "typ" field may indicate that a token is encoded based on the JSON Web Token (JWT) standard or CBOR Web Token (CWT). A CWT may be used, for example, for WTRUs that may have constrained resources for computing, memory and/or battery.
[00224] A "kid" field may indicate a credential identifier associated with the AF and may indicate either a certificate id, public key identifier and/or public key may be used as the kid. The kid may be a credential identifier associated with a symmetric key. The kid may uniquely identify a public key credential associated with AF. In an example (e.g., symmetric key), a kid may identify a credential associated with the AF and the eNB/MME. [00225] An "alg" field may represent the type of algorithm to be used to generate the signature. In an example, "RS256" may indicate that it uses the RSA algorithm using a 256 bit hash.
[00226] An "iss" field may indicate that the issuer is an AF located or associated with ttp.com (trusted third party).
[00227] A "sub" field may indicate the actual subject requesting authorization. In an example, a subject requesting authorization may be WTRUl@att.com. This field or attribute may contain the IMSI, temporary ids (e.g., TID), etc.
[00228] An "aud" field may indicate an intended audience of the token. In an example, the audience may be eNBl@att.com, eNB2@att.com or MMEl@att.com. The "aud" may, for example, imply that WTRU1 has been authorized to access the service using eNBl, eNB2 or MME1 that resides in the ATT trust domain. The "aud" may be a list of EFs. The "aud" may have values that may belong to a different operator (e.g., Visited PLMN), which may indicate that a WTRU has been authorized to access services using eNB in a different PLMN.
[00229] An "exp" field may indicate when access to a service may expire.
[00230] An "iat" field may indicate an issuing date by the AF for an access token.
[00231] A "jti" field may indicate a unique token id.
[00232] Claims may be referred to as Service-Specific Claims (SSC). In some cases, claims are used for access control for a particular class of service and/or individual service(s). In an example (e.g., as shown in FIG. 40), a token may describe claims related to a ProSe service. In some examples, the token structure is generic enough so that it may be tailored to individual services. In an example, SSCs may include one or more of the following: serv, pro-app code and pro code suf. Security specific claim relating to authenticity of the token by including one or more signatures represented by "sig."
[00233] In some examples, a "serv" claim is a custom claim that indicates the service for which the WTRU has been authorized. This may include a list of one or more services. Examples of services that may be authorized include, without limitation, ProSe Discovery, which may be indicated by prose disc, ProSe Announce, which may be indicated by prose annoc, etc. A claim may contain multiple services, such as ProSe, real-time video, MBMS, etc.
[00234] A "pro app code" claim may be specific to ProSe and may contain the ProSe application that has been authorized. A custom claim relating to MBMS may (e.g., similarly) be included (e.g., in addition or alternative to ProSe). [00235] A "pro code suf' claim may be similar to a "pro app code" claim. A "pro code suf ' claim may be specific to ProSe and may be used for performing access control by the EF (e.g., eNB, MME).
[00236] In some examples, a Service Access Token contains various security claims. A "sig" claim may indicate a signature of the message generated by the AF. The signature may be created by hashing the token claims using hashing algorithm (e.g., SHA-256) as inputs and digitally signing the hash using a private key associated with the AF's public key.
[00237] Token/claims may be transmitted as a JSON object used as the payload of a JSON Web Signature (JWS) or as the plaintext of a JSON Web Encryption (JWE) structure, which may be digitally signed or integrity protected using a Message Authentication Code (MAC) and/or encrypted. The token may alternatively be transmitted using a secure connection channel (e.g., TLS).
[00238] Referring now to FIG. 41, an example of a multi service authorization with a caching architecture 4100 is shown. FIG. 41 illustrates an example of an authorization architecture 4100 for a plurality of independent MNO services (Services X, Y, etc.) with caching capabilities, for example, by a centralized AF 4102. In an example, a tiered authorization is provided for each service. The AF 4102 may act as a central anchor point for MNO services basic level authorization (Tier 1) and application level authorization by a third party Application Server (Tier 2). In some cases, Tier 1 authorization may bind MNO service usage to a particular subscription, which may be conditional based on device capabilities. Tier 2 authorization may bind a particular application session (e.g., mobile app session) to an MNO service session and associated network resources that may have been allocated for it (e.g., radio resources). Thus, authorization may be provided (e.g., generically) for MNO services and applications enabled by MNO services, e.g., in contrast to ProSe, which may be specific to a particular MNO proximity service.
[00239] Still referring to FIG. 41, the AF 4102 may obtain access subscription information from a Subscription Database (SDB) 4104. The AF 4102 may obtain services information from a Service Directory (SD) 4106. In some cases, the SD 4106 and the SDB 4104 may be integrated with each other (e.g., evolved HSS augmented rich service data description).
In some cases, a separate SD may offload a critical node (e.g., SDB) for service details storage and maintenance. In an example, the AF 4102 may interact with the SDB 4104 and the SD 4106 via a Subscription and Services Information Broker (SSIB) 4108. In some cases, the AF 4102 and the SSIB 4108 may be co-located/integrated. In some cases, the SSIB 4108 may act as a facade of the SDB 4104 and/or the SD 4106 for the AF 4102. The AF may use a Service Authorization Cache (SAC) 4110, which may contain authorization information derived from SDB/SD data. The SAC 4110 may enable faster authorization operation and/or reduce signaling overhead towards the SDB/SD. In some cases, a WTRU (UE) 4112 may use an operator service enabled application with an Application Server (AS) (e.g., AS 4114a and AS 4114b) to communicate with the AF 4102.
[00240] The AF 4102 may authorize/configure the UE 4112 for a particular operator service (e.g., Tier 1 authorization), for example, based on: (i) user authorization information and/or (ii) Access Policy Rules 4114 that may include device capabilities criteria.
[00241] In some examples, the AF 4102 may grant a WTRU/ Application access to a particular operator service (e.g., Tier 2 authorization) based on, for example and without limitation: (i) prior WTRU Tier 1 authorization context and/or (ii) authorization verification conducted with the AS for the application. The AS may maintain a binding between the operator service and application sessions.
[00242] Turning now to FIG. 42, an example tiered authorization 4200 is shown. Fig. 42 shows an example of a tiered authorization for a plurality of independent MNO services (X, Y, etc.) with caching capabilities provided by the Centralized AF 4102.
[00243] Referring to FIG. 42, at 0a, the example authorization may include a user subscription being provisioned (e.g., on the network side) with a list of services (Services X, Y, etc.) At 0b, an application may be pre-configured on the UE 4112 (e.g., App installed on phone, user signed in with Application Server 4114). In an example, the UE 4112 may consume a service, for example, when the UE 4112 is pre-configured by an operator with Service authorization and configuration information (e.g., in ME/UICC). An example use case this consumption may be for Public Safety WTRUs in ProSe with direct communication/discovery capabilities "out of the box" without the need for additional OTA authorization/configuration. In an example, Authorization Enforcement points may be setup in the network (e.g., in the
RAN/eNodeB via MME or in the Core via PCRF) automatically as part of initial network attachment procedures.
[00244] At 1 , in accordance with the illustrated example, the UE 4112 (WTRU) requests authorization to use Service X on behalf of the user. An MNO User Id may be, for example, an IMSI. Service X may be a name or object describing a service (e.g., "ProSe"). A request may be triggered by an application (e.g., fresh start) or implicitly by a middleware or an OS service (e.g., at device boot) on behalf of one or more applications that might use a common service on a device. A request may also be triggered to renew an expiring or expired
authorization. [00245] At 2, the AF 4102 may look up the SAC 4110 for an entry associated with a particular user to check whether the user is authorized to use service X. An entry might not be found, for example, when it is the first time connecting (e.g., new activation), or when the cache entry has expired (e.g., out of coverage for a long time, no authorization renewal in validity period). A pre-caching of service authorization information for the user may be (e.g., alternatively) performed, for example, when a user first authenticates with the network. This may be realized, for example, by a notification from the Subscription and Service Information Broker (SSIB) 4108 toward the AF 4102 during a network attachment procedure.
[00246] At 3, the AF 4102 may request the SSIB 4108 for a particular user and service. A flag for bulk retrieval may be set to retrieve other services that may be provisioned to the user. At 4, the SSIB 4108 may forward the request to the SDB 4104, which may return the list of services authorized for the user.
[00247] At 5, the SSIB 4108 may request detailed service information for one or more of the services from the SD 4106. The SD 4106 may return the list of detailed service information, which may contain the list of applications authorized to utilize a particular service. Application information may contain its unique id, a third party AS address (e.g., URL) and/or additional elements, such as application supported service enabled commands (e.g., ProSe "announce," "monitor"). An AS address may be implicit in an application (e.g., a decorated app name).
[00248] At 6, the SSIB 4108 may return to the AF 4102 the list of detailed service information authorization for the User. At 7, the AF 4102 may write user service information into the SAC 4110. Cache entries may be assigned an expiration, for example, based on caching configuration and/or operator policy.
[00249] At 8, the AF 4102 may generate a Service Unique Id (UID) for the service session, which it may map to the MNO User Id (e.g., IMSI). Authorization Enforcement points may be setup in the network (e.g., in the RAN/eNodeB via MME and/or in the Core via PCRF).
[00250] At 9, the AF 4102 may return an authorization response to the UE 4112. A response may contain, for example, the Service UID and a service session validity time. A response may contain other configuration elements, such as a validity area (e.g., authorized
PLMN or Region or Country). At 9a, the UE 4112 may communicate the Service UID to an application server, for instance AS 4112a. Communication may be application/service specific.
The AS 4112a may return an App UID to the UE 4112 and may keep a mapping to Service UID.
UID may be used for tighter authorization coupling of the AF 4102 and AS 4112a while concealing MNO User Id and AS login from one another. [00251] At 10, the UE 4112 (WTRU) may request authorization to use Service X by a particular application. A request may be triggered, for example, by a user interacting with the application or by an IoT device on an environmental trigger (e.g., sensor). Parameters provided may include an application Id, which may allow the AF to know which AS to reach), the application supported service enabled command (e.g., ProSe "announce," "monitor") and/or the App UID (e.g., when previously obtained from the Application Server). The App Context/ API Object parameter may, for example, be encoded using JSON or XML to accommodate a multitude of different services and their specific commands.
[00252] At 11, the AF 4102 may look up the SAC 4110 for an entry associated with a particular user, for example, to check whether the user is authorized to use service X. SAC 4110 may return an entry that confirms the user is authorized to use Service X with a particular Application. The AF 4102 may request (e.g., based on AF policy and API object content) further authorization from the AS 4114a associated with the particular application (at 11a). At l ib, the AS 4114a may return an authorization response that may include the Service UID corresponding to the App UID, for example, when the App UID was provided in the request. The AF 4102 may check whether a service UID is associated with a particular user, for example, when the Service UID is present in the response. The AF 4102 may cache AS authorization data into the SAC 4110. A cached entry may be exploited for subsequent requests, for example, to avoid requesting the AS again (e.g., app restart).
[00253] Authorization Enforcement points may be setup in the network (e.g., in the RAN/eNodeB via MME and/or in the Core via PCRF). At 12, the AF 4102 may return an authorization response to the UE 4112. A positive response may constitute a Proof of
Authorization (PoA) that may refer to service/ Application specific configuration elements and a validity time/area (e.g., PLMN, etc.). The App Context Response may, for example, be encoded using JSON or XML to accommodate a multitude of different services and their specific response.
[00254] At 13, in accordance with the illustrated example, the UE 4112 (WTRU) may consume the service with App A. It will be understood, as depicted at 14-17, that the UE 4112 may access another Service (Service Y) sought by another application (App B) that is associated with a different AS (AS 4141b).
[00255] Table 1 shows an example mapping of parameters between a generic tiered authorization procedure and ProSe. Table 1
Figure imgf000055_0001
[00256] Referring now to FIG. 43 an example authorization update/revocation 4300 is shown. In an example, the update/revocation 4300 may be triggered by a subscription update, for instance an update to the user subscriber profile in the SDB 4104. Service authorization or revocation may be carried out automatically, for example, based on change in status of the WTRU/user/application. Examples of change in status may involve, for example, change in location of the WTRU (which may be inferred using GPS location information), depletion of credit (e.g., dollar amount), date/time, change in role, etc.
[00257] In accordance with the illustrated example, at 0, the UE 4112 (WTRU) may be authorized and configured for MNO Service X, for example according to an authorization 4200. At 1, MNO Service X with other services related subscription data may be updated (e.g., change of PLMN or Region where service is authorized or service subscription termination). The SDB 4104 may send a Service Subscription Update Notification for the User to the SSIB 4108. At 2, the SSIB 4108 may retrieve (e.g., from the SD 4106) detailed data associated with affected Services. At 3, the SSIB 4108 may send (e.g., to the AF 4102) a Service Information Update Notification for the User. At 4, the AF may update related data in the SAC 4110. At 5, in accordance with the illustrated example, the AF 4102 detects that the user has an active authorization for Service X. At 6, the AF 4102 may send a Service Information Update Notification to the UE 4112, for example, immediately or when the UE 4112 communicates with the AF 4102 again, for example, based on Access Policy Rules to update or revoke authorization information. At 7, the UE 4112 (WTRU) may update authorization information accordingly. [00258] FIG. 44 depicts another example of an Authorization Update/Revocation 4400 that is triggered by the AF 4102 (e.g., Operator Policy). Referring to Fig. 44, at 1, the AF 4102 may update authorization data for a User for Service X, for example, in response to operator policy. At 2, the AF may update related data in the SAC 4110. At 3, the AF 4102 may send a Service Information Update message to the SSIB 4108 for the impacted User. At 4, the SSIB may forward the message to the SDB 4104, which may update service subscription data accordingly.
[00259] Referring now to FIG. 45, in accordance with an example embodiment, Multi- domain authorization with distributed enforcement may be applied to CP/UP traffic flows, using an SDN architecture 4500. The example SDN architecture includes a distributed AF 4502 for CP/UP access control enforcement. The a centralized AF 4502 may handle authorization for a WTRU 4504. The centralized AF 4502 may be implemented, for example, by an Access Control Policy Function (ACPF) 4506 and Enforcement Function (EF) 4508 sitting on top of an SDN infrastructure 4510. In various examples, distributed authorization enforcement may be applied to a network. In an example, the WTRU 4504 may access a service provided by a Network Slice (NS) that spans across multiple Network Domains. As shown, Slice #1 spans across two different Network Domains (ND #1 and ND #2). The network domains may have a master-slave relationship. In the illustrated example, ND #1 may act as the master domain. The AF 4502, within ND#1) may handle authorization to access a service (e.g., slice) on behalf of the WTRU 4504. In an example, the AF 4502 may be a third party application server (e.g., outside the operator network domain). The ACPF 4506 (e.g., PCRF in ND#1 and ND#2) may control and centralize the policy decision with regard to slice/service access control. The ACPF 4506 may use one or more input parameters (e.g., operator defined polices, network real-time operational status, user subscription, device capabilities, etc.), for example, to generate policy rules that may be provided to the EF 4508 for enforcement.
[00260] In some cases, the EF 4508 (e.g., PCEF in ND#1 and ND#2) may enforce traffic handling policy rules received from the PCRF on data forwarding infrastructure, which may be realized by an SDN Switch Fabric 4510 (e.g., one SDN Controller per domain with a set of Routers/Switches). The EF 4508 may act as an SDN Application on top of an SDN Controller
North Bound Interface (NBI). A central User/WTRU DB 4512 (e.g., UUDB or HSS in ND#1) may be queried by the ACPF 4506 for user/device identification and profile information. A
Network Slice Management Function (NSMF) 4514 (e.g., ETSI MANO in ND#1 and ND#2) may be in charge of NS deployment/management (e.g., M messages). A Charging Function (CF)
4514 (e.g., OCS in ND#1 and ND#2) may provide real-time charging, for example, using session events or flow data usage counters from the ACPF/EF, or by enabling dynamic authorization policies in ACPF based on real-time credit control.
[00261] Still referring to FIG. 45, in accordance with an example, at 1, the UE 4504 (WTRU) sends a request to a network to use or access a particular service in Slice#l . In an example, a request (response) may be sent during and/or after UE attachment to the network (e.g., in a 3 GPP network). The request (response) may be transported over a signaling protocol (e.g., NAS) or over the user plane (e.g., IP), for example, when the WTRU is granted an appropriate bearer (e.g., default bearer) in a prior attachment. The request may be forwarded to the AF 4502 in ND#1. Request forwarding may be accomplished (e.g., in a 3GPP network), for example, by the serving eNodeB, which may query a DNS service for AF selection.
[00262] At 2, the AF 4502 may forward the authorization request to the ACPF 4506 to verify User and/or Device authorization for the particular Service. At 3, the ACPF 4506 may verify against the UUDB 4512 for User/Device authentication and authorization. In some cases, the ACPF 4506 may also verify against a CF, for example, to make a policy decision based on a subscriber charging status (e.g., user spending limit).
[00263] At 4, the ACPF 4506 may obtain from the NSMF 4514 detailed information concerning how the service is realized in the network infrastructure. The detailed information may include, for example and without limitation, Service Function Paths (SFPs) rendering the chaining of the CP and UP NFs that may provide the service to the WTRU. The detailed information may include, for example, Real-time network usage data, e.g., to check that enough network resources may be available to provide the desired QoS to the user. The ACPF 4506 may generate a unique Security Tag per traffic type (CP or UP), e.g., to assist with subsequent SDN based traffic labelling/routing enforcement. A Security Tag may be signed and bound to a WTRU (e.g., UE 4504), and may use the ACPF's private key for added security, e.g., to provide integrity/authenticity to the tags. CP and/or UP traffic may be transmitted using a secure communications channel such as IPsec connection, which may provide integrity and/or confidentiality, for example, when the connection spans more than one administration domain. The tag may be bound to contextual information to form an overall Authorization Context Information (ACI). Contextual information to which a tag may be bound may include, for example: (i) User/Device Identification (e.g., IMSI, IMEI, IP address, etc.) and/or (ii) End-to- end SFP (CP or UP) in the slice providing the service (e.g., ordered set of NFs in the NS).
[00264] The ACPF 2506 (in ND# 1 ) may detect from the NSMF 4514 information that a portion of the SFPs (e.g., CP-NF2, UP-NF3) may be under the control of another domain (e.g.,
ND#2). The ACPF 2506 may send an authorization request to the appropriate remote ACPF in ND#2. The request may include, for example, full ACI for cross domain consistency (e.g., same tag for traffic labeling, uniform user identification for charging (e.g., IMSI or WTRU source IP)). ACPF-ACPF communication across domains may be secured (e.g., using IP sec tunnels).
[00265] At 6, the ACPF in ND#2) may retrieve related network/slice information from an NSMF in ND#2 to validate the request from ACPF 2506 in ND#1 against network resource availability and in accordance with operator policies and QoS requirements. At 7, the ACPF in ND#2 may return an authorization response to the ND#1 ACPF 2506. At 8a and 8b, the ACPF in each domain may, when access is granted across domains, send traffic handling policy rules with associated ACI to its respective EF. Actions performed by the ACPFs may occur in parallel with each other. At 9a, the EF 4508 may program the policy rules into the SDN Controller in the form of classification and flow forwarding rules (e.g., <match, action> pairs), respectively (e.g., invoking appropriate NBI commands). The EF in ND#2 may perform the same action in its domain. At 10a, 10b, and 10c, the SDN Controller may push classification and flow forwarding rules to the Classifier and Switches (e.g., using OpenFlow commands).
[00266] At 11, in accordance with the example, the ACPF 2506 sends an authorization response to the AF 4502. A code describing a reason for the authorization decision may be provided, for example, when access is denied. A session starting event may be communicated to the CF, e.g., for charging purposes. A Security Tag may be used for correlation between the various functions (ACPF/EF/CF) and may enable charging granularity on an individual data flow basis. At 12, the AF 4502 may forward to the UE 4504 an authorization response (e.g., with PoA).
[00267] At 13, if access is granted the UE 4512 may generate CP related traffic (e.g., mobility tracking). The Classifier may (e.g., upon receiving a first CP packet of a flow) inspect the CP packet to detect the source User/Device, e.g., to try to match it with its classification rules. The classifier may (e.g., when a matching rule is found for an authorized packet) label an authorized packet with a corresponding CP Security Tag and may be forwarded to the next hop switch. The classifier may (e.g., when no match is found) drop the packet or forward it to a predetermined destination, e.g., for network forensics purposes.
[00268] A switch may receive a packet and try to match it against its flow rules. A switch may (e.g., when a matching rule is found for an authorized packet (e.g., a Security Tag in packet matches a flow entry)), forward an authorized packet to the next hop switch or NF according to the specified SFP. A switch may (e.g., when no match is found) drop the packet or forward it to a predetermined destination, e.g., for network forensics purposes. [00269] Examples of data the EF 4508 may collect in real-time from the SDN
Controller to be forwarded to the CF includes, without limitation: (i) initial packet events for session or time based charging; and (ii) per CP/UP flow data usage counters for volume based charging.
[00270] In another example, when access is granted, the UE 4504 may generate UP related traffic (e.g., application data). The Classifier may (e.g., upon receiving a first UP packet of a flow) inspect the UP packet to detect the source User/Device, e.g., to try to match it with its classification rules. A classifier may (e.g., when a matching rule is found for an authorized packet) label an authorized packet with a corresponding UP Security Tag and forward to the next hop switch. When no match is found, the classifier may drop the packet or forward it to a predetermined destination, e.g., for network forensics purposes.
[00271] A switch may receive a packet and may try to match it against its flow rules. A switch may (e.g., when a matching rule is found for an authorized packet (e.g., a Security Tag in packet matches a flow entry)), forward an authorized packet to the next hop switch or NF according to the specified SFP. A switch may (e.g., when no match is found) drop the packet or forward it to a predetermined destination, e.g., for network forensics purposes.
[00272] CP and/or UP traffic (e.g., when not already secured at the application layer) may be transported in secure tunnels that may be established through dedicated secure gateways on domain edges or through the NFs themselves (e.g., CP-NF1 <-> CP-NF2).
[00273] In some cases, upon session termination and/or based on operator policy), the AF 4502 may revoke authorization by canceling it via the ACPF 4506 through the EF 4508, which may clear the SFP authorization rules programming from the SDN Controller, which may, in turn, delete related classification/flow entries from the classifier/switches. In some examples, the AF 4502 may dynamically update authorization information for an active session through the ACPF 4506, which may ensure the update trickles down through Classifier/switches (e.g., add/remove an NF in the SFP).
[00274] The various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to affect the methods described herein. As used herein, the terms "apparatus," "network apparatus," "node," "entity", "function," "device," and "network node" may be used interchangeably, without limitation unless otherwise specified. [00275] With respect to the figures, various systems and networks are depicted in the figures. It will be appreciated that the example systems and networks are simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a system such as the systems illustrated in the figures, and all such embodiments are contemplated as within the scope of the present disclosure.
[00276] Processes and instrumentalities described herein may apply in any combination and may apply to other networks and wireless technologies. Although features and elements (including procedural steps) described herein in various examples may be shown or described in particular combinations and/or orders, each feature and element may be used alone or in any combination and in any order with and without other features and elements. Although examples provided herein may pertain to New Radio (NR) or 5G-specific protocols, subject matter described herein is not limited to provided examples or referenced communication technologies. Subject matter herein is applicable to a wider variety of examples and implementations, including in other wireless systems.
[00277] A WTRU or UE may refer to an identity of the physical device, or to the user's identity such as subscription related identities, e.g., MSISDN, SIP URI, etc. WTRU (UE) may refer to application-based identities, e.g., user names that may be used per application.
[00278] The processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as CD-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.

Claims

What is Claimed:
1. A method performed by an authorization node, the method comprising:
receiving a request from a device to use a service provided by at least one network slice; obtaining authorization decision information comprising at least one of: information related to a subscription, the service, or the at least one network slice; one or more operator policies; or information related to a device making the request; and
comparing the authorization decision information to the request;
based on the comparison between the authorization decision information and the request, generating authorization information; and
sending the authorization information to the device.
2. The method as recited in claim 1 , the wherein the authorization information comprises at least one of a proof of authorization or an indication of an authorization grant decision.
3. The method as recited in claim 2, wherein:
the proof of authorization or the indication of the authorization grant decision comprises an access token that indicates at least one of: 1) an authentication level that was achieved; 2) an identity proof of the device; 3) a security assurance level; 4) one or more authentication factors used; 5) an authorization role associated with the device; 6) an authorized access time period; 7) a service type that is authorized; 8) one or more service specific parameters; and 9) one or more payment parameters.
4. The method as recited in any one of the preceding claims, the method further comprising: performing a supplementary dynamic authorization based on the comparison between the authorization decision information and the request.
5. The method as recited in any one of the preceding claims, wherein the authorization decision information comprises one or more operator policies that are generated based on a risk associated with accessing the service.
6. The method as recited in any one of the preceding claims, wherein the one or more operator policies indicate that the device can access the one or more network slices if the device is authenticated and if the device belongs to a certain class of devices.
7. The method as recited in any one of the preceding claims, wherein the authorization decision information is obtained from a function hosted at a third party, or from an entity within a network controlled by a visited or home mobile network operator.
8. The method as recited in claim 7, wherein the authorization node is controlled by the third party, or by the visited or home mobile network operator.
9. The method as recited in any one of the preceding claims, wherein the request from the device is received via an access control device, and the authorization information is sent to the device via the access control device.
10. The method as recited in any one of the preceding claims, wherein the request comprises an identifier of the at least one network slice, a requested quality of service (QoS), or a requested security level.
1 1. An authorization node comprising a processor, a memory, and communication circuitry, the node being connected to a network via its communication circuitry, the node further comprising computer-executable instructions stored in the memory of the node which, when executed by the processor of the node, cause the node to perform operations comprising:
receiving a request from a device to use a service provided by at least one network slice; obtaining authorization decision information comprising at least one of: information related to a subscription, the service, or the at least one network slice; one or more operator policies; or information related to a device making the request; and
comparing the authorization decision information to the request;
based on the comparison between the authorization decision information and the request, generating authorization information; and
sending the authorization information to the device.
12. The node as recited in claim 11 , the wherein the authorization information comprises at least one of a proof of authorization or an indication of an authorization grant decision.
13. The node as recited in claim 12, wherein:
the proof of authorization or the indication of the authorization grant decision comprises an access token that indicates at least one of: 1) an authentication level that was achieved; 2) an identity proof of the device; 3) a security assurance level; 4) one or more authentication factors used; 5) an authorization role associated with the device; 6) an authorized access time period; 7) a service type that is authorized; 8) one or more service specific parameters; and 9) one or more payment parameters.
14. The node as recited in any one of claims 11 to 13, the node further comprising computer- executable instructions stored in the memory of the node which, when executed by the processor of the node, cause the node to perform further operations comprising:
performing a supplementary dynamic authorization based on the comparison between the authorization decision information and the request.
15. The node as recited in any of claims 11 to 14, wherein the authorization decision information comprises one or more operator policies that are generated based on a risk associated with accessing the service.
16. The node as recited in any one of claims 11 to 15, wherein the one or more operator policies indicate that the device can access the one or more network slices if the device is authenticated and if the device belongs to a certain class of devices.
17. The node as recited in any one of claims 11 to 16, wherein the authorization decision information is obtained from a function hosted at a third party, or from an entity within a network controlled by a visited or home mobile network operator.
18. The node as recited in claim 17, wherein the authorization node is controlled by the third party, or by the visited or home mobile network operator.
19. The node as recited in any one of claims 11 to 18, wherein the request from the device is received via an access control device, and the authorization information is sent to the authorization node via the access control device.
20. The node as recited in any one of claims 1 1 to 19, wherein the request comprises an identifier of the at least one network slice, a requested quality of service (QoS), or a requested security level.
PCT/US2017/042141 2016-07-15 2017-07-14 Adaptive authorization framework for communication networks WO2018013925A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662362895P 2016-07-15 2016-07-15
US62/362,895 2016-07-15
US201762451414P 2017-01-27 2017-01-27
US62/451,414 2017-01-27

Publications (1)

Publication Number Publication Date
WO2018013925A1 true WO2018013925A1 (en) 2018-01-18

Family

ID=59416815

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/042141 WO2018013925A1 (en) 2016-07-15 2017-07-14 Adaptive authorization framework for communication networks

Country Status (1)

Country Link
WO (1) WO2018013925A1 (en)

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109412790A (en) * 2018-10-26 2019-03-01 重庆邮电大学 A kind of user authentication of internet of things oriented and key agreement system and method
CN109714759A (en) * 2018-12-27 2019-05-03 浙江合众新能源汽车有限公司 A kind of safe automobile OTA method of servicing and service system
CN109995776A (en) * 2019-03-26 2019-07-09 西安纸贵互联网科技有限公司 A kind of internet data verification method and system
WO2019158819A1 (en) * 2018-02-15 2019-08-22 Nokia Technologies Oy Security management for roaming service authorization in communication systems with service-based architecture
WO2019158818A1 (en) 2018-02-15 2019-08-22 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture
WO2019197883A1 (en) * 2018-04-13 2019-10-17 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for performing multi-domain network slice selection and approval
WO2019220002A1 (en) * 2018-05-18 2019-11-21 Nokia Technologies Oy Authentication in public land mobile networks comprising tenant slices
WO2020030852A1 (en) * 2018-08-10 2020-02-13 Nokia Technologies Oy Network function authentication based on public key binding in access token in a communication system
WO2020058559A1 (en) * 2018-09-17 2020-03-26 Nokia Solutions And Networks Oy Credentials management
CN111382192A (en) * 2018-12-28 2020-07-07 北京神州泰岳软件股份有限公司 Data list display method and device and electronic equipment
WO2020151809A1 (en) * 2019-01-22 2020-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Security for distributed networking
WO2020174121A1 (en) * 2019-02-28 2020-09-03 Nokia Technologies Oy Inter-mobile network communication authorization
CN111903156A (en) * 2018-03-26 2020-11-06 凯迪迪爱通信技术有限公司 Terminal device, base station device, control method, and program for autonomous handover via terminal device
WO2020233205A1 (en) * 2019-05-22 2020-11-26 华为技术有限公司 Container service management method and device
WO2020257986A1 (en) 2019-06-24 2020-12-30 Nokia Shanghai Bell Co., Ltd. Dynamic allocation of network slice-specific credentials
WO2021004444A1 (en) * 2019-07-09 2021-01-14 华为技术有限公司 Communication method and network element
WO2021032912A1 (en) * 2019-08-21 2021-02-25 Nokia Technologies Oy Plmn based authorization service
EP3813322A4 (en) * 2018-11-05 2021-09-08 Huawei Technologies Co., Ltd. METHOD FOR AUTHORIZING NETWORK SLICES AND COMMUNICATION DEVICE
CN113647062A (en) * 2019-06-26 2021-11-12 甲骨文国际公司 Method, system, and computer-readable medium for producer network function (NF) service instance-wide egress rate limiting at a service communication proxy (SCP)
CN113994625A (en) * 2019-04-11 2022-01-28 株式会社Ntt都科摩 network node
WO2022021139A1 (en) * 2020-07-29 2022-02-03 Lenovo (Beijing) Limited Method and apparatus for subscribing and provisioning
US11354955B2 (en) 2017-05-15 2022-06-07 Amazon Technologies, Inc. Universal access control device
CN114760626A (en) * 2021-10-18 2022-07-15 西安电子科技大学 Self-adaptive combined authentication method for 5G large-scale terminal
US11438169B2 (en) * 2017-09-25 2022-09-06 Amazon Technologies, Inc. Time-bound secure access
US20220393939A1 (en) * 2019-11-07 2022-12-08 Nokia Solutions And Networks Oy Method and apparatus for provisioning of internet devices
US11589226B2 (en) 2019-12-17 2023-02-21 Cisco Technology, Inc. Multi-factor authentication for mobile security protocol
US11595444B2 (en) 2020-12-03 2023-02-28 International Business Machines Corporation Authenticity assessment of a requestor based on a communication request
CN117278329A (en) * 2023-11-21 2023-12-22 大连凌一科技发展有限公司 Application resource dynamic control access method based on zero trust gateway
EP4340297A1 (en) * 2022-09-16 2024-03-20 Nokia Technologies Oy Service function authorization
US12075347B2 (en) 2018-05-21 2024-08-27 Nokia Technologies Oy Managing VPLMN configuration updates in the UE due to home PLMN configuration changes

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100146596A1 (en) * 2007-04-27 2010-06-10 John Stenfelt Method And A Device For Improved Service Authorization
US20120054847A1 (en) * 2010-08-24 2012-03-01 Verizon Patent And Licensing, Inc. End point context and trust level determination
US20150222634A1 (en) * 2012-01-19 2015-08-06 Telefonaktiebolaget L M Ericsson (Publ) Handling of Authorization Requests For a Packet-Based Service in a Mobile Network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100146596A1 (en) * 2007-04-27 2010-06-10 John Stenfelt Method And A Device For Improved Service Authorization
US20120054847A1 (en) * 2010-08-24 2012-03-01 Verizon Patent And Licensing, Inc. End point context and trust level determination
US20150222634A1 (en) * 2012-01-19 2015-08-06 Telefonaktiebolaget L M Ericsson (Publ) Handling of Authorization Requests For a Packet-Based Service in a Mobile Network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NOKIA: "pCR to TR 33.899: Security aspects of Network Slicing", vol. SA WG3, no. San Jose del Cabo; 20160509 - 20160513, 8 May 2016 (2016-05-08), XP051099239, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/Docs/> [retrieved on 20160508] *

Cited By (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11354955B2 (en) 2017-05-15 2022-06-07 Amazon Technologies, Inc. Universal access control device
US11438169B2 (en) * 2017-09-25 2022-09-06 Amazon Technologies, Inc. Time-bound secure access
EP3752941A4 (en) * 2018-02-15 2021-10-27 Nokia Technologies Oy SECURITY MANAGEMENT FOR SERVICE AUTHORIZATION IN COMMUNICATION SYSTEMS WITH SERVICE-BASED ARCHITECTURE
WO2019158818A1 (en) 2018-02-15 2019-08-22 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture
WO2019158819A1 (en) * 2018-02-15 2019-08-22 Nokia Technologies Oy Security management for roaming service authorization in communication systems with service-based architecture
US10963553B2 (en) 2018-02-15 2021-03-30 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture
US10645583B2 (en) 2018-02-15 2020-05-05 Nokia Technologies Oy Security management for roaming service authorization in communication systems with service-based architecture
CN111903156A (en) * 2018-03-26 2020-11-06 凯迪迪爱通信技术有限公司 Terminal device, base station device, control method, and program for autonomous handover via terminal device
WO2019197883A1 (en) * 2018-04-13 2019-10-17 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for performing multi-domain network slice selection and approval
US11419046B2 (en) 2018-04-13 2022-08-16 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for performing multi-domain network slice selection and approval
WO2019220002A1 (en) * 2018-05-18 2019-11-21 Nokia Technologies Oy Authentication in public land mobile networks comprising tenant slices
US11564193B2 (en) 2018-05-18 2023-01-24 Nokia Technologies Oy Authentication in public land mobile networks comprising tenant slices
US12075347B2 (en) 2018-05-21 2024-08-27 Nokia Technologies Oy Managing VPLMN configuration updates in the UE due to home PLMN configuration changes
US12184790B2 (en) * 2018-08-10 2024-12-31 Nokia Technologies Oy Network function authentication based on public key binding in access token in a communication system
US20210234706A1 (en) * 2018-08-10 2021-07-29 Nokia Technologies Oy Network function authentication based on public key binding in access token in a communication system
WO2020030852A1 (en) * 2018-08-10 2020-02-13 Nokia Technologies Oy Network function authentication based on public key binding in access token in a communication system
WO2020058559A1 (en) * 2018-09-17 2020-03-26 Nokia Solutions And Networks Oy Credentials management
CN109412790A (en) * 2018-10-26 2019-03-01 重庆邮电大学 A kind of user authentication of internet of things oriented and key agreement system and method
CN109412790B (en) * 2018-10-26 2021-11-16 重庆邮电大学 User authentication and key agreement system and method facing to Internet of things
EP3813322A4 (en) * 2018-11-05 2021-09-08 Huawei Technologies Co., Ltd. METHOD FOR AUTHORIZING NETWORK SLICES AND COMMUNICATION DEVICE
CN109714759A (en) * 2018-12-27 2019-05-03 浙江合众新能源汽车有限公司 A kind of safe automobile OTA method of servicing and service system
CN111382192B (en) * 2018-12-28 2023-11-03 北京神州泰岳软件股份有限公司 Data list display method and device and electronic equipment
CN111382192A (en) * 2018-12-28 2020-07-07 北京神州泰岳软件股份有限公司 Data list display method and device and electronic equipment
WO2020151809A1 (en) * 2019-01-22 2020-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Security for distributed networking
US11831622B2 (en) 2019-01-22 2023-11-28 Telefonaktiebolaget Lm Ericsson (Publ) Security for distributed networking
WO2020174121A1 (en) * 2019-02-28 2020-09-03 Nokia Technologies Oy Inter-mobile network communication authorization
CN109995776A (en) * 2019-03-26 2019-07-09 西安纸贵互联网科技有限公司 A kind of internet data verification method and system
CN113994625A (en) * 2019-04-11 2022-01-28 株式会社Ntt都科摩 network node
WO2020233205A1 (en) * 2019-05-22 2020-11-26 华为技术有限公司 Container service management method and device
CN114097261A (en) * 2019-06-24 2022-02-25 上海诺基亚贝尔股份有限公司 Dynamic distribution of network slice specific credentials
CN114097261B (en) * 2019-06-24 2024-07-05 上海诺基亚贝尔股份有限公司 Dynamic allocation of network slice specific credentials
EP3987834A4 (en) * 2019-06-24 2023-04-05 Nokia Technologies OY Dynamic allocation of network slice-specific credentials
US12132732B2 (en) 2019-06-24 2024-10-29 Nokia Technologies Oy Dynamic allocation of network slice-specific credentials
WO2020257986A1 (en) 2019-06-24 2020-12-30 Nokia Shanghai Bell Co., Ltd. Dynamic allocation of network slice-specific credentials
CN113647062A (en) * 2019-06-26 2021-11-12 甲骨文国际公司 Method, system, and computer-readable medium for producer network function (NF) service instance-wide egress rate limiting at a service communication proxy (SCP)
WO2021004444A1 (en) * 2019-07-09 2021-01-14 华为技术有限公司 Communication method and network element
WO2021032912A1 (en) * 2019-08-21 2021-02-25 Nokia Technologies Oy Plmn based authorization service
US20220393939A1 (en) * 2019-11-07 2022-12-08 Nokia Solutions And Networks Oy Method and apparatus for provisioning of internet devices
US11589226B2 (en) 2019-12-17 2023-02-21 Cisco Technology, Inc. Multi-factor authentication for mobile security protocol
WO2022021139A1 (en) * 2020-07-29 2022-02-03 Lenovo (Beijing) Limited Method and apparatus for subscribing and provisioning
US11595444B2 (en) 2020-12-03 2023-02-28 International Business Machines Corporation Authenticity assessment of a requestor based on a communication request
CN114760626B (en) * 2021-10-18 2024-04-02 西安电子科技大学 An adaptive combined authentication method for 5G large-scale terminals
CN114760626A (en) * 2021-10-18 2022-07-15 西安电子科技大学 Self-adaptive combined authentication method for 5G large-scale terminal
EP4340297A1 (en) * 2022-09-16 2024-03-20 Nokia Technologies Oy Service function authorization
CN117278329A (en) * 2023-11-21 2023-12-22 大连凌一科技发展有限公司 Application resource dynamic control access method based on zero trust gateway
CN117278329B (en) * 2023-11-21 2024-01-16 大连凌一科技发展有限公司 Application resource dynamic control access method based on zero trust gateway

Similar Documents

Publication Publication Date Title
WO2018013925A1 (en) Adaptive authorization framework for communication networks
CN114080843B (en) Apparatus, system, and method for enhancing network slice and policy framework of 5G networks
US20230092015A1 (en) Securing communication of devices in the internet of things
US20220385445A1 (en) EMBEDDED UNIVERSAL INTEGRATED CIRCUIT CARD (eUICC) PROFILE CONTENT MANAGEMENT
KR102588974B1 (en) Methods and systems for privacy protection of 5g slice identifier
US10992472B2 (en) Systems and methods for secure roll-over of device ownership
JP6174617B2 (en) Certificate validation and channel binding
CN107534658B (en) End-to-end authentication at the service layer using public key mechanisms
CN107005569B (en) End-to-end service layer authentication
WO2017200978A1 (en) Security-based slice selection and assignment
US20180014192A1 (en) Machine-To-Machine Gateway Architecture
JP5586779B2 (en) Policy management methods
US8627064B2 (en) Flexible system and method to manage digital certificates in a wireless network
US20210377054A1 (en) Systems and methods for managing public key infrastructure certificates for components of a network
US11855977B2 (en) Systems and methods for configuring a network function proxy for secure communication
EP4527095A1 (en) Security for distributed non-access stratum protocol in a mobile system
Singh et al. Unified heterogeneous networking design
US20250023740A1 (en) Multi Access Security Handling
WO2025014775A9 (en) Systems, methods, and apparatus for nef-based pdc creation
WO2025014771A1 (en) Systems, methods, and apparatus for wireless transmit/receive unit based pdc creation
WO2025014778A1 (en) Systems, methods, and apparatus for pdc security
WO2025014781A1 (en) Apparatus and method for user plane function (upf) based pdu set handling data channel (pdc) operation

Legal Events

Date Code Title Description
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17745580

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17745580

Country of ref document: EP

Kind code of ref document: A1