WO2017200978A1 - Sélection et attribution de tranches à base de sécurité - Google Patents

Sélection et attribution de tranches à base de sécurité Download PDF

Info

Publication number
WO2017200978A1
WO2017200978A1 PCT/US2017/032804 US2017032804W WO2017200978A1 WO 2017200978 A1 WO2017200978 A1 WO 2017200978A1 US 2017032804 W US2017032804 W US 2017032804W WO 2017200978 A1 WO2017200978 A1 WO 2017200978A1
Authority
WO
WIPO (PCT)
Prior art keywords
sdd
wtru
network
slice
service
Prior art date
Application number
PCT/US2017/032804
Other languages
English (en)
Inventor
Alec Brusilovsky
Samir Ferdi
Ayman ABDELHAMID
Vinod Kumar Choyi
Yogendra C. Shah
Eldad M. Zeira
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 WO2017200978A1 publication Critical patent/WO2017200978A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Definitions

  • a diverse range of services and/or associated network service requirements may be provided in 5G networks.
  • Network Slicing may enable sub-networks (e.g., network slices) to support the diverse services and requirements.
  • a network slice may be isolated from other (e.g., all other) network slices.
  • Virtualization and/or Network Function Virtualization may enable a network slice (NS) to offer granular control of performance, for example, based on the application and/or services being delivered.
  • a WTRU may transmit to a serving network (SN) a request for an attachment to a slice with a service description document (SDD).
  • SN serving network
  • SDD service description document
  • the SN may perform an authorization check, based on the request.
  • the SN may determine whether the WTRU has provided a requested SDD (SDDR).
  • SDDR requested SDD
  • the SN may obtain an SDD identity (SDDId) of an authorized SDD based on subscription associated with that subscriber (e.g. user or users or WTRU).
  • An associated SDD may be received, based on the SDDId.
  • the SDD may be assigned to the WTRU.
  • a network device may receive, from a WTRU, a message.
  • the message may be a service request message, or an attach request message.
  • the service request message may be piggybacked with the attach request message.
  • the message may include a first requested SDD.
  • the first requested SDD may be a network slice selection assistance information (NSSAI) message.
  • NSSAI message may include a collection of various single NSSAI (S-NSSAI) messages.
  • a S-NSSAI message may include a slice/service type (SST) and/or a slice/service type (SST) and/or a slice/service type (SST) and/or a slice/service type (SST) and/or a slice/service type (SST) and/or a slice/service type (SST) and/or a slice/service type (SST) and/or a slice/service type (SST) and/or a slice/service type (SST) and/or a slice/service type (SST) and/
  • the network device may receive the first requested SDD via the RRC and/or NAS layers.
  • the first requested SDD may be associated with an application.
  • the first requested SDD may indicate one or more service flow requirements.
  • a service flow requirement may indicate a Quality of Service (QoS) requirement characteristic and/or a security characteristic.
  • QoS requirement characteristic and/or the security characteristic may be associated with the application.
  • the network device may determine an offered SDD.
  • the network device may send the offered SDD to the WTRU.
  • the offered SDD may satisfy the service flow requirement.
  • the offered SDD may be associated with a network slice.
  • the network device may determine that the offered SDD is a match for the first requested SDD.
  • the network device may assign a network slice to the WTRU, for example, based on the one or more service flow requirements. For example, the network device may assign the network slice to the WTRU based on the offered SDD being a match for the first requested SDD.
  • the network device may determine that the offered SDD is a match for the first requested SDD when the offered SDD is tailored for the application.
  • the network device may send, to the WTRU, a response message that indicates the assigned network slice.
  • the network device may determine that the offered SDD is not a match for the first requested SDD, for example, when the offered SDD is not tailored for the application.
  • the network device may send, to the WTRU, a catalog of services and/or slices available in the SN.
  • the catalog may include services and/or slices provided by the SN itself and/or any 3 rd Party Service and/or Slice provider, for example, that are approved by the SN.
  • the network device may receive, from the WTRU, a second requested SDD.
  • the second requested SDD may indicate a second service flow requirement.
  • the second service flow requirement may be part of the offered SDD.
  • the network slice may be assigned based on the second requested SDD.
  • the QoS requirement characteristic may be indicated by a QoS class identifier (QCI) value.
  • the QoS requirement characteristic may indicate one or more of a minimum GBR, a data rate, a latency, a delay, a packet loss error rate, a re-transmission threshold, a RLC mode, a call setup time, a connection density, a traffic density, or a handoff success rate.
  • the first and/or second requested SDD may indicate respective QoS requirement characteristics for one or more of a control plane, a user plane, and/or a management plane.
  • the first and/or second requested SDD may indicate respective QoS requirement characteristics for uplink and/or downlink communications.
  • the first and/or second requested SDD may indicate security characteristics for one or more of a security level, a data integrity requirement, a data confidentiality requirement, a privacy requirement, an algorithm complexity requirement, a key length requirement, or an authorization type.
  • 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. 1 A.
  • 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. 1 A.
  • FIG ID is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1 A.
  • FIG. IE is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.
  • FIG. 2 depicts example Business Models in 5G Networks.
  • FIG. 3 depicts example Three Dimensions of Innovation in 5G Networks.
  • FIG. 4 depicts an example Network Slicing Conceptual Outline.
  • FIG. 5 depicts example Network Function Virtualization (NFV) Layers.
  • NFV Network Function Virtualization
  • FIG. 6 depicts an example NFV Management and Orchestration (NFV-MANO)
  • FIG. 7 depicts an example overview of a Software Defined Networking (SDN) Layering Concept.
  • SDN Software Defined Networking
  • FIG. 8 depicts an example Schematic Diagram of Slice Composition in different 5G Use Cases.
  • FIG. 9 depicts an example 3GPP Architecture for Service Capability Exposure.
  • FIG. 10 depicts example Network Service Header Contents.
  • FIG. 11 depicts an example table of Quality of Service (QoS) Class Identifiers (QCIs) and Associated Key Performance Indicators (KPIs).
  • QoS Quality of Service
  • QCIs Class Identifiers
  • KPIs Key Performance Indicators
  • FIG. 12 depicts
  • FIG. 13 depicts
  • FIG. 14 depicts
  • FIG. 15 depicts an example Flow-chart Illustrating a Slice Selection Process.
  • FIG. 16 depicts an example Call flow depicting slice selection based on subscriber profile.
  • FIG. 17 depicts an example Slice Negotiation, Selection and Attachment based on WTRU Request.
  • FIG. 18 depicts an example slice assignment based on Application Service Provider (ASP) driven service requirements.
  • ASP Application Service Provider
  • FIG. 19 depicts an example Architecture for Network Exposure with Slice Selection.
  • FIG. 20 depicts an example Determining Static and Dynamic Service Function Paths (SFPs).
  • FIG. 21 depicts an example Dynamic Service Function Chain (SFC) Determination.
  • FIG. 22 depicts an example Routing based on information within packet.
  • FIG. 1 A is a diagram of an example communications system 100 in which one or more disclosed embodiments 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 systems 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) 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.
  • 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
  • smartphone a laptop
  • netbook a personal computer
  • a wireless sensor consumer electronics, and the like.
  • the communications systems 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, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MTMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MTMO 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, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • 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).
  • UMTS Universal Mobile Telecommunications System
  • UTRA Universal Mobile Telecommunications System
  • WCDMA wideband CDMA
  • 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).
  • HSPA 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
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for
  • WiMAX Microwave Access
  • CDMA2000 Code Division Multiple Access
  • CDMA2000 IX Code Division Multiple Access
  • CDMA2000 EV-DO Interim Standard 2000
  • IS-2000 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGE
  • the base station 114b in FIG. 1 A 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, 102c, 102d.
  • 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.
  • VoIP voice over internet protocol
  • 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
  • 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, i.e., 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), 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 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 microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,
  • DSP digital signal processor
  • 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
  • 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 115/116/117.
  • a base station e.g., the base station 114a
  • 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 one embodiment, 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 (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.
  • 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 method 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.
  • 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.
  • the RAN 103 may also be in communication with the core network 106.
  • 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 lur 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. In one
  • 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 and/or downlink, 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 SI 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 PDN gateway 166 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.
  • 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 authentication,
  • 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 (MTP-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
  • any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • the MTP-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.
  • the 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.
  • a 5G mobile network may support one or more of the following network functions.
  • An Access and Mobility Management Function may handle registration, connection, and/or mobility management of Next Generation UE (NG-UE).
  • the traditional MME function in EPS may be split between a Security Anchor Function (SEAF) and an Authentication Server Function (AUSF).
  • SEAF may authenticate a NG-UE while interacting with an AMF.
  • the SEAF may or may not be co-located with the AMF.
  • the AUSF may interact with a Unified Data Management (UDM).
  • the AUSF may include an Authentication, Authorization, and Accounting (AAA) server.
  • the UDM may be the equivalent of a home subscriber server (HSS) in EPS.
  • HSS home subscriber server
  • the Session Management Function may be in charge of packet data unit (PDU) session management, which may be shared between the MME and the Control Plane of the Secure Gateway/Packet Gateway (SGW/PGW) in EPS.
  • a User Plane Function may include the RAN anchor point for user data in the 5G Core.
  • the UPF may be an external PDU session point of interconnect to a Data Network.
  • the functionality of the UPF may be shared between the User Plane of the SGW and the PGW, e.g., in EPS.
  • a Policy Control Function PCF
  • Separation of Control Plane and User Plane (SMF, UPF) and/or separation of mobility and session management (AMF, SMF) functions may be design features in the evolution from the EPS architecture.
  • Examples of the use cases that are driving the 5G system architecture may 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
  • 5G may continue to up the ante on the data rate.
  • 5G may make uplink data throughput as high as, or in excess of, downlink.
  • the focus of 5G may be on coverage and user experience.
  • the interest in 5G technologies may be simmering, and the industry may be funding projects looking into such technologies.
  • HEW High Efficiency Wireless
  • 5G may consist of multiple interconnected communication standards, ranging from wireless metropolitan area networks down to wireless personal area networks, and wired networks, providing the required throughput and connectivity.
  • a driver of the connectivity concept may be the pervasive presence of a variety of things or objects, such as RFID tags, sensors, actuators, and/or mobile phones in the environment around us. These things or objects may more popularly be known as the Internet of Things (IoT). Most of these objects or devices may interact with each other in a variety of ways and may generate huge amounts of data.
  • IoT Internet of Things
  • a challenge to 5G systems from the convergence of the IoT and the Internet world as we know it may be the multitude and/or variety of service scenarios, many of which may not even have been dreamt of yet.
  • the IoT for 5G systems may require loosely defined smart objects (e.g.
  • M2M / IoT devices to connect, and/or may enable them to interact with other objects to yield productivity and automation gains through predictive, actionable intelligence.
  • mobile devices may adopt silent mode when entering a meeting room if this is the request of the meeting moderator indicated in the policy, may alert the user and to turn off the radio on his/her mobile phone before entering sensitive medical areas, and/or may detect when the user enters his/her car and automatically to connect to its sound system.
  • Wireless sensors may let people check where their pet is in real-time, as well as control the temperature for each room of their house while they are out.
  • Emergency services may be remotely and automatically alerted if fire is detected in a building or if a patient's medical parameters shift beyond a critical threshold.
  • An additional new driver in 5G may be the need for increased service reliability for mission critical communications services, such as intelligent transportation systems. These use cases may drive towards new requirements for resiliency and reliability.
  • 5G networks may be designed to connect industries (e.g., manufacturing and processing, intelligent transportation, smart grids, and/or e-health). Such environments may bring the challenge of speed, latency, and/or heterogeneity. Platforms (e.g., different platforms) interacting may mean different protocols, different interfaces, and different policies (e.g., QoS requirements). The diverse service contexts may introduce security and privacy considerations. For example, an e-health information system may require more privacy than a Home Automation System (HAS), which may need more security for Control Plane (CP) signaling.
  • HAS Home Automation System
  • CP Control Plane
  • Radio Network equipment that supports higher frequencies (e.g., Millimeter waves: 30GHz+), core networks that can store, forward, and/or process the data may be designed and deployed, thus creating a great increase in the CAPEX as well as associated OPEX that may be expended by mobile network service providers.
  • An MNO may be an Asset Provider, Connectivity Provider, and/or Partner service provider, as shown in the FIG. 2.
  • An Asset Provider may be the one who may own a certain function of the network (partially/fully sharing the RAN and/or the core network).
  • a connectivity provider may be an MNO who may not own any infrastructure, but provides a Network (e.g., IP) connectivity that may be offered to a consumer/business or to a wholesale/Mobile Virtual Network Operator (MVNO).
  • a partner service provider may benefit from the service features offered by a 3 rd party operator who may own mobile connectivity capabilities. For example, the customers of smart wearable devices with services of a remote health monitoring company.
  • An Asset Owner may be a model where the service provider (SP) may own the infrastructure partially or in full.
  • SP may own the core network while sharing the RAN network with other SPs.
  • a cloud based scenario may be a scenario where an SP may share infrastructure with other SPs.
  • This may introduce business models (e.g., new business models) in 5G networks with implementations ranging from dedicated H/W through to cloud-based services, including Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and/or Software-as-a-Service (SaaS).
  • IaaS Infrastructure-as-a-Service
  • PaaS Platform-as-a-Service
  • SaaS Software-as-a-Service
  • the connectivity provider may be an example of the cloud based ownership model where the SP may not own any infrastructure and the SP may function as a connectivity broker for end SPs.
  • Realizing the features of 5G networks may require consideration along three different dimensions: use-cases, service requirements and different business models, as shown in FIG. 3. These dimensions (e.g., each of these dimensions) may vary in such a way as to realize a variety of the 5G network features.
  • the user requirements along with the 5G network features may form different use cases, as shown in FIG 3.
  • the elasticity of the business models in 5G networks may provide an aspect (e.g., a third aspect) that may be considered when designing the 5G network.
  • Flexibility and Scalability may mean that the key connection attributes (e.g. mobility, security, privacy, reliability, latency, etc.) may be enabled, disabled, modified, and/or controlled in a programmable and/or switchable manner.
  • the key connection attributes may be enabled, disabled, modified, and/or controlled in a programmable and/or switchable manner depending on use-cases, subscription details, and/or associated policies defined by operators.
  • Context- awareness may allow for customization and/or creation of the application to match the preferences of the individual user.
  • context awareness may allow for customization and/or creation of the application to match the preferences of the individual user based on current context (e.g., location, time, activities, and services).
  • 5G may include Fixed-Mobile Convergence.
  • 5G may support fixed and/or mobile convergence to ensure a seamless customer experience within the fixed and mobile domains (e.g., a unified user authentication, RAN, and/or CN independence).
  • the main features that are envisioned for 5G networks may include Energy and Cost efficiency, Operations awareness and efficiency, and/or Availability and Reliability (e.g., Resilience Networks).
  • the main features that are envisioned for 5G networks may include Enhanced Network Security.
  • the security protocols may be improved to adapt to newly introduced use- cases (e.g., Massive Machine Type Communications (mMTC)), and may comply with security requirements defined in 3 GPP standards.
  • the main features that are envisioned for 5G networks may include Enhanced user security and privacy.
  • the introduction of business models (e.g., new business models) in 5G may make the user vulnerable (e.g., more vulnerable) to security and/or privacy breaches.
  • the introduction of business models in 5G may make the user vulnerable to security and/or privacy breaches due to different levels of trust and/or security required in each model.
  • Protecting user privacy according to different contexts and/or applications may be a cornerstone of 5G security.
  • Network Slicing may be used to offer granular control (e.g., more granular control) of performance and/or network features based on the application and/or services being used, e.g., due to the diversity of applications and associated network service requirements (e.g. QoS, speed, latency, security) for an (e.g., each) application.
  • Network Slicing may include architectures and procedures configured to provide relatively isolated sub-networks, each optimized for specific types of traffic characteristics.
  • Each network slice may have a set (e.g., its own set) of security and QoS requirements and slices (e.g., all slices) may be isolated (e.g., potentially completely isolated) from each other.
  • network functionalities e.g., some or all of the network functionalities
  • NFV Network Function Virtualization
  • 5G networks may introduce new architectures and/or technologies in the communications industry and virtualization and NFV are enablers for NSs.
  • Network Slicing may be used to support different use cases across business models (e.g., different business models), which may drive the need for enhanced network capabilities (different HAV components for different use cases and business models). This may increase the capital expenditure (CAPEX) and the operating expenditure (OPEX) dramatically in 5G networks.
  • Use of network slicing may be used to effectively provision a wide spectrum of use- cases in 5G.
  • a Slice may be associated with a set of features that may achieve the requirements of a certain use-case taking into consideration the capabilities of the operator(s) who may provide this service.
  • a slice may be realized by taking into account the current 3GPP standard procedures and protocols.
  • 5G networks may support dedicated vertical use cases, such as intelligent transportation, gaming, remote machinery, and/or virtual reality that may have different service requirements.
  • Virtual slices of one or more networks that may support the requirement may be designed, e.g., in order to be able to support such differentiated application and services.
  • Such virtual Slices may be logical instantiations of the network resources (e.g., required network resources).
  • operators/service providers may be able to support such a slicing.
  • a description of network slicing is shown in FIG. 4 according to next generation mobile networks (NGMN) 5G requirements and
  • a network operator may use a Network Slice Blueprint to create a Network Slice Instance.
  • a Network Slice Instance may provide the network characteristics (e.g., layers (e.g., all layers) from the Radio Access layer up to the service layer) which may be used (e.g., required) by a Service Instance.
  • a Network Slice Instance may be shared across multiple Service Instances provided by the network operator.
  • Network Function Virtualization may be utilized to support network slicing.
  • NFV technology may be a way (e.g., a new way) to build an end-to-end network infrastructure with evolving standard IT virtualization technology to enable the consolidation of heterogeneous network devices onto standard high-volume servers, switches, and/or storage.
  • the virtual network functionality of a network device may be implemented as a software package.
  • a Virtual Network Function (VNF) may run on one Virtual Machine (VM) as a VNF Instance (VNFI) or more than one VM as a VNF Component Instance (VNFCI).
  • VM Virtual Machine
  • VNFI VNF Instance
  • VNFCI VNF Component Instance
  • the OPEX and CAPEX may be reduced, e.g., because the 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
  • FPGA hardware acceleration and/or programmability
  • Companies e.g., Intel
  • FPGA field-programmable gate arrays
  • a key feature may include Virtual infrastructure (NFVI), into which virtual machines may be created on generic high-volume hardware servers and/or storage devices, connected by generic high-volume network switches and organized by the orchestration (e.g., Hypervisor).
  • NFVI Virtual infrastructure
  • a feature of NFV may include Separation of the software that defines the network functions for network devices from generic hardware.
  • a key feature may include Management and Orchestration (MANO), which may automate installation and/or management of the virtualized network functions on the generic hardware.
  • MANO Management and Orchestration
  • Benefits of NFV technology may include carriers being able to build and/or operate a flexible and/or highly configurable network with reduced equipment costs and/or reduced power consumption. Carriers may be able to build and/or operate a flexible and/or highly configurable network with reduced equipment costs and/or reduced power consumption because consolidating equipment and/or exploiting the economies of scale of the information technology (IT).
  • IT information technology
  • the role of the Management and Orchestration (MANO) within NFV may be to manage the NFV Infrastructure (NFVI) and to perform resource allocations that may be used (e.g., needed) by the various network services and VNFs.
  • the MANO may be involved in the management and/or orchestration of Network Functions Virtualization Infrastructure.
  • the components that may be managed may be virtualized or partially-virtualized resources, such as: (a) Computing infrastructure, that may include computing machines and virtual machines having CPU and/or memory; (b) Storage, that may include Non-volatile secure storage; and (c)
  • the MANO may be involved in the management and/or orchestration of Virtualized Network Functions, that may involve the management and/or orchestration of VNFs pertaining to fault, configuration, accounting, provisioning, and/or security (FCAPS). The ability to instantiate, scale, upgrade, and/or terminate VNFs.
  • the MANO may be involved in the management and/or orchestration of Network Services, that may involve managing the lifecycle of network services (e.g., instantiation of services, scaling (elasticity), termination of services, etc.).
  • the MANO may be involved in the management and/or orchestration of Miscellaneous, that may include Policy management, interactions with legacy or new Operations Support Systems/Business Support Systems (OSS/BSS), etc.
  • OSS/BSS Operations Support Systems/Business Support Systems
  • the NFV Architectural Framework may include one or more functional blocks.
  • the functional blocks may include NFV Orchestrator (NFVO), VNF Manager (VNFM), and/or Virtualized Infrastructure Manager (VIM), as shown in FIG. 6.
  • the NFVO may perform orchestration functions of NFVI resources across VIMs (e.g., multiple VIMs) and/or lifecycle management of network services.
  • the VNFM may perform orchestration and/or management functions of VNFs.
  • the VFM may perform orchestration and/or management functions of NFVI resources within a domain.
  • the NFVO may interact with the OSS/BSS, possibly legacy system, for provisioning, configuration, capacity management, and/or policy-based management.
  • the VNFM may interact with the Element Manager (EM) and the VNF for provisioning,
  • EM Element Manager
  • the VIM may interact with the NFVI for the management and/or orchestration of virtualized resources.
  • the term NF, VNF, and/or PNF may be used to refer to a network function.
  • SDN Software Defined Networking
  • NFV Network-to-Network Interface
  • SDN may be a complementary technology to NFV.
  • SDN may enable realization of the control plane user plane and/or management plane for NFV.
  • SDN may be a solution for enabling network function virtualization and/or network
  • the SDN network architecture may consist of a centralized network controller in the control plane, which may be responsible for allocating traffic to network elements in the separated data plane of the network, as described in FIG. 7.
  • the network controller may maintain (e.g., centrally maintain) the intelligence and/or state of the network (e.g., the entire network).
  • the network controller may output control rules (e.g., the best fine granular flow routing control rules) to the heterogeneous network devices from vendors (e.g., different vendors).
  • the network controller may provide a global united view and/or resources of the network to the upper layer network applications as a single, logical switch.
  • the network controller may provide a global united view and/or resources of the network to the upper layer network applications as a single, logical switch through the northbound interface.
  • Novel network applications may be created, tested, and/or deployed (e.g., may easily be created, tested, and/or deployed).
  • novel network applications may be created, tested, and/or deployed in a short time.
  • SDN protocols may enable control-plane management and may be separated from the data/user plane.
  • Open flow is defined by the Open Networking Foundation (ONF) and may be accepted (e.g., broadly accepted) as SDN protocol (e.g., dominating SDN protocol) in the southbound interface between the network controller and network devices. Open flow may be supported by device manufacturers, service providers, and/or operators. For CES and/or PCE, defined by the Internet Engineering Task Force (IETF), may be southbound SDN protocols (e.g., alternative southbound SDN protocols). SDN protocols for the northbound interface may currently be under development.
  • ONF Open Networking Foundation
  • IETF Internet Engineering Task Force
  • SDN protocols for the northbound interface may currently be under development.
  • Three use cases (e.g., main uses cases) driving 5G networks may be expanded into a range of QoS Class Identifiers (QCI), which may provide service selectively (e.g., fine grained service selectivity).
  • QCI QoS Class Identifiers
  • the eMBB category may be sub-divided into ultra-high speed, high speed, high mobility, and/or low cost, where each of these specific categories may be serviced by slice specifications (e.g., different slice specifications), as shown in FIG. 8.
  • Slicing may include architectures and procedures configured to provide isolated subnetworks.
  • the sub-networks e.g., each of the sub-networks
  • the sub-networks may be optimized for types (e.g., specific types) of traffic characteristics.
  • a slice may be formed based on the set of requirements needed to provision a certain session (e.g., use-case).
  • a slice may map to service characteristics (e.g., a set of service characteristics, such as latency, throughput, etc.) that may be provisioned in the slice.
  • service characteristics e.g., a set of service characteristics, such as latency, throughput, etc.
  • QCIs may be used (e.g., commonly used) to set up data bearers (e.g., different data bearers) that may be assigned to sessions (e.g., different sessions) of a WTRU.
  • QCI-4 may describe requirements (e.g., a set of requirements) that may be needed to set up a Video Streaming session.
  • the notion of QCI may be extended to support a slice definition. For example, with an expansion of the services to be covered in 5G networks, as well as the flexibility of such networks, it may be natural to extend the notion of QCI to support a slice definition
  • 3 GPP may define a Service Capability Exposure Function (SCEF) as an enabler for a server side API for 3rd party applications.
  • SCEF Service Capability Exposure Function
  • the SCEF may enable business opportunities (e.g., new business opportunities) through network optimized services from OTT and/or Vertical industries.
  • FIG. 9 shows the a (e.g., the current) 3GPP architecture.
  • a slice e.g., each individual slice
  • a use case e.g., a particular use case
  • SFC Service Function Chaining
  • IETF may define SFC as "an ordered set of abstract service functions and ordering constraints that may be applied to packets and/or frames and/or flows selected as a result of classification."
  • An example of an abstract service function may be "a firewall.”
  • an SFC may be an abstracted view of a service that may specify the set of required SFs, as well as the order in which they are executed.
  • a logical path may be created that may ensure that a packet is treated at a function (e.g., each of the functions) as specified by the SFC.
  • the Network Service Header may be an enabler to dynamic SFC deployment.
  • An NSH may be used to define a data plane protocol specifically for the creation of dynamic service chains.
  • NSH may address the limitations of static SFCs that was mentioned herein, including topology dependency, monitoring and troubleshooting a SFC, classification and reclassification realization in SDN Open Flow switches and transport layer protocols dependency (NSH is transport agnostic).
  • the NSH header may include service path information and/or metadata that may be added to a packet and/or frame and/or used to create a service plane, as shown in FIG. 10.
  • the packets (e.g., original packets) preceded by NSH may be encapsulated in an outer header for transport.
  • a part (e.g., the main part) in the NSH may be the Service Path Header.
  • the Service Path Header may constitute the Service Path Identifier (SPI) and/or the Service Index (SI).
  • SPI may identify a service path (e.g., a certain service path).
  • SI may provide a location within the SFP.
  • Service index may be decremented, e.g., by service functions and/or proxy nodes, after performing services (e.g., required services) and/or the SI value (e.g., the new decremented SI value) may be reflected in the egress NSH packet.
  • a WTRU attaches (e.g., initially attaches) to a network
  • the WTRU may attach (e.g., attempt to attach) to a slice (e.g., a particular default slice) from which the WTRU may request services that may be supported by the slice.
  • the serving network may communicate with the WTRU to ascertain the type(s) of service and to then provide the services through a particular slice(s), e.g., in order for the serving network to deliver such services.
  • Such awareness may be achievable (e.g., easy to achieve) by pre-provisioning slices used (e.g., required) by the WTRU Subscriber Profile (e.g., provisioning a list of supported slices in the ME or UICC).
  • the serving network may not be pre-provisioned.
  • the Home Network may not control and/or predict which foreign network the WTRU may attempt to attach.
  • Slices realized in the Home Network may be different from slices realized in the Serving Network and/or slices realized in the Home Network may not exist.
  • the exposure may be used (e.g., required) at the WTRU level and/or at the network level to shared network service providers and/or OTT service providers.
  • the exposure may be used (e.g., required) for alignment of services between difference network service providers.
  • the communications over the air and/or inside the network may be protected with integrity and/or confidentiality protection for services.
  • a vertical health care application e.g., remote patient monitoring
  • a slice with the highest security/QoS attributes may be selected to provide the health-care data and communications with integrity and/or confidentiality and/or privacy.
  • the health-care application may be used by a medical professional attending to a patient in a moving ambulance.
  • the application When the application is started by the medical professional, based upon the application within the WTRU using (e.g., requiring) a connectivity service that may satisfy the desire (e.g., need) to "provide a secure and reliable communication channel" in order to report biological data (e.g., frequently and/or reliably small amounts of biological data, such as blood pressure, heart rate, glucose level from a moving ambulance (0-120 km/h)), to an application server.
  • biological data e.g., frequently and/or reliably small amounts of biological data, such as blood pressure, heart rate, glucose level from a moving ambulance (0-120 km/h)
  • the application server may protect private patient data and may satisfy (e.g., at the same time satisfy) the time criticality aspect of the communications.
  • a driver for flexible security in 5G networks may be the need to support a diverse set of devices from smartphones, smart appliances, smart meters, and/or small footprint, battery powered devices.
  • the resources (e.g., limited resources) of such devices e.g., low power consumption, low memory, and/or low computational capacity
  • sensors may be resource constrained and may not support cryptography.
  • Deploying cryptographic capabilities may increase the cost per sensor and may be prohibitive to the application.
  • a standard cryptographic hash function, for example, such as SHA-3 may be beyond the capabilities of some sensors.
  • Lightweight authentication protocols and hashing algorithms which may have been studied during the last decade, may be key enablers for 5G networks.
  • the a WTRU may specify service requirements through QCI, which may be matched to the use cases in 5G systems.
  • Techniques from IETF to facilitate network configuration in a manner suitable for 5G networks to match requested service requirements in a network through propagation of the QCI may be utilized.
  • QCI e.g., a variety of QCI
  • An application service provider may choose to provide services based on a service descriptor (e.g., High Mobility and/or Legacy Streaming, etc.), which may be interpreted into detailed information that includes the QCI service requirements to include security requirements of the application.
  • a service descriptor e.g., High Mobility and/or Legacy Streaming, etc.
  • a summary of the high-level steps that may be performed in order for the communications and the associated data to be handled in a secure manner may include Slice Assignment based on Security Requirements, Mapping Slice to Appropriate Path and Functions, and Routing through Assigned SFP.
  • a slice assignment may be determined based on security requirements.
  • a detailed slice request, negotiation, and assignment process may be performed.
  • the representation of a set of service-specific and/or application-specific QCI parameters may be defined by means of a Service Description Document (SDD). Details of the SDD and the Slice request/negotiation processes may be described herein.
  • SDD Service Description Document
  • a Service Description Document for network slicing may be utilized.
  • An NS's services may be described by a Service Description Document (SDD).
  • SDD Service Description Document
  • An SDD may include a description of the services provided by a particular NS (e.g., latency, throughput, etc.) and/or their corresponding QoS Class Identifier values.
  • QCIs may be used (e.g., commonly be used) as a service characteristic for data bearers (e.g., different data bearers) that may be assigned to sessions (e.g., different sessions).
  • the notion of QCI may be extended to support a slice definition.
  • a SDD may have QCIs for affinities and/or restrictions used (e.g., required) for a slice (e.g., geographical affinity and/or restriction, certain hardware affinity and/or restriction, restriction on the capacity of the slice, etc.).
  • Traditional networks may provide a set of services within a single network.
  • the network may be catered for a limited set of service characteristics that may be separated into two or more major classes.
  • the major classes may include real time services and/or non-real time services.
  • the real time services may be a conversational class and/or a streaming class.
  • the non-real time services may be an interactive class and/or a background class.
  • Applications and/or services on a WTRU or in an application serving network may be aligned with the best fitting and/or most suitable NSs.
  • the SDD which may also be referred to and used
  • the NSSAI may be sent to a SN, for example, in a service request message.
  • the NSSAI may include one or more single NSSAIs (S-NSSAIs).
  • the network may select a NS based on the NSAAI.
  • An S-NSSAI may identify a NS.
  • the S-NSSAI may include a slice/service type (SST), which may refer to expected NS behavior, for example, in terms of QoS features and/or services.
  • S-NSSAI may include a Slice Differentiator (SD).
  • the SD may include optional information that complements the SSTs. The SD may enable further differentiation for selecting an NS instance from multiple NS instances that may comply with the indicated SST.
  • FIG. 11 illustrates an example mapping 1100 of the QCI and associated key performance indicators (KPIs) to various service categories.
  • an SDD may specify QCI and KPIs that correspond to the QCI may be determined, e.g., derived from the 3GPP standard.
  • the QCI and associated KPI may be non-exhaustive and may illustrate a range of use cases of differing service requirements (e.g., security).
  • QCI may include one or more of data rate, latency, reliability, availability, mobility, density, and/or power.
  • the detailed QCI / Security requirements and associated KPIs may be matched up with the three use cases as described in FIG. 8.
  • Each KPI may have different QCI for the uplink and the downlink.
  • two data rate values may be associated with a KPI. When two data rate values are provided for a KPI, an upper data rate value may be for the downlink and/or a lower data rate values may be for the uplink.
  • One or more parameters may be inherited from a legacy 3GPP LTE QCI table. Such parameters may not be sufficient to provision the new features and/or requirements in 5G networks. For example, as shown in FIG. 11 A, a low Packet Loss Rate (PLR) value may not guarantee a reliable network.
  • PLR Packet Loss Rate
  • the Radio Link Control (RLC) protocol at the radio link layer (RLC mode - Transparent, Ack, or UnAck.) and/or the Hybrid-ARQ retransmissions (retransmissions threshold) at the MAC layer may be configured in modes (e.g., different modes) to enable reliable (e.g., more reliable) communications.
  • Controlling the call/session Success Rate (SR) and/or the call/session setup time may enforce the network availability as a feature (e.g., new feature) in 5G networks.
  • Dense networks may emerge in 5G networks, for example, because of the massive increase in the number of WTRUs and/or the introduction of the new mMTC use case.
  • Connection density may be an indication of the number of connections per unit area.
  • Traffic density may be an indication of total required data rate per unit area.
  • the connection density may be expected to be high (e.g., extremely high) in the mMTC use case, unlike the traffic density, which may not be high in the mMTC use case. Traffic density may be high in the dense BBN use case (e.g., because of high data rates).
  • a Handoff Success Rate (HOSR) of eNBs is a metric that may be used to select an appropriate eNB to serve a session according to the use case's required mobility management.
  • the variety of diverse 5G use cases may impose one or more security requirements on the delivered services (e.g., confidentiality, integrity protection, authorization, and/or user privacy).
  • security requirements e.g., confidentiality, integrity protection, authorization, and/or user privacy.
  • data plane security may be determined by the services being provisioned and/or established for a session.
  • the International Mobile Subscriber Identity (IMSI) and/or the Temporary Mobile Subscriber Identity (TMSI) may be protected in all over-the-air connectivity modes for use cases.
  • the security considerations may be considered for 5G systems by providing mechanisms to tune the security algorithms and/or parameters for services (e.g., different services).
  • Introducing use cases may impose the use of (e.g., need for) new authorization mechanisms (e.g., multi-level authorization).
  • security implications e.g., new security implications
  • security attributes may introduce (e.g., mandate introducing) security attributes to the QCIs, as shown in FIG. 1 IB and 11C.
  • network security algorithms to may be (e.g., may need to be) power efficient (e.g., highly power-efficient).
  • Low- complexity and/or scalable algorithms may be vital in an mMTC use case.
  • low- complexity and/or scalable algorithms may be vital in an mMTC use case in order to minimize the burden (e.g., processing burden) on devices (e.g., small footprint battery powered devices) expected to be serviced.
  • Privacy e.g., user privacy
  • a security level may indicate a level of authentication strength, a level of integrity protection, a level of confidentiality protection, a level of isolation of functionality from other services, and/or a level of privacy protection.
  • the security level may be indicated for user plane data and/or control plane messages.
  • the level of protection may indicate a strength of the security algorithm, a length of a credential or key, one or more security protocols used, a type of security algorithm (e.g., such as asymmetric keying vs. symmetric keying), etc.
  • a security level may include a security assurance level of the platform and/or a security assurance level of the network(s) that is providing the services including application servers, routers, and the whole infrastructure.
  • a security assurance level may indicate one or more security policies, processes, procedures, and/or best practices that may have been developed and/or used for deployment of the network and services by a serving network or application services provider.
  • Security levels may not be limited to those described herein and may also include other features such as replay protection, protection against breaking of a security algorithm by means of quantum computers, etc.
  • FIG. 12 depicts an example simple SDD 1200.
  • the application/WTRU may send a SDD 1200 to the network.
  • This SDD 1200 may include the package of services requested by the user.
  • the SDD 1200 may be associated with an application ⁇ e.g., such as whatsapp as shown in FIG. 12).
  • the SDD 1200 may enable the application and/or a WTRU to provide information about the application service characteristics.
  • the SDD 1200 may enable an application and/or a WTRU to provide information about the application service characteristics bundled as part of the application and/or to provide details (e.g., granular details) about security and/or other QoS requirements to a Serving Network (SN).
  • An application and/or underlying application-aware service requirements layer and/or other lower layers may communicate the required service from a WTRU to a Service Network using a SDD 1200.
  • the service characteristics (e.g., QoS and/or security requirements) of applications may be communicated from the application to lower layers (e.g., MAC / Logical-link layer) by means of cross-layer messaging.
  • the lower layer protocol may communicate the SDD 1200 to the SN using MAC / Logical-link layer protocols (e.g., RRC/NAS and/or 5G/New Radio (NR) MAC layer protocol).
  • the QoS requirements may be communicated via a service layer which may be used by the WTRU and/or application to communicate the SDD 1200 to the SN using protocols, such as HTTP.
  • the SDD 1200 may be pre-configured at the appropriate layers.
  • the SDD 1200 may be pre-configured at the appropriate layers without the requirement for cross-layer messaging.
  • the QoS and/or security requirements may be provided by means of an API to a user interface.
  • the QoS and/or security requirements may be provided by means of an API to a user interface so that a user may be made aware of the security and/or QoS requirements.
  • the SDD 1200 may indicate a type of application 1204 and/or a class of application 1206.
  • the SDD 1200 may indicate a SDD identifier (ID) 1202 that is associated with the application.
  • ID SDD identifier
  • the header of the SDD 1200 may include an SDD identifier 1202 (e.g., SDD ID), its associated attributes (e.g., digital signature, date of creation, author, owner, alias, preferred operator, etc.).
  • SDD ID e.g., SDD ID
  • associated attributes e.g., digital signature, date of creation, author, owner, alias, preferred operator, etc.
  • the header of the SDD 1200 may indicate the type of application 1104 and/or the class of application 1106.
  • FIG. 13 depicts an example SDD 1300 with service information 1310.
  • the example SDD 1300 may provide information (e.g., granular information) regarding the services that form part of the application.
  • the SDD 1300 may describe one or more service components of a requested and/or offered Network Slice (NS) (e.g., HD Audio, SD Video, Text 140, store and forward, etc.) and/or their associated QCIs, security requirements etc.
  • NS Network Slice
  • the SDD 1300 may indicate one or more of a SDD ID 1302, a type of application 1304, a class of application 1306, a security level 1308, one or more services 1310, or one or more security parameters 1312 associated with the SDD. As shown in FIG.
  • the services 1310 indicated by the example SDD 1300 may include a legacy conversation voice, a low cost video, and/or an SMS. Additional parameters indicated via the services 1310 may include the SST, SD, and security parameters 1312.
  • the security parameters 1312 may include a security algorithm, a confidentiality, an integrity requirement, a privacy requirement, an issuer, a key identifier (KID) or credential identifier, a digital signature, and/or the like.
  • FIG. 14 depicts an example SDD 1400 that separates QCI according to different service planes (e.g., user plane and/or control plane) and/or for uplink and downlink.
  • An application may request an SDD 1400 with Security and QoS requirements (e.g., very detailed Security and QoS requirements) by specifying custom QCI for a particular application.
  • the SDD 1400 may specify QCI for discrete services.
  • the SDD 1400 may specify QCI for a first service 1410 (e.g., Service 1), a second service 1420 (e.g., Service 2), a third service 1430 (e.g., Service 3), and a fourth service 1460 (e.g., Service N).
  • the SDD may indicate various QCI for each service.
  • the SDD 1400 may indicate a first QCI 1412, a second QCI 1414, a third QCI 1416, and a fourth QCI 1418 for the first service 1410.
  • the SDD 1400 may indicate a first QCI 1422, a second QCI 1424, a third QCI 1426, and a fourth QCI 1428 for the second service 1420.
  • the SDD 1400 may indicate a first QCI 1462, a second QCI 1464, a third QCI 1466, and a fourth QCI 1468 for the fourth service 1460.
  • the SDD 1400 may separate attributes into different service planes. For example, one or more of the services (e.g., the third service 1430 as shown in FIG. 14) may be associated with one or more service planes.
  • the SDD 1400 may specify, for one or more of the services 1410, 1420, 1430, 1460, QCI for a Control Plane (CP) 1402, a User Plane (UP) 1404, and a Management Plane (MP) 1406.
  • the SDD 1400 may indicate a first QCI 1432, a second QCI 1434, a third QCI 1436, and a fourth QCI 1438 for a control plane 1402 of the third service 1430.
  • the SDD 1400 may indicate a first QCI 1442, a second QCI 1444, a third QCI 1446, and a fourth QCI 1448 for a user plane 1404 of the third service 1430.
  • the SDD 1400 may indicate a first QCI 1452, a second QCI 1454, a third QCI 1456, and a fourth QCI 1458 for a management plane 1406 of the third service 1430.
  • Network slice parameters for appropriate service planes may be expressed by a corresponding set of QCI attributes. For example, as depicted in FIG. 14, the CP 1402, the UP 1404, and the MP 1406) for Service 3 may each have a separate set of corresponding service plane attributes.
  • Standardized and/or pre-provisioned NS's may be requested by a WTRU by including an SDD ID and/or its alias (e.g., "whatsapp" would be an alias for a NS with a particular SDD ID and/or associated set of services) in a request (e.g., a requested SDD
  • the NS requirement may be categorized (e.g., may alternatively be categorized) as a NS with the slice descriptor.
  • the NS requirement may be categorized as an NS with the slice descriptor as shown in FIG. 11.
  • the whatsapp application scenario may include at least one or more of the following services: a Legacy Conv Voice service, a NS with a Low Cost data service, and/or a NS with SMS texting service capability.
  • Each of these services may be associated with one or more unique network slices.
  • the services may be enabled via multiple NSs. Each of the multiple NSs may cater to the different traffic
  • Such an SDD alias translation into NS requirements may work if (e.g., only if) such SDD ID or SDD aliases are standardized. Additional examples may include default NSs (e.g., legacy 4G NS, Emergency Calling NS, credential provisioning NS, etc.), which may be available for selection in home and/or roaming scenarios.
  • a set (e.g., an expanded set) of NSs may be made available by way of a negotiation involving a Request (e.g., a requested SDD (SDDR)) and an Offer (e.g., an offered SDD (SDDo)).
  • a network may select one or more NS(s) based on an attempt to match the SDD characteristics with the network's slices, e.g., when a network receives an SDD.
  • An example slice-selection may be summarized by means of the flowchart as illustrated in FIG. 15.
  • An SDD may be encoded using JSON, XML, CBOR, and/or a compressed data record.
  • the SDD may be protected for integrity and for confidentiality. Integrity of the SDD may be provided by creating a digital signature, for example, by the issuer using asymmetric cryptography.
  • a digital signature on the SDD may be generated by the issuer by using the private key of the "issuer" (e.g., facebook.com).
  • Symmetric keys may also be used to provide integrity for the SDD.
  • a digital signature may be generated by means of asymmetric cryptography (e.g., Elliptic curve digital signature standard (ECCDSA)) that may or may not be quantum computer safe.
  • ECCDSA Elliptic curve digital signature standard
  • the SDD may be protected for confidentiality and/or privacy by encrypting the SDD and/or enveloping the SDD into an object (e.g., a secure object, such as Json Web Encryption object (JWE) or an equivalent CBOR object etc). Encryption of the SDD may be achieved by means of symmetric keys that are shared between the application and/or WTRU and the SN.
  • JWE Json Web Encryption object
  • the encryption and privacy of the SDD may also be ensured by encrypting the SDD using the public key (asymmetric cryptography) of the SN.
  • the SN may decrypt the SDD by means of the private key of the SN.
  • One or more public keys associated with the SN may be assumed to be pre-provisioned, obtained by the WTRU during the initial connect / authentication phases, and/or using any other key distribution mechanism.
  • a WTRU and/or an application may negotiate a slice assignment with a SN.
  • an SDD may be presented (e.g., sent) to the SN by the WTRU.
  • the SN and/or the WTRU may perform a slice negotiation, followed by a slice assignment to the WTRU.
  • a flow-chart that describes the slice negotiation and/or selection process between the SN and the WTRU is provided in FIG. 15.
  • the WTRU may have performed an attachment with the serving network using the MAC / Link Layer before the Slice Negotiation and/or Assignment occurs.
  • the Slice Selection may include one or more of the following messages and/or procedures.
  • the WTRU may have performed an attachment and/or authentication prior to slice selection.
  • the WTRU may have performed an attachment and/or authentication to the functional block in the SN that is common for a group or all slices being served by the SN using the MAC / Link Layer before the Slice Negotiation and/or Assignment occurs.
  • FIG. 15 depicts a flow-chart of an example slice selection 1500.
  • a Request message that includes an SDD may be received by the SN.
  • a Request message that includes an SDD may be received by the SN from a WTRU.
  • the Request message may include a Requested SDD (SDDR).
  • SDDR may include zero or more SDDs (e.g., an array of SDDR).
  • the SDDR may be a network slice selection assistance information (NSSAI) message.
  • a NSSAI message may include a collection of various single NSSAI (S-NSSAI) messages.
  • a S-NSSAI may assist the network in selecting a particular Network Slice.
  • a S-NSSAI message may identify a network slice.
  • a S-NSSAI message may include a slice/service type (SST) and/or a slice differentiator (SD).
  • the SST may indicate the expected Network Slice behavior, for example, in terms of features and/or services.
  • the SD may complement the SST and may allow further differentiation for selecting a Network Slice from the potentially multiple Network Slice instances that may comply with the indicated Slice/Service type.
  • the Serving Network may determine whether a lower-layer connection Request may be made by a legacy WTRU (e.g., 4G device). If the WTRU is determined to be a legacy WTRU, the process may move to Step nine and/or, based upon policy, the process may be terminated or a default legacy slice may be assigned. This step may be useful in order to mitigate masquerading attacks (e.g., WTRU pretending to be a 5G device).
  • a legacy WTRU e.g., 4G device
  • the SN may determine whether the WTRU is authorized to perform a request to obtain a slice by retrieving the WTRU and/or Subscriber Profile (SProf) 1540).
  • the SProf 1540 may include information about the WTRU and/or Subscriber which may be stored in a database within the SN and/or in a trusted third-party network. If the SN determines that the WTRU is not authorized, the flow may move to twelve 1524 to seek WTRU authorization.
  • the SN may determine if the WTRU had provided a Requested SDD (SDDR), e.g., if the WTRU has been deemed to be authorized to perform the Request.
  • SDDR may be a first SDDR.
  • the SN may perform ten 1520 to obtain an SDD from a stored SProf 1540, e.g., if the WTRU did not provide an SDDR within the Request message.
  • the SDD may indicate a QoS requirement using a QCI value.
  • the SDD may indicate respective QoS requirements for a control plane, a user plane, and a management plane and/or security requirements of a service.
  • the SN may determine if an Offered SDD (SDDo) that fulfills the SDDR, e.g., if an SDDR was present in the Request message. For example, the SN may determine if the SN has an available SDDo that satisfies the SDDR.
  • An SDDR and/or SDDo may be made up of one or more SDDs.
  • An SDDo may satisfy the SDDR when the SDDo includes QoS and security requirement(s) that meet or exceed the QoS and security requirement(s) indicated by the SDDR.
  • the SDDo may be associated with a network slice.
  • the SN may determine if there is a match (e.g., an exact match) between the SDDR and the SDDo. For example, the SN may determine that the SDDo is a match for the SDDR. The SN may determine that the SDDo is a match for the SDDR when the SDDo is configured (e.g., tailored) for the application associated with the SDDR. The SDDo may be configured (e.g., tailored) for the application when it indicates the application and includes QoS and/or security requirement(s) associated with the application. The SN may determine that the SDDo is not a match for the SDDR when the SDDo is not configured (e.g., tailored) for the application associated with the SDDR.
  • a match e.g., an exact match
  • a match may include a WTRU sending an SDDR for "MyChatApp” (e.g., whatsapp) application and/or the SN having a slice (e.g., an SDDo) specifically pre-tailored for "MyChatApp.” If there is not a match (e.g., an exact match) thirteen 1526 may be performed.
  • MyChatApp e.g., whatsapp
  • slice e.g., an SDDo
  • authorization checks may be carried out, for example, if the slice service is a high integrity service.
  • Authorization checks may include multi-factor subscriber and/or user authentication.
  • Multi -factor user authentication may include platform attestation.
  • an explicit user consent may be obtained (e.g., in case of extra cost associated with access to the particular slice).
  • the SN may determine if the WTRU and/or subscriber has been authenticated (e.g., adequately authenticated), for example, when it determines that additional authorization checks are required. If authorization checks have not been passed (e.g., the WTRU and/or subscriber are not authenticated), the flow may move to eleven 1522 and the SN may send a service request denial to the WTRU.
  • the WTRU and/or subscriber has been authenticated (e.g., adequately authenticated), for example, when it determines that additional authorization checks are required. If authorization checks have not been passed (e.g., the WTRU and/or subscriber are not authenticated), the flow may move to eleven 1522 and the SN may send a service request denial to the WTRU.
  • the SN may determine if the WTRU has requested a catalog (e.g., an entire catalog) of the services offered by the SN.
  • a catalog e.g., an entire catalog
  • a slice (e.g., network slice) that matches the SDDR may be assigned to the WTRU and/or application, for example, if the WTRU did not Request for a catalog (e.g., an entire catalog) of services offered.
  • the SN may assign the slice to the WTRU based on the QoS and security requirement(s) indicated in the SDDR.
  • the SN may send, to the WTRU, a response message that indicates the successful assignment of a slice that meets or exceeds the
  • the SN may obtain the SDDR from the SProf 1540 and/or the results may be provided to determine a default SDD that may be assigned (e.g., offered) to the WTRU.
  • the subscriber may be authorized to be assigned one or more SDDs.
  • the SDDs identified by associated SDD IDs (e.g., each one of the SDDs identified by associated SDD IDs) may be obtained from the SProf 1540, e.g., if the subscriber is authorized to be assigned one or more SDDs.
  • a service request denial may be sent by the SN (e.g., sent by the SN to the WTRU).
  • a WTRU may seek to obtain authorization (e.g. using payment and/or subscriptions options).
  • the WTRU may determine if the SDDo is acceptable. For example, the SDDo may satisfy the QoS and/or security requirement(s) associated with the application but not match the SDDR. The WTRU may determine that the SDDo is acceptable if based on the QoS and/or security requirement(s) indicated by the SDDo.
  • the WTRU may determine a second SDDR (e.g., a new SDDR) based on the SDDo.
  • the second SDDR may be the SDDo (e.g., the complete SDDo) and in other cases, the SDDR may be a subset of the SDDo.
  • the WTRU may determine to request a catalog of services from the SN.
  • the WTRU may send a Request message for obtaining the catalog of services from the SN, for example, if the WTRU determined to request the catalog (e.g., at fifteen 1530).
  • the SN may send (e.g., offer) one or more catalogs of services to the WTRU, for example, if the SN determined that a catalog has been requested by the WTRU (e.g., in eight 1516), or if there was no match for the first requested SDDR.
  • the WTRU may select the second SDDR from based on the catalog, for example, based on the one or more catalog services offered by the SN.
  • an SDDR request may be sent by the WTRU (e.g., a request that includes the second SDDR) to the SN.
  • the second SDDR may have been selected by the WTRU using the SDDo (e.g., in fourteen 1528) and/or using the catalog (e.g., at seventeen 1534).
  • the second SDDR may indicate QoS and security requirement(s) that differ from the first SDDR.
  • a WTRU may negotiate for a slice based on its current SDD request and/or the network may take into consideration the WTRU/Subscriber's profile with the current SDD request sent by the WTRU.
  • An Application Service Provider (ASP) may perform (e.g., may alternatively perform) the negotiations on behalf of the WTRU with the SN.
  • both the WTRU and the application service provider may negotiate (e.g., jointly) with the SN for requesting a service and/or a slice, for example, based on QCI and/or service requirements.
  • a slice assignment may be performed based on a WTRU/Subscriber Profile.
  • FIG. 16 depicts an example slice assignment based on a WTRU/Subscriber Profile.
  • the network may use the WTRU/Subscriber's profile with the SDD, for example, to assign a slice (e.g., a consistent slice).
  • a consistent slice may be assigned to the WTRU using the subscriber's information in the Subscription Profile Repository (SPR), (e.g., subscriber's allowed services, subscriber category, subscriber's charging related information, etc.).
  • SPR Subscription Profile Repository
  • the flow in FIG. 16 may illustrate the network assigning a slice to a subscriber based on the subscriber's profile.
  • a WTRU 1602 may attach to a SN 1606, for example, using a default slice.
  • the WTRU 1602 may have been identified and/or authenticated as part of the attachment process with the default slice.
  • the SDF 1604 may be co- hosted with a VNF and/or may be implemented as a VNF.
  • the WTRU 1602 may send a subscriber identifier (e.g., EVISI) to the SDF 1604.
  • the subscriber identifier may or may not be associated with an MNO.
  • the subscriber identifier may be associated with a third-party Identity Provider (e.g., OTT provider, such as Google and/or a Gmail id may be used, e.g., instead of the IMSI).
  • OTT provider such as Google
  • Gmail id may be used, e.g., instead of the IMSI.
  • the SDF 1604 may send a request to a Subscriber Profile Database (SPD) 1608 to obtain and/or access a subscriber profile associated with the WTRU 1602 and/or IMSI stored in the SPD 1608, for example, if the WTRU 1602 had provided an IMSI.
  • SPD Subscriber Profile Database
  • the SPD 1608 may send the subscriber profile that was requested by the SDF 1604, for example, if the request from the SDF 1604 has been authenticated and/or if the SDF 1604 has been authorized.
  • the SPD 1608 may send a slice-id (e.g., NSSAI) that identifies (e.g., uniquely identifies) the slice that the WTRU 1602 and/or application that the WTRU is hosting is authorized to attach to.
  • a slice-id e.g., NSSAI
  • the SDF 1604 may check to see if the WTRU 1602 and/or Subscriber has been authorized to perform such a request (e.g., slice request), for example, based upon the information obtained from the subscriber profile.
  • a request e.g., slice request
  • the SDF 1604 may communicate with a Slice Database 1601 and/or obtain the information pertaining to the slice that the WTRU 1602 and/or Subscriber is authorized to attach to, for example, if the WTRU 1602 and/or Subscriber has been authorized.
  • the SDF 1604 may obtain a Risk-metric associated with that slice, the Slice-Id, Slice- Attachment-Point-URI, and/or Policies from a Slice Database 1601.
  • Subscriber. Assertions about the various authentication, verification, and/or authorizations may be combined and/or assessed at the SDF 1604.
  • the SDF 1604 may assign the slice to the WTRU 1602 and/or Subscriber, for example, if the assessments were successfully completed and/or if the
  • the SDF 1604 may send details about the slice.
  • the details may include the Slice-Id, Slice- Attachment-Point-URI, Policies, etc.
  • the SDF 1604 may send the details to the WTRU 1602 via a Slice Response message.
  • the SDF 1604 may send one or more policies associated with the slice and/or slice access to the WTRU 1602.
  • the WTRU 1602 may store the information (e.g., all the information) that was provided to it by the SDF 1604 and may use the information to attach to a slice.
  • Slice Negotiation and Attachment may be performed based on a Slice Request.
  • a slice negotiation and/or assignment may be based on a Slice Request that includes a non-null SDD.
  • a slice negotiation and/or assignment based on a slice request that includes a non-null SDD may include one or more of the following: Slice Negotiation, a Slice Assignment, and/or a Slice Attachment/ Authorization.
  • Slice Negotiation a WTRU and/or a SN may negotiate one or more slices (e.g., appropriate slice(s)) for attachment.
  • Slice Assignment the SN may authorize attachment to one or more slice(s).
  • Slice Attachment/ Authorization may be the process by which the WTRU is authorized to attach to the one or more slice(s).
  • FIG. 17 depicts an example of slice selection 1700.
  • the WTRU 1702 may attach to the SN 1706, for example, using a default slice and similar processes (e.g., authentication and authorization) described herein that may be carried out between the WTRU 1702 and the SN 1706.
  • a default slice and similar processes e.g., authentication and authorization
  • the WTRU 1702 may request a slice by sending a SDDR and/or a WTRU-Id to a SDF 1704.
  • the WTRU 1702 may send a subscriber identifier (e.g., IMSI).
  • the SDF 1704 may send a request to obtain and/or access the subscriber profile associated with WTRU 1702 and/or IMSI stored in a SPD 1710, for example, if the WTRU 1702 had provided an FMSI.
  • the SPD 1710 may send, to the SDF 1704, the subscriber profile that was requested, for example, if the request from the SDF 1704 has been authenticated and/or if the SDF 1704 has been authorized.
  • the SPD 1710 may send a slice-id that identifies (e.g., uniquely identifies) the slice that the WTRU 1702 and/or application is authorized to attach to.
  • the SDF 1704 may also send a request to the SPD 1710 for obtaining information about the Slice-Id.
  • the SPD 1710 may be assumed to store information about Slice-Id and/or some other network function may store information about the slice IDs.
  • the SDF 1704 may check to see if the WTRU 1702 and/or Subscriber has been authorized to perform a request (e.g., a slice request), based upon the information obtained from the subscriber profile.
  • a request e.g., a slice request
  • the SDF 1704 may communicate with a Slice Database 1701 and/or obtain an offered SDD (SDD 0 ) that may match (e.g., closely match) the SDDR, for example, if the WTRU 1702 and/or Subscriber has been authorized.
  • the SDD 0 may include and/or have an indirect link (e.g., URI, URL, IP address) to a catalog that includes the offered list of SDD (e.g., a complete list of SDDo.)
  • the SDF 1704 may compare the SDDR to the SDDo.
  • the SDF 1704 may determine if there is a match (e.g., an exact match) between the SDDR and an SDDo in the catalog.
  • the SDF 1704 may obtain a Risk-metric that may be associated with the SDDo, the Slice-Id(s), Slice- Attachment-Point-URI(s), and/or associated Policies). If there is a match between the SDDR and an SDDo in the catalog, then the process jumps to ten 1732 to perform a risk-based assessment of the WTRU 1702.
  • the SDF 1704 may send a slice response message to the WTRU 1702.
  • the slice response message may include the SDDo, for example, in case if the SDDR does not match the SDDo.
  • the SDDo may be a catalog (e.g., an entire catalog) of the SDD.
  • the SDDo may include information (e.g., miscellaneous information) that may enable the WTRU 1702 to make a decision (e.g., a proper decision) on selection of an SDD. Examples of miscellaneous information may include risk metric information associated with each of the SDD within the SDDo, cost associated with each SDD, etc.
  • the WTRU 1702 may select an appropriate SDD (e.g., a second SDDR) from the SDDo based on various criteria that may include requirements associated with the application that is intending to use the slice.
  • the WTRU 1702 may terminate the slice selection 1700, for example, if one or more of the SDDs within the SDDo does not match the requirements associated with application and/or WTRU 1702.
  • the WTRU 1702 may send, to the SDF 1704, a second (e.g., a new) slice request message that may include the second SDDR selected in seven 1726.
  • a second slice request message may include the second SDDR selected in seven 1726.
  • the SDF 1704 may determine if the second SDDR is one or more of the SDDs within the SDDo and/or if the second SDDR is the complete SDDo. If so, the SDF 1704 may assess the risk associated with the second SDDR. If the second SDDR is not an SDD within the SDDo, the SDF 1704 may reject the slice request and/or initiate a negotiation by performing (e.g., initially performing) a comparison (e.g., such as at five 1722) and/or sending a slice response message (e.g., as in six 1724) that includes a second SDDo that may match the second
  • a comparison e.g., such as at five 1722
  • a slice response message e.g., as in six 1724
  • the SDF 1704 and/or an Authentication / Authorization / Assessment server may perform one or more authentications, authorization checks and/or assessments of the WTRU 1702 and/or the Subscriber, as described herein.
  • the SDF 1704 may assign a slice to the WTRU 1702 and/or
  • the SDF 1704 may send, to the WTRU 1702, one or more details about the slice.
  • the details may include one or more of the Slice-Id(s), Slice-Attachment-Point (SAP) (e.g., URI(s), IP address, etc.), Policies, etc.
  • SAP Slice-Attachment-Point
  • the SDF 1704 may send one or more details about the slice assigned in eleven 1734 to the WTRU 1702, for example, in a slice response message.
  • the WTRU 1702 may store the details sent by the SDF.
  • the WTRU 1702 may send a slice request message.
  • the slice request message may include an "acceptance" indication to the SDF 1704.
  • the acceptance indication may be an accept information element.
  • the slice accept message may be in response to the slice response message received from the SDF and may be sent within a slice request message, for example, if the slice(s) assigned to the WTRU 1702 is/are acceptable to the WTRU 1702.
  • the SDF 1704 and/or a Token Authority Function and/or an Authorization Server Function may generate and/or send one or more Access Token(s) (e.g., Slice- Access-Token) to the WTRU 1702, for example, in a secure manner.
  • Access Token(s) e.g., Slice- Access-Token
  • Fourteen 1740 may be performed as part of twelve 1736. If this message fourteen 1740 was performed as part of twelve 1736 then thirteen 1738 may be skipped.
  • the WTRU 1702 and/or the SAP 1708 may set up a secure communications channel between one another, for example, using the Slice- Attachment-Point (SAP) information provided to the WTRU 1702 by the SDF 1704.
  • the secure communications channel may be enabled by means of TLS, DTLS, IPSec, EAP, and/or by one or more other means.
  • the secure communications channel may depend upon the layer (OSI layer) where the attachment occurs.
  • the WTRU 1702 may send a Slice Attachment Request that includes one or more of the Slice-Id(s), the WTRU-Id, Slice-Access-Token(s), and/or an Application-Id(s) to the SAP(s) 1708.
  • the SAP(s) 1708 may verify the Slice-Access-Token(s) and/or generate WTRU-specific policies, security credentials, and/or keying material.
  • the SAPs 1708 may send to the WTRU 1702 a Slice Attachment Response message that includes, for example, the policies, keying material, and/or slice details.
  • the WTRU 1702 may store the policies, keying material, and/or the slice details for future use.
  • the authorization may be carried out using a token-based mechanism (e.g., using a push/pull model) and/or by messaging (e.g., explicit messaging) between the SDF 1704 and/or the SAP 1708.
  • a token-based mechanism e.g., using a push/pull model
  • messaging e.g., explicit messaging
  • the use of a token is an example for conveying the authorization information between the SDF 1704 and/or the SAP 1708.
  • the Slice Selection described herein may be used when a WTRU requests services offered by a 5G network (5 th Generation cellular network such as those provided by MNOs such as AT&T or Vodafone), and/or Wireless LAN network providers, Network-access provided by an MVNO, and/or Application Service Providers (e.g., Over-The-Top provider such as Google or Facebook), etc.
  • 5G network 5 th Generation cellular network such as those provided by MNOs such as AT&T or Vodafone
  • Wireless LAN network providers e.g., Network-access provided by an MVNO, and/or Application Service Providers (e.g., Over-The-Top provider such as Google or Facebook), etc.
  • FIG. 18 depicts an example slice assignment based on Application Service Provider (ASP) driven service requirements.
  • ASP Application Service Provider
  • an ASP responsible for serving an application e.g., client
  • the role of the WTRU may be minimal in this scenario and/or may contrast with the illustration and/or associated description for Figure 15.
  • the negotiations may be handled by an ASP (e.g., on behalf of the WTRU and/or application running on the WTRU).
  • the WTRU may have performed an attach procedure with an SN.
  • the WTRU may have been identified, authenticated, and/or authorized to connect to a default slice or to the SN Functional block that is common to most (e.g., all) slices served by the SN, e.g., as part of the attach procedure.
  • the attach procedure may have been carried out by using legacy (e.g., 4G and older) and/or 5G mechanisms.
  • the WTRU may be provided with access to default slice(s), e.g., when the attach procedure has been completed.
  • a user may trigger launching (e.g., activate) an application (App) in the WTRU.
  • the user may trigger launching an application by clicking an icon on the WTRU that is associated with the application, by using voice commands, and/or the like.
  • the application may be triggered without a user, for example, based on policies associated with the application on the WTRU.
  • the App When the App is launched, the App may set up a connection with an Application Service Provider (ASP) (e.g., an associated ASP) using the default slice.
  • ASP Application Service Provider
  • the User may be authenticated by the ASP and vice-versa, for example, by using mutual authentication mechanisms (e.g., such as user name / password, FIDO, federated authentication, biometric / multi-factor authentication, etc.).
  • mutual authentication mechanisms e.g., such as user name / password, FIDO, federated authentication, biometric / multi-factor authentication, etc.
  • a message (e.g., a message that includes a request for attachment to a slice with a particular SDD) may be sent to the Serving Network (SN).
  • the request may be sent by the WTRU to the SN and/or the ASP may send the request on behalf of the WTRU/user.
  • the request may (e.g., may only) be sent by the ASP if the authentication (e.g., performed in Step two) is successful.
  • the Request may include a Requested SDD (SDDR).
  • the SN may determine if an SDDR is present in the request message and/or may prepare an offered SDDo. The SN may return an SDDo to the ASP, for example, based on the request.
  • the ASP may determine if there is a match (e.g., an exact match) between the SDDR and the SDDo.
  • the message may include a request for a plurality of SDDs within its SDDR and/or may be matched with a list (e.g., a complete list) of SDDos.
  • the ASP may determine whether there is a match (e.g., an exact match) between the SDDR and the SDDo.
  • the ASP may determine that the SDDo is a match for the SDDR when the SDDo is configured (e.g., tailored, pre-configured, etc.) for the application associated with the SDDR.
  • the SDDo may be configured (e.g., tailored, pre-configured, etc.) for the application when it indicates the application and includes QoS and/or security requirement s) associated with the application.
  • the ASP may determine that the SDDo is not a match for the SDDR when the SDDo is not configured (e.g., tailored, pre-configured, etc.) for the application associated with the SDDR. If there is a match, then the flow may move to twelve 1824.
  • the ASP may determine if the SDDo provided is acceptable for the service request despite not being an exact match (e.g., a preconfigured/predetermined match). The ASP may determine that the SDDo may be acceptable for (e.g., satisfies) the SDDR when the SDDo includes QoS and security requirement(s) that meet or exceed the QoS and security requirement(s) indicated by the SDDR. If the SDDo provided is acceptable, the flow may move to twelve 1824.
  • a modification may be carried out.
  • a second (e.g., new) request message may be sent (e.g., sent back) to the SN.
  • the ASP may request for a tailored SDDR, for example, if the ASP determines not to make a new request (e.g., a new request including a modified SDDR).
  • ASP may indicate to the SN that the ASP may desire a tailored SDD based upon the earlier requested SDDR and/or a modification of the earlier requested SDDR and/or SDDo.
  • the SN may send a service request denial message to the ASP and/or the WTRU.
  • the example slice assignment 1800 may end.
  • the SN may fetch the SDDR from the WTRU/
  • the SProf may be stored at the ASP and/or the WTRU.
  • an SDD (e.g., each SDD) may be assessed for risk and/or a
  • WTRU/subscriber may be authenticated (e.g., further authenticated), for example, based on the risk posed by the WTRU/Subscriber to the NS.
  • a platform attestation may be carried out, for example, in addition to device authentication.
  • a platform attestation may be carried out if the risk is deemed to be higher.
  • a multi-factor authentication of the user may be carried out.
  • Authorization checks and/or authentication of WTRU may be performed to match risk aligned with providing a requested
  • the SN may assign one or more slices to the WTRU, e.g., based upon the SDDR.
  • the SN may send a confirmation to the ASP and/or the WTRU that may include the details of the assigned one or more slices.
  • the flow may move to ten 1820 and/or may conclude.
  • the ASP may select a second (e.g., new) SDDR from the offered SDDo, for example, if the ASP determines that the SDD Request should be modified (e.g., at seven 1814).
  • the ASP may generate a response message (e.g., a new Request message) that may include the second SDDR (e.g., the new SDDR).
  • the flow may move to four 1808.
  • the SN may request that the ASP and/or the WTRU request for privileges (e.g., additional privileges, such as buying a new subscription and/or payment) that may match the SDDR, for example, if the ASP had requested for a tailored slice (e.g., in eight 1816).
  • the flow may move to four 1808.
  • An SCEF may enable network service discovery and/or slice selection by an application service provider.
  • the SCEF may be used to expose the catalog of available slices and/or the slice capabilities to WTRUs and/or to 3 rd party entities.
  • the 3 rd party entities may be interested in providing a service, leasing a NS, and/or leasing parts of a NS (e.g., the RAN and/or Core Network in conjunction with their own service counterpart).
  • a 5G network may allow for a 3 rd party service (and/or WTRU using it) to perform discovery and/or selection of the slice that may be the best fit for its Security Level and/or other QoS parameters for a particular service.
  • the SCEF for example, in conjunction with an SDD, may enable an application service provider to describe a desired service characteristic for a tailored NS.
  • the tailored NS may meet one or more specific services that the application service provider may provide.
  • FIG. 19 illustrates an architecture for slice selection 1900 through a network exposure API (e.g., a SCEF).
  • An application service provider servicing a WTRU may send a request (e.g., a connectivity service discovery request) to the network via the API by specifying one or more specific QCI and/or security requirements.
  • the request may be triggered when a user and/or subscriber initiates an app on a WTRU.
  • the QCI and/or security requirements may be indicated by an SDD as described herein.
  • the SDD may be provided by the WTRU to the network or by the application server on the network side via the SCEF API.
  • the QCI and/or Security requirements may be represented by a service flow identifier, a label, and/or a tag which may be interpreted into more details requirements by for example, reference tables and parameters.
  • the requirements may have a compact form and/or may be represented using quantitative and/or qualitative values (e.g., 1 (Very Low) - 5 (Very High)).
  • the detailed QCI and/or Security requirements may have an elaborate form and/or may be formulated to provide detailed requirements, similar to those shown in FIG. 11 Table 1. Detailed information for one or more of the "confidentiality and integrity", "user privacy”, “authentication protocol”, “authentication complexity,” and/or “authorization” mechanisms may also be provided.
  • the network exposure layer may authorize the application request and/or may forward the application request to an orchestration system.
  • the orchestration system may map the application QoS and/or Security requirements to an internal representation and/or lookup in Network Service Catalog/Record (ETSI terminology) for the best slice which matches the desired criteria.
  • ETSI Network Service Catalog/Record
  • the network exposure may send back a response message (e.g., a positive response message) and/or a network slice reference (e.g., a list of S-NSSAIs with supported QoS/Security levels to the application), for example, if an existing running slice match is found. For example, a lower QoS may be accepted and/or refused by the application.
  • a response message e.g., a positive response message
  • a network slice reference e.g., a list of S-NSSAIs with supported QoS/Security levels to the application
  • a network slice reference e.g., a list of S-NSSAIs with supported QoS/Security levels to the application
  • the application may send a binding request via the API to indicate that it will be using that particular slice.
  • orchestration system may record the application as a user of the slice in a Network Service Record (NSR) for billing and/or lifecycle management and/or may send back a confirmation to the application.
  • NSR Network Service Record
  • Operations may be performed in the context of that slice and may be dispatched through a central entity (e.g., central PCRF to the slice's PCRF).
  • a central entity e.g., central PCRF to the slice's PCRF.
  • the slice selection 1900 through a network exposure API may be separated into two parts, which may be used in tandem.
  • a first part of the slice selection 1900 may not be performed, for example, if the operator has a slice with the required characteristics and/or capacity already available.
  • a slice may be created and/or modified to
  • the service provider and/or Application Service Provider may request the establishment and/or modification of a slice.
  • the request may be prompted by conditions (e.g., a variety of conditions), that may include WTRU communications with the ASP, demand in a region, etc.
  • the request may be made via an API with the SCEF-like function.
  • the orchestration system may create and/or manage the slice as negotiated.
  • the network e.g., the AMF, the NSSF, or the RF
  • the network may create a slice identifier.
  • the network may assign the slice identifier, for example, using the slice determination function which may be part of a network orchestration, configuration, provisioning and management entity.
  • the slice selection 1900 through a network exposure API may be used for roaming NWs, for example, if the compatibility and inter-operability between the visited SCEF and the home SCEF is common.
  • the ASP may request usage of a specific slice for the WTRU.
  • the ASP may request usage of the specific slice for the WTRU using one of several ways.
  • the user identity may be known to the ASP / ISP (e.g. full name as used by some applications) and may be kept hidden from the MNO.
  • the subscriber identity e.g., IMSI, MS-ISDN, etc.
  • the request may leave a non- reputable paper trail.
  • the WTRU may receive from a NW function a temporary WTRU identifier.
  • the temporary WTRU identifier may be single use, short term, long term, and/or may be updated and/or replaced as often as desired.
  • the WTRU may send its WTRU identifier, a slice identifier, and/or a description of the desired service to the ASP.
  • the WTRU may require access through a "default" slice, for example, because the WTRU may not be consuming any services or may not currently have access to the desired slice.
  • the ASP may return the WTRU identifier to the NW function which may have issued it or which may be able to identify the user or WTRU, together with the slice identifier, for example, if the ASP agrees to the use of the slice (e.g., if the user/WTRU is recognized by the ASP and/or the requested service warrants use of the slice).
  • WTRU_Slicel_tempid KDF (KASME, IMSI
  • KASME may be used in EPS
  • an analogous root key may be used in 5G Systems.
  • the WTRU temp id may uniquely identify the identity of the WTRU associated with a particular Slice (e.g., as identified by a Slice-Id).
  • the secure_connection_parameters may be parameters that are known (e.g., only known) to the WTRU and the SN when they have established a secure connection (e.g., by means of TLS / DTLS, IKE / IPSEC or EAP protocol).
  • the inclusion of secure connection parameters in the WTRU identifier may be optional, for example, in case of the existence of a valid KASME. In cases where a WTRU may not have been authenticated by the network, the KASME may not be included, for example, since there is either no valid and non- expired KASME nor does a KASME exists since no authentication has occurred.
  • the KASME may be replaced by a master key or a derivative of the master key associated with the secure connection (e.g., TLS Master Key or derivative of the TLS Master Key).
  • secure_connection_parameters may be tlsdata, tls master secret, challenge nonces etc. in the case where TLS / SSL or DTLS was used to create a secure connection.
  • An example Key Derivation Function (KDF) may be HMAC-SHA-256.
  • the temporary ids used by the WTRU for different slices may be significantly different provided the correct set of KDFs are used in the generation and/or the set of KDFs are unique to each of the slices associated with a single user.
  • Each of the temporary id(s) may have a unique expiration time.
  • the expiration time for a temporary id may be associated with the length of time that the WTRU has been authorized for providing access to that particular slice.
  • the temporary ids may be derived using different
  • secure connection parameters for example, since they may have been derived when the WTRU requested access to a slice by means of a different secure connection and possibly at a different date and/or time.
  • the same secure connection parameters may be used to generate the temporary ids for the different slices, for example, if a request to access one or more services and/or slices is performed using the same secure connection (e.g., TLS).
  • the temporary ids may be different for each slice since the Slice-Id provides the required variability to the generated temporary ids.
  • a key that is used may have been derived out of an authentication between the WTRU and the Network by means of e.g. an LTE Authentication and Key Agreement (AKA) process.
  • the key e.g., credential
  • MSK Master Session Key
  • the key may be any root key that is generated as part of a 5G authentication process (e.g., KSEAF). Any session key that is generated by the WTRU and/or the SN may be used in the generation of the WTRU Slice- Id tempid(s).
  • An ASP may generate the tempid(s) as described herein for the network, except that the session key between the ASP and the SN may be used to generate the tempid(s).
  • the secure connection parameters may be associated with the secure connection between the ASP and SN (e.g., tlsdata for the TLS connection between the ASP and the SN).
  • the above described WTRU temporary identifier e.g.
  • WTRU Slicel tempid) generation may be performed by the WTRU and the Network independently on their own.
  • an ASP requests an SDD on behalf of a WTRU
  • similar mechanisms to those used by the WTRU and/or the Network may be used with some modifications, wherein, the KASME or KSEAF, which may not be available to the ASP are not used in the generation of the tempids.
  • the Slice-Id information may be assumed to be available apriori to the WTRU or ASP, for example, using a pre-provisioning process by the network, obtained by the WTRU or ASP using an external database hosted outside the network, or provided as part of the SDD negotiation process by the network to the WTRU or ASP.
  • the ASP may request a batch of WTRU identifiers, which the ASP may dispense to WTRUs that it agrees to connect through slice.
  • another Network Operator may initiate a process (e.g., a similar two-step process) of slice creation/selection via the same SCEF like API and/or more directly through a dedicated Interworking function (e.g., with adequate trust level) capable of interfacing with the Slice Management system.
  • a slice capability selection principle may apply.
  • the slice capability selection principle may apply regardless of the network slice implementation as chaining (e.g., chaining only) Virtual Network Functions and/or dedicated network functions.
  • Slices and/or QoS/Security capabilities may be catalogued in a repository (e.g., central repository).
  • a WTRU attaches (e.g., initially attaches) to a network
  • the WTRU may attach (e.g., attempt to attach) to one or more NS(s) from which it may wish to request services.
  • NS and/or NSs may include such services and/or may be supported by the Serving Network (SN).
  • the SN may communicate with the WTRU to determine the type(s) of services and/or to provide the services through selected slice(s), e.g., in order for the SN to deliver such services.
  • Such awareness may be achievable (e.g., relatively easy to achieve) for a home network, for example, by pre-provisioning slices required by means of the WTRU Subscriber Profile (e.g., provisioning a list of supported slices in the ME or UICC).
  • pre-provisioning slices required by means of the WTRU Subscriber Profile e.g., provisioning a list of supported slices in the ME or UICC.
  • the home network may not control and/or predict which serving network the roaming WTRU may attempt to attach, and/or slices realized in the home network may be different from slices realized in the serving network and/or may not exist.
  • Infrastructure security information may be used as a parameter for the SDD.
  • Telecommunication networks may depend upon conventional protection mechanisms to protect against what may be vulnerabilities (e.g., common vulnerabilities) in IT systems.
  • vulnerabilities e.g., common vulnerabilities
  • the closed (e.g., proprietary) nature of network devices, their fairly static design, and/or the homogeneity of software may represent defenses against threats (e.g., common threats).
  • Perimeter defenses may protect a network infrastructure from threats (e.g., external threats) and practices (e.g., best practices) for dealing with threats (e.g., internal threats) may provide protection.
  • threats e.g., external threats
  • practices e.g., best practices
  • the systems e.g., existing systems
  • an operator may lose physical control of the parts of the network infrastructure and/or may rely on infrastructure service providers (e.g., IaaS, PaaS, NFVI providers) to provide security based on one or more SLAs (e.g., agreed SLAs).
  • infrastructure service providers e.g., IaaS, PaaS, NFVI providers
  • SLAs e.g., agreed SLAs
  • the infrastmcture service providers may support one or more operators that may use an infrastructure (e.g., the same infrastructure) and may be able to assure that the agreed SLAs are being provided to one or more operators (e.g., each of the operators individually).
  • Information on the level of security may be provided, for example, since the diversity of deployments and/or business case scenarios in 5G may introduce variability in terms of the infrastructure components.
  • a parameter may be added for one or more (e.g., each) of the services included in the SDD for a requested service.
  • the parameter may be used to assign a network infrastructure security (NIS) level.
  • NIS level may be interpreted as the minimum acceptable level of security for one or more (e.g., each) of the functions in a network and may be used to route traffic through the network, for example, through trusted and secure infra-structure.
  • the network may use mappings between slices to an appropriate path and/or appropriate functions when routing communications.
  • the network may translate a Slice and/or an SDD associated with a NS into an SFC, for example, after the network assigns the slice to the user.
  • An SFC may be a chain of NFs that may be needed to be executed for a certain service request, for example, so that the network can meet the service requirements.
  • the network management function may translate an SDD from a WTRU and/or application and/or may assign a slice (e.g., an appropriate slice).
  • the network may determine the SFC, for example, based on the slice information. There may be one or more SFCs that may satisfy a slice requirement.
  • an SFC may be a chain of user plane functions comprising one or more VNFs.
  • the SFC may be applied (e.g., separately applied) to control plane functions, such as handover signaling, authentication signaling, mobility management, etc.
  • the QCI and/or the security level may be input parameters, e.g., when determining the exact VNF instances to be included in a specific SFC.
  • a classifier located at the ingress (e.g., an ingress router / switch / server) of the network may classify the SFC, for example, to pre-determine the full service function path (SFP) of the flow.
  • the classifier may be part of the MANO and/or may establish (e.g., help establish) a connectivity path through the network.
  • the classifiers may be placed at the network's ingress point and/or the classifiers may be placed throughout the network.
  • reclassification of the SFC e.g., if any V F is congested
  • V F failure, and/or path failure may be enabled.
  • Re-classifying the SFC may include the insertion, removal, and/or replacement of VNF within the SFC (e.g., redefine and re-route the pre-determined path).
  • the static and/or the dynamic models may be used. For example, if some parts of the network are designated to be secure (e.g., highly secure), a fixed static predetermined SFP may be used for routing the packets. Dynamic SFPs may be used for other parts of the network, where security may be slightly relaxed. VNFs which may be considered critical for security of the network (e.g., high security) may include the HSS and/or the AAA, which may be made immune (e.g., need to be immune) to one or more risks of compromise and/or may be provided as part of a static SFP, for example, in order to minimize risks to the WTRU and the HSS/AAA.
  • An SFP may be determined based on the SFC.
  • a logical SFC may be mapped to a physical SFP using a static SFC mapping a dynamic SFC mapping, and/or a hybrid mapping.
  • a static SFC mapping may be topology-dependent (e.g., such that an ingress classifier may be placed at the network entrance to classify the SFC accompanied with the received packet and/or may define the full consistent physical path, such as static SFC deployment model).
  • This type of service function deployment model e.g., mapping of a logical SFC to a physical SFP
  • mapping of a logical SFC to a physical SFP may be static and/or may be bound to a fixed topology. They may not adapt (e.g., adapt well) to elastic service environments enabled by virtualization.
  • a topology-independent approach may enable deploying the classifiers more flexibly across a network (e.g., dynamic SFC and/or hybrid deployment models).
  • a SFP may be determined relatively statically from the SFC.
  • FIG. 20 depicts example Static and Dynamic SFC deployments 2000.
  • a Static SFC deployment a full end-to-end network path may be predetermined at the ingress classifier and/or may not be modified and/or adapted as shown in FIG. 20.
  • a static route may be predetermined at the classifier and may not be modified afterwards (e.g., even if one of the VNFs may be congested, VNF failure, link failure, and/or compromised VNF).
  • a packet that is classified using a static path may traverse the following sequence of functions: classifier A ⁇ V F1 ⁇ VNF2a ⁇ VNF3a ⁇ VNF4a ⁇ VNF5 ⁇ VNFn.
  • the V Fs beyond the classifier may not have a capability to re-classify an SFP (e.g., an established SFP).
  • SFP e.g., an established SFP
  • network service deployments may be coupled to network topology.
  • Topology information may be stored in databases for mapping SFCs to physical paths. The configuration may be performed through SDN controllers.
  • the configuration and SFP may be facilitated through the use of intelligence (e.g., in the form of NSH included within a packet).
  • intelligence e.g., in the form of NSH included within a packet.
  • Dynamic SFP Determination from the SFC may be used.
  • the SFC may be classified and/or reclassified at instances throughout the network according to the network status (e.g., VNF congestion and/or failure, a link failure, etc.).
  • the Dynamic SFC deployment may be attractive for 5G systems, for example, because static topology information may be less viable due to scaling, tenancy, and/or complexity reasons.
  • classifiers e.g., A, VNF3a
  • A, VNF3a may be placed throughout the network to remap some of the SFCs in case one or more of the SFPs are no longer consistent with the QCI of the provisioned slice.
  • the classifier A and/or VNF3a may re-route packets using a route (e.g., a newer route).
  • a packet may be routed (e.g., may then be routed) using the path (e.g., the newer path) that may traverse the following sequence of functions: classifier A ⁇ VNFl ⁇ VNF2b ⁇ VNF3a ⁇ VNF4b ⁇ VNF5 ⁇ VNFn.
  • the NIS may be described as a (e.g., another) service
  • NIS Infrastructure security
  • the NIS security level values may be susceptible to change over time, for example, due to attacks, lack of resiliency, and/or another vulnerability.
  • the security level values of such infrastructure entities may be updated (e.g., dynamically updated) over time, for example, to maintain network integrity. Updating the security level values may result in a change in the SFC-physical topology mapping (e.g., redirect flows to alternative routes), for example, due to some network conditions.
  • Hop-by-hop QCI may be utilized for routing.
  • Hop-by-hop QCI may enable the network flow to be classified hop-by-hop (e.g., at each switch/entity) to route through the best next hop according to the QCI requirements of the flow (including NIS requirements).
  • the hop-by-hop QCI may enable the network flow to be classified hop-by-hop to route through the best next hop according to the QCI requirements of the flow. This can be attained by placing a number of SFC classifiers through the network.
  • FIG. 21 depicts an example Dynamic SFC Determination 2100.
  • an SDN-based network at both the RAN and the Core networks may be assumed, as shown in FIG. 21.
  • An SFC classifier switch may be deployed at the entrance of the Core.
  • the SFC classifier may allocate the full network path that may correspond to the SFC accompanied with the network flow as shown by the thick curvy line.
  • One or more open switches may function as Service Function Forwarders (SFFs).
  • SFFs Service Function Forwarders
  • a classifier may have the privilege to update the SFC (e.g., insert and/or remove some functions from the chain).
  • the SFFs may forward (e.g., can only forward) the flows (e.g., packets) based on the destination that corresponds to the executing SFC that was predetermined by a former classifier, for example, unlike the classifier.
  • the SFF may lack control to modify the SFC accompanied with the flow.
  • the classifier may alter the SFC, for example, based on the availability of network nodes.
  • the dynamic SFC determination 2100 may include a back-up route for the full network path, for example, if switch A is down. If the next hop is an SFC-unaware service function, the flow may go through an SFC proxy, for example, before being forwarded to a network function.
  • Some switches may not be configured to operate as a classifier.
  • classification-capable switches may be strategically placed throughout the network such that the resiliency of the network is assured while minimizing deployment costs. Strategically placing classification-capable switches may provide flexibility in allocating service resources and/or more robust SFPs.
  • Routing may be performed via an assigned SFP.
  • packets and/or datagrams that originate from a WTRU for a particular application with an associated SDD and for which the SFC and associated SFP have been determined may be routed using routing information/intelligence within the network (e.g. configuration of the SDN controllers).
  • packets and/or datagrams that originate from a WTRU for a particular application with an associated SDD and for which the SFC and associated SFP have been determined may be routed using routing information incorporated in the packets emanating from the WTRU.
  • the routing information may be provided as high level information attributes (example's., QCI levels as described herein) within the packets and/or datagrams.
  • QCI levels as described herein
  • the two static and dynamic modes and/or a hybrid mode of packet/datagram routing may be considered.
  • Routing through an assigned SFP may be performed using a preconfigured static path.
  • a classifier may read the packet header to determine a full SFP.
  • the SFC may be classified and/or mapped to an SFP and/or the network path may be determined and/or setup as intelligence in the network.
  • the SDN controllers may be provided with the pre-determined path information that may be used by the SDN controllers to configure the switches and/or routers. The path may not be reclassified.
  • Routing through an assigned SFP may be performed using a static path defined within a packet.
  • the packet and/or datagram emanating from the application in the WTRU may play a vital role in its routing.
  • Some information may be added to the packet's header to indicate the construction of the SFP, for example, to enable flexibility and/or dynamic function selection for the SFC deployment.
  • the classifier may read the packet header information to determine the full SFP and may construct header information for the packet. This functionality may be included into some of the currently used L2/L3 network protocols (e.g., source-routing headers).
  • An enhancement of the IETF defined NSH may be used, for example, in order to achieve this QCI based routing.
  • each VNF may read the NSH header information to determine the next hop (e.g., the next VNF to be executed).
  • the packets may include the Slice-Id, which may be used by the classifier and/or router to determine the path.
  • FIG. 22 depicts an example call flow 2200 illustrating usage of information included within a packet/datagram.
  • information about slices and/or SFC may be pre- populated from the SFC Routing Information Dissemination Function (SRJDF) to the Classifier Function (CF) 2204 and/or the SDN Controller.
  • SRJDF SFC Routing Information Dissemination Function
  • CF Classifier Function
  • the information sent to the CF 2204 may include the details on the SFC, identified by an SFC-Id for each slice, identified by a Slice-Id.
  • the information sent to the CF 2204 may include policies on the NSH that may be created based upon the SFC for that slice.
  • the information that may be provided to the SDN Controller may be detailed information, for example, on how routing of packets / datagram may be handled.
  • the information may provide details on how the VNFs may be reached and/or default routing information if a VNF may not be reached.
  • the information may include associated routing, QoS, and/or security policies.
  • a packet from a WTRU 2202, identified by a WTRU-Id and/or a Slice- Id, may be received by a CF 2204.
  • the CF 2204 may have been pre-configured with
  • the initial attachment point with a SAP may be the address of the CF 2204.
  • the WTRU 2202 may be provided with a link to the CF 2204 that may form part of the SAP.
  • the CF 2204 may perform a look-up of the list of SFCs that make up the SFP, for example, using the slice-Id as an index to the table that maintains the link(s) between Slice-Id, SFC, and/or the associated SFP.
  • the CF 2204 may add an NSH to the packet header and/or may add the list of SFCs or SFP components within the NSH.
  • the SFP components may be addressable as: IP address and/or port number, URL and/or port number, VNF-Id (e.g., which may be translated to addressable endpoints), etc.
  • the CF 2204 may initialize the SI within the NSH.
  • the CF 2204 may identify an NF (e.g., the next NF) that may be targeted for this packet.
  • the lower layer may identify the SDN Switch to which the packet may be forwarded to.
  • the CF may forward the packet to SDN Switch 1 2206.
  • the determination of the forwarding of the packet may be based upon the routing information that may have been populated by the SDN controller at zero 2216.
  • the SDN Switch 1 2206 may determine the NF within the chain. The SDN Switch 1 2206 may determine (e.g., may then determine) the SDN Switch that may lead the packet to the appropriate VNF 2210.
  • the SDN Switch 1 2206 may forward the packet and/or datagram to SDN Switch 2 2208.
  • the SDN Switch 2 2208 may inspect the NSH and/or may determine that the next NF (e.g., the next NF that is to service the packet) which may be accessed via it.
  • the SDN switch 2 2208 may translate the SPI and/or the SI into the next-hop (e.g., Next NF to be executed).
  • the SDN switch 2 2208 may send the packet to the VNF 2210.
  • the VNF 2210 may execute an appropriate function to be carried out.
  • higher layer protocols may be used, for example, the SDN switch 2 2208 may send the packet to the VNF 2210 using higher-layer protocols (e.g., HTTP, CoAP etc.).
  • termination of the packet may occur at a user plane function (e.g. UPF).
  • UPF user plane function
  • the UPF may be implemented on an application server.
  • the VNF 2210 may process the packet. Processing the packet may include performing security, session management operations, etc., based on the data within the packet and/or based on the type of network function being performed by the VNF 2210.
  • the VNF 2210 may forward the packet to the SDN Switch 2 2208 and/or to one or more other routing / switches (e.g., a default Switch), for example, once the packet has been processed.
  • a default Switch e.g., a default Switch
  • the SDN Switch 2 2208 and/or one or more other routing / switches may modify (e.g., decrement by one) the NSH, for example, in order to indicate the next VNF function to be targeted.
  • the SDN switch 2 2208 may determine the next VNF using the modified NSH.
  • the NIS information may be taken into consideration when forming the SFC (e.g., NIS-based SFC). No additional information may be embedded and/or carried in the NSH header, for example, to indicate the requested NIS level.
  • the CF 2204 and/or SDN controller may utilize the SFC information to route packets.
  • a dynamic path may be used for routing through an assigned SFP.
  • the packet may carry routing
  • the network may determine (e.g., dynamically determine) the SFP navigated, for example, based upon a QCI indication and/or label included within the packet/datagram.
  • the network path may not be pre-determined.
  • the network path may be established at a hop VNF (e.g., each hop VNF) that may be selected and/or that meets and/or exceeds the QCI and/or security requirements as specified.
  • the specific VNF that may satisfy the intent of the QCI may be determined at a hop (e.g., each hop) VNF and/or the SDN controller configured, for example, based on the interpretation of the QCI indication.
  • a hybrid path may be used for routing through an assigned SFP.
  • part of the SFP may be performed in a subnetwork (e.g., based on information/intelligence included within the network).
  • part of the SFP may be performed in a sub-network based on
  • NSH a specialized header
  • this may be feasible for separation of RAN and/or Core networks.
  • a hybrid routing may be applied where the packets (e.g., very first packets) for a particular session (e.g., during session setup) may be routed following a hop by hop classification and/or switching mechanism using NSH insertion and/or lookup.
  • This initial traffic setup after leaving the last switch may lead to the establishment of a new SFP.
  • One or more subsequent packets may follow the new SFP, for example, by regular network based routing (e.g., as soon as a SFP is traced once, normal SDN flow control without the need for the NSH can take over).
  • 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Abstract

L'invention concerne des systèmes, des procédés et des instruments de sélection et d'attribution de tranches à base de sécurité. Un dispositif de réseau peut recevoir, en provenance d'une WTRU, un message de requête de rattachement qui comprend un SDD demandé qui est associé à une application. Le SDD demandé peut indiquer une exigence de flux de service. Le dispositif de réseau peut déterminer un SDD proposé. Le SDD proposé peut satisfaire l'exigence de flux de service dans le SDD demandé. Le dispositif de réseau peut attribuer une tranche de réseau à la WTRU, par exemple, sur la base de l'exigence de flux de service. Le dispositif de réseau peut attribuer la tranche de réseau à la WTRU sur la base du fait que le SDD proposé correspond au SDD demandé. Le SDD proposé peut correspondre au SDD demandé lorsque le SDD proposé est personnalisé pour l'application. Le dispositif de réseau peut envoyer, à la WTRU, un message de réponse qui indique la tranche de réseau attribuée.
PCT/US2017/032804 2016-05-16 2017-05-16 Sélection et attribution de tranches à base de sécurité WO2017200978A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662337076P 2016-05-16 2016-05-16
US62/337,076 2016-05-16
US201662355202P 2016-06-27 2016-06-27
US62/355,202 2016-06-27

Publications (1)

Publication Number Publication Date
WO2017200978A1 true WO2017200978A1 (fr) 2017-11-23

Family

ID=58873882

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/032804 WO2017200978A1 (fr) 2016-05-16 2017-05-16 Sélection et attribution de tranches à base de sécurité

Country Status (1)

Country Link
WO (1) WO2017200978A1 (fr)

Cited By (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018231125A1 (fr) * 2017-06-16 2018-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Réseau, nœuds de réseau, dispositifs de communication sans fil et procédé dans ceux-ci pour gérer des tranches de réseau dans un réseau de communication sans fil
US20190124544A1 (en) * 2017-10-24 2019-04-25 At&T Intellectual Property I, L.P. Systems and methods for on demand intelligent analytics dynamic access network slice switching and carrier aggregation
WO2019106308A1 (fr) * 2017-12-01 2019-06-06 Orange Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur
WO2019114988A1 (fr) * 2017-12-15 2019-06-20 Nokia Technologies Oy Procédé de commande de transmission de données à l'aide de tranches de réseau
CN109922540A (zh) * 2019-03-01 2019-06-21 展讯通信（上海）有限公司 无线收发设备组通信方法、设备组、系统及存储介质
EP3503492A1 (fr) * 2017-12-22 2019-06-26 Deutsche Telekom AG Techniques permettant d'établir une communication de données basée sur une identification d'utilisateur
WO2019193252A1 (fr) * 2018-04-06 2019-10-10 Nokia Technologies Oy Procédé et appareil de messagerie de fonction de réseau
CN110446233A (zh) * 2018-05-04 2019-11-12 华为技术有限公司 切换方法、设备及系统
WO2019229492A1 (fr) * 2018-05-26 2019-12-05 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et systèmes de demande par un ue de nssai appropriées dans une 5g
WO2020035732A1 (fr) * 2018-08-13 2020-02-20 Lenovo (Singapore) Pte. Ltd. Authentification de tranche de réseau
US20200106812A1 (en) * 2018-09-27 2020-04-02 Palo Alto Networks, Inc. Network slice-based security in mobile networks
WO2020068521A1 (fr) * 2018-09-27 2020-04-02 Palo Alto Networks, Inc. Sécurité basée sur une tranche de réseau dans des réseaux mobiles
US10638356B2 (en) 2018-07-23 2020-04-28 Nokia Technologies Oy Transmission of network slicing constraints in 5G wireless networks
WO2020146328A1 (fr) * 2019-01-08 2020-07-16 Mavenir Networks, Inc. Procédé et appareil de sélection de ressource de plan utilisateur pour réseau central 5g
US10728826B2 (en) 2018-07-02 2020-07-28 At&T Intellectual Property I, L.P. Cell site routing based on latency
WO2020159731A1 (fr) * 2019-01-28 2020-08-06 Qualcomm Incorporated Indication de caractéristique étendue dans la norme new radio (nr)
US10785652B1 (en) 2019-09-11 2020-09-22 Cisco Technology, Inc. Secure remote access to a 5G private network through a private network slice
US10812972B2 (en) 2018-09-27 2020-10-20 Palo Alto Networks, Inc. Service-based security per user location in mobile networks
US10812971B2 (en) 2018-09-27 2020-10-20 Palo Alto Networks, Inc. Service-based security per data network name in mobile networks
CN111989979A (zh) * 2018-02-25 2020-11-24 诺基亚通信公司 控制通信网络的操作以减少等待时间的方法和系统
US10863333B2 (en) 2019-02-15 2020-12-08 Cisco Technology, Inc. Federated insertion of 3rd party software as a service for network slices
WO2021041143A1 (fr) * 2019-08-23 2021-03-04 Idac Holdings, Inc. Authentification et autorisation d'accès à un réseau par un véhicule aérien sans pilote
US11019077B2 (en) 2018-09-27 2021-05-25 Palo Alto Networks, Inc. Multi-access distributed edge security in mobile networks
US11039359B1 (en) 2019-11-19 2021-06-15 Sprint Communications Company L.P. Wireless communication device handovers between wireless communication network slices
EP3836506A1 (fr) * 2019-12-09 2021-06-16 Orange Fourniture de services de cybersécurité par un réseau et son approvisionnement automatique
CN113225759A (zh) * 2021-05-28 2021-08-06 广东电网有限责任公司广州供电局 一种面向于5g智能电网的网络切片安全与决策管理方法
US11108636B2 (en) 2019-10-23 2021-08-31 Cisco Technology, Inc. Integrity verification for managing network configurations
US20210281473A1 (en) * 2018-03-12 2021-09-09 Apple Inc. Management Services for 5G Networks and Network Functions
WO2021174439A1 (fr) * 2020-03-04 2021-09-10 Nokia Shanghai Bell Co., Ltd. Ressource d'allocation de tranche de réseau
WO2021225283A1 (fr) * 2020-05-07 2021-11-11 삼성전자 주식회사 Dispositif électronique formant une tranche de réseau et une session de données, et son procédé de fonctionnement
CN113973047A (zh) * 2020-07-24 2022-01-25 中移(苏州)软件技术有限公司 一种信息显示方法、装置、设备及存储介质
US11258830B2 (en) * 2020-06-10 2022-02-22 Charter Communications Operating, Llc Method and framework for internet of things network security
EP3925190A4 (fr) * 2019-03-22 2022-05-04 Huawei Technologies Co., Ltd. Procédé et appareil pour fournir un contexte de transport et des métadonnées en chemin pour la prise en charge de réseaux 5g
US20220150813A1 (en) * 2020-06-19 2022-05-12 Verizon Patent and Licencing Inc. Systems and methods for user-specific slice configuration for an application
US11382163B2 (en) 2017-12-19 2022-07-05 At&T Intellectual Property I, L.P. Instantiating intelligent service delivery parameters within protected hardware
TWI771928B (zh) * 2020-02-26 2022-07-21 新加坡商樂天交響新加坡股份有限公司 電腦系統及網路切片管理方法
WO2022187070A1 (fr) * 2021-03-01 2022-09-09 Secureg Courtier de confiance numérique et assurance de confiance de bout en bout dans des réseaux multidomaines, multiopérateurs et en nuage pour environnements de haute sécurité
WO2022240934A1 (fr) * 2021-05-12 2022-11-17 Tencent America LLC Procédés de mise en œuvre de divers scénarios de déploiement de diffusion en continu de liaison montante dans des réseaux 5g
US11533777B2 (en) 2018-06-29 2022-12-20 At&T Intellectual Property I, L.P. Cell site architecture that supports 5G and legacy protocols
US11575509B2 (en) * 2017-01-27 2023-02-07 Telefonaktiebolaget Lm Ericsson (Publ) Secondary authentication of a user equipment
GB2611317A (en) * 2021-09-29 2023-04-05 British Telecomm Methods and systems of operating software defined networks
GB2611318A (en) * 2021-09-29 2023-04-05 British Telecomm Methods and systems of operating software defined networks
US20230140966A1 (en) * 2021-11-08 2023-05-11 Verizon Patent And Licensing Inc. Systems and methods for tiered network slice design and management in a wireless network
WO2023118922A1 (fr) * 2021-12-22 2023-06-29 Fondation B-Com Procédé de conception d'une architecture d'un système électronique, procédé de réalisation de fonctions dans un système électronique et système électronique associé
WO2023122627A1 (fr) * 2021-12-20 2023-06-29 A10 Systems LLC Découpage de réseau intelligent et moteur de routage à base de règles

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140086177A1 (en) * 2012-09-27 2014-03-27 Interdigital Patent Holding, Inc. End-to-end architecture, api framework, discovery, and access in a virtualized network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140086177A1 (en) * 2012-09-27 2014-03-27 Interdigital Patent Holding, Inc. End-to-end architecture, api framework, discovery, and access in a virtualized network

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Architecture for Next Generation System (Release 14)", 3GPP STANDARD; 3GPP TR 23.799, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. V0.4.0, 27 April 2016 (2016-04-27), pages 1 - 92, XP051123441 *
CHINA UNICOM ET AL: "Security consideration on the network slicing", vol. SA WG3, no. San Jose Del Cabo, Mexico; 20160509 - 20160513, 8 May 2016 (2016-05-08), XP051099156, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/Docs/> [retrieved on 20160508] *
ETRI: "Solution for network function selection within a network slice", vol. SA WG2, no. SOPHIA ANTIPOLIS; 20160411 - 20160415, 5 April 2016 (2016-04-05), XP051086470, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_114_Sophia_Antipolis/Docs/> [retrieved on 20160405] *

Cited By (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11575509B2 (en) * 2017-01-27 2023-02-07 Telefonaktiebolaget Lm Ericsson (Publ) Secondary authentication of a user equipment
US11895229B2 (en) 2017-01-27 2024-02-06 Telefonaktiebolaget Lm Ericsson (Publ) States secondary authentication of a user equipment
US11284250B2 (en) 2017-06-16 2022-03-22 Telefonaktiebolaget Lm Ericsson (Publ) Network, network nodes, wireless communication devices and method therein for handling network slices in a wireless communication network
WO2018231125A1 (fr) * 2017-06-16 2018-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Réseau, nœuds de réseau, dispositifs de communication sans fil et procédé dans ceux-ci pour gérer des tranches de réseau dans un réseau de communication sans fil
US20190124544A1 (en) * 2017-10-24 2019-04-25 At&T Intellectual Property I, L.P. Systems and methods for on demand intelligent analytics dynamic access network slice switching and carrier aggregation
US10645608B2 (en) * 2017-10-24 2020-05-05 At&T Intellectual Property I, L.P. Systems and methods for on demand intelligent analytics dynamic access network slice switching and carrier aggregation
US20200245185A1 (en) * 2017-10-24 2020-07-30 At&T Intellectual Property I, L.P. Systems and methods for on demand intelligent analytics dynamic access network slice switching and carrier aggregation
US10939320B2 (en) 2017-10-24 2021-03-02 At&T Intellectual Property I, L.P. Systems and methods for on demand intelligent analytics dynamic access network slice switching and carrier aggregation
FR3074626A1 (fr) * 2017-12-01 2019-06-07 Orange Procede d'acheminement de donnees d'une session initialisee entre un terminal et un serveur
EP4132177A1 (fr) * 2017-12-01 2023-02-08 Orange Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur
CN111418186B (zh) * 2017-12-01 2023-06-09 奥兰治 用于路由终端与服务器之间初始化的会话的数据的方法
US11394787B2 (en) 2017-12-01 2022-07-19 Orange Method for routing data of a session initialized between a terminal and a server
CN111418186A (zh) * 2017-12-01 2020-07-14 奥兰治 用于路由终端与服务器之间初始化的会话的数据的方法
US11785095B2 (en) 2017-12-01 2023-10-10 Orange Method for routing data of a session initialized between a terminal and a server
WO2019106308A1 (fr) * 2017-12-01 2019-06-06 Orange Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur
WO2019114988A1 (fr) * 2017-12-15 2019-06-20 Nokia Technologies Oy Procédé de commande de transmission de données à l'aide de tranches de réseau
US20210084523A1 (en) * 2017-12-15 2021-03-18 Mokia Technologies Oy Method for controlling data transmission by using network slices
CN111527725A (zh) * 2017-12-15 2020-08-11 诺基亚技术有限公司 用于通过使用网络分片来控制数据传输的方法
US11382163B2 (en) 2017-12-19 2022-07-05 At&T Intellectual Property I, L.P. Instantiating intelligent service delivery parameters within protected hardware
EP3503492A1 (fr) * 2017-12-22 2019-06-26 Deutsche Telekom AG Techniques permettant d'établir une communication de données basée sur une identification d'utilisateur
WO2019120696A1 (fr) * 2017-12-22 2019-06-27 Deutsche Telekom Ag Techniques pour l'établissement d'une communication de données d'après une identification d'utilisateur
CN111989979A (zh) * 2018-02-25 2020-11-24 诺基亚通信公司 控制通信网络的操作以减少等待时间的方法和系统
US11848815B2 (en) * 2018-03-12 2023-12-19 Apple Inc. Management services for 5G networks and network functions
US20210281473A1 (en) * 2018-03-12 2021-09-09 Apple Inc. Management Services for 5G Networks and Network Functions
EP3777091A4 (fr) * 2018-04-06 2021-12-29 Nokia Technologies Oy Procédé et appareil de messagerie de fonction de réseau
US11652851B2 (en) 2018-04-06 2023-05-16 Nokia Technologies Oy Method and apparatus for network function messaging
WO2019193252A1 (fr) * 2018-04-06 2019-10-10 Nokia Technologies Oy Procédé et appareil de messagerie de fonction de réseau
CN110446233A (zh) * 2018-05-04 2019-11-12 华为技术有限公司 切换方法、设备及系统
CN110446233B (zh) * 2018-05-04 2021-06-01 华为技术有限公司 切换方法、设备及系统
US11659481B2 (en) 2018-05-26 2023-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for UE to request appropriate NSSAI in 5G
WO2019229492A1 (fr) * 2018-05-26 2019-12-05 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et systèmes de demande par un ue de nssai appropriées dans une 5g
US11533777B2 (en) 2018-06-29 2022-12-20 At&T Intellectual Property I, L.P. Cell site architecture that supports 5G and legacy protocols
US10728826B2 (en) 2018-07-02 2020-07-28 At&T Intellectual Property I, L.P. Cell site routing based on latency
US10638356B2 (en) 2018-07-23 2020-04-28 Nokia Technologies Oy Transmission of network slicing constraints in 5G wireless networks
US11539699B2 (en) 2018-08-13 2022-12-27 Lenovo (Singapore) Pte. Ltd. Network slice authentication
WO2020035732A1 (fr) * 2018-08-13 2020-02-20 Lenovo (Singapore) Pte. Ltd. Authentification de tranche de réseau
JP2022502913A (ja) * 2018-09-27 2022-01-11 パロ アルト ネットワークス, インコーポレイテッドPalo Alto Networks, Inc. モバイルネットワークにおけるネットワークスライスベースのセキュリティ
CN112868248A (zh) * 2018-09-27 2021-05-28 帕洛阿尔托网络公司 移动网络中基于网络切片的安全性
US10812971B2 (en) 2018-09-27 2020-10-20 Palo Alto Networks, Inc. Service-based security per data network name in mobile networks
US10812972B2 (en) 2018-09-27 2020-10-20 Palo Alto Networks, Inc. Service-based security per user location in mobile networks
JP7410343B2 (ja) 2018-09-27 2024-01-09 パロ アルト ネットワークス，インコーポレイテッド モバイルネットワークにおけるネットワークスライスベースのセキュリティ
JP7408859B2 (ja) 2018-09-27 2024-01-05 パロ アルト ネットワークス，インコーポレイテッド モバイルネットワークにおけるネットワークスライスベースのセキュリティ
US20200106812A1 (en) * 2018-09-27 2020-04-02 Palo Alto Networks, Inc. Network slice-based security in mobile networks
US11582264B2 (en) 2018-09-27 2023-02-14 Palo Alto Networks, Inc. Network slice-based security in mobile networks
US11792235B2 (en) 2018-09-27 2023-10-17 Palo Alto Networks, Inc. Network slice-based security in mobile networks
WO2020068521A1 (fr) * 2018-09-27 2020-04-02 Palo Alto Networks, Inc. Sécurité basée sur une tranche de réseau dans des réseaux mobiles
JP2023088904A (ja) * 2018-09-27 2023-06-27 パロ アルト ネットワークス，インコーポレイテッド モバイルネットワークにおけるネットワークスライスベースのセキュリティ
JP7233525B2 (ja) 2018-09-27 2023-03-06 パロ アルト ネットワークス，インコーポレイテッド モバイルネットワークにおけるネットワークスライスベースのセキュリティ
JP2023085250A (ja) * 2018-09-27 2023-06-20 パロ アルト ネットワークス，インコーポレイテッド モバイルネットワークにおけるネットワークスライスベースのセキュリティ
US10944796B2 (en) 2018-09-27 2021-03-09 Palo Alto Networks, Inc. Network slice-based security in mobile networks
US11019077B2 (en) 2018-09-27 2021-05-25 Palo Alto Networks, Inc. Multi-access distributed edge security in mobile networks
WO2020146328A1 (fr) * 2019-01-08 2020-07-16 Mavenir Networks, Inc. Procédé et appareil de sélection de ressource de plan utilisateur pour réseau central 5g
US11805059B2 (en) 2019-01-08 2023-10-31 Mavenir Networks, Inc. Method and apparatus for user plane resource selection for 5G core
WO2020159731A1 (fr) * 2019-01-28 2020-08-06 Qualcomm Incorporated Indication de caractéristique étendue dans la norme new radio (nr)
US11109305B2 (en) 2019-01-28 2021-08-31 Qualcomm Incorporated Extended feature indication in NR
US10863333B2 (en) 2019-02-15 2020-12-08 Cisco Technology, Inc. Federated insertion of 3rd party software as a service for network slices
CN109922540A (zh) * 2019-03-01 2019-06-21 展讯通信（上海）有限公司 无线收发设备组通信方法、设备组、系统及存储介质
EP3925190A4 (fr) * 2019-03-22 2022-05-04 Huawei Technologies Co., Ltd. Procédé et appareil pour fournir un contexte de transport et des métadonnées en chemin pour la prise en charge de réseaux 5g
WO2021041143A1 (fr) * 2019-08-23 2021-03-04 Idac Holdings, Inc. Authentification et autorisation d'accès à un réseau par un véhicule aérien sans pilote
US10785652B1 (en) 2019-09-11 2020-09-22 Cisco Technology, Inc. Secure remote access to a 5G private network through a private network slice
US11818007B2 (en) 2019-10-23 2023-11-14 Cisco Technology, Inc. Integrity verification for managing network configurations
US11108636B2 (en) 2019-10-23 2021-08-31 Cisco Technology, Inc. Integrity verification for managing network configurations
US11039359B1 (en) 2019-11-19 2021-06-15 Sprint Communications Company L.P. Wireless communication device handovers between wireless communication network slices
EP3836506A1 (fr) * 2019-12-09 2021-06-16 Orange Fourniture de services de cybersécurité par un réseau et son approvisionnement automatique
WO2021116033A1 (fr) * 2019-12-09 2021-06-17 Orange Fourniture de services de cybersécurité par un réseau et approvisionnement automatisé associé
TWI771928B (zh) * 2020-02-26 2022-07-21 新加坡商樂天交響新加坡股份有限公司 電腦系統及網路切片管理方法
CN115211159A (zh) * 2020-03-04 2022-10-18 上海诺基亚贝尔股份有限公司 网络切片的分配资源
WO2021174439A1 (fr) * 2020-03-04 2021-09-10 Nokia Shanghai Bell Co., Ltd. Ressource d'allocation de tranche de réseau
WO2021225283A1 (fr) * 2020-05-07 2021-11-11 삼성전자 주식회사 Dispositif électronique formant une tranche de réseau et une session de données, et son procédé de fonctionnement
US11258830B2 (en) * 2020-06-10 2022-02-22 Charter Communications Operating, Llc Method and framework for internet of things network security
US20220150813A1 (en) * 2020-06-19 2022-05-12 Verizon Patent and Licencing Inc. Systems and methods for user-specific slice configuration for an application
US11582689B2 (en) * 2020-06-19 2023-02-14 Verizon Patent And Licensing Inc. Systems and methods for user-specific slice configuration for an application
CN113973047B (zh) * 2020-07-24 2024-04-09 中移(苏州)软件技术有限公司 一种信息显示方法、装置、设备及存储介质
CN113973047A (zh) * 2020-07-24 2022-01-25 中移(苏州)软件技术有限公司 一种信息显示方法、装置、设备及存储介质
WO2022187070A1 (fr) * 2021-03-01 2022-09-09 Secureg Courtier de confiance numérique et assurance de confiance de bout en bout dans des réseaux multidomaines, multiopérateurs et en nuage pour environnements de haute sécurité
US11711401B2 (en) 2021-03-01 2023-07-25 Secureg Digital trust broker and end to end trust assurance in multi-domain, multi-operator and cloud networks for high security environments
WO2022240934A1 (fr) * 2021-05-12 2022-11-17 Tencent America LLC Procédés de mise en œuvre de divers scénarios de déploiement de diffusion en continu de liaison montante dans des réseaux 5g
CN113225759A (zh) * 2021-05-28 2021-08-06 广东电网有限责任公司广州供电局 一种面向于5g智能电网的网络切片安全与决策管理方法
WO2023052005A1 (fr) * 2021-09-29 2023-04-06 British Telecommunications Public Limited Company Procédés et systèmes d'exploitation de réseaux définis par logiciel
WO2023052006A1 (fr) * 2021-09-29 2023-04-06 British Telecommunications Public Limited Company Procédés et systèmes d'exploitation de réseaux définis par logiciel
GB2611318A (en) * 2021-09-29 2023-04-05 British Telecomm Methods and systems of operating software defined networks
GB2611318B (en) * 2021-09-29 2024-02-21 British Telecomm Methods and systems of operating software-defined networks
GB2611317A (en) * 2021-09-29 2023-04-05 British Telecomm Methods and systems of operating software defined networks
US20230140966A1 (en) * 2021-11-08 2023-05-11 Verizon Patent And Licensing Inc. Systems and methods for tiered network slice design and management in a wireless network
US11871318B2 (en) * 2021-11-08 2024-01-09 Verizon Patent And Licensing Inc. Systems and methods for tiered network slice design and management in a wireless network
US11812359B2 (en) 2021-12-20 2023-11-07 A10 Systems LLC Intelligent network slicing and policy-based routing engine
WO2023122627A1 (fr) * 2021-12-20 2023-06-29 A10 Systems LLC Découpage de réseau intelligent et moteur de routage à base de règles
WO2023118922A1 (fr) * 2021-12-22 2023-06-29 Fondation B-Com Procédé de conception d'une architecture d'un système électronique, procédé de réalisation de fonctions dans un système électronique et système électronique associé

Similar Documents

Publication Publication Date Title
WO2017200978A1 (fr) Sélection et attribution de tranches à base de sécurité
US11903048B2 (en) Connecting to virtualized mobile core networks
US11683087B2 (en) Cloud based access solution for enterprise deployment
US20230092015A1 (en) Securing communication of devices in the internet of things
US20220272620A1 (en) Apparatus, system and method for enhancements to network slicing and the policy framework of a 5g network
WO2018013925A1 (fr) Structure d&#39;autorisation adaptative pour réseaux de communication
Choyi et al. Network slice selection, assignment and routing within 5G networks
CN114173374A (zh) 多接入管理服务分组分类和优先级排定技术
WO2022020770A1 (fr) Gestion de charge de travail calculatoire dans des réseaux cellulaires de nouvelle génération
WO2018035431A1 (fr) Exposition de service de réseau pour une continuité de service et de session
WO2018232253A1 (fr) Fonction d&#39;exposition de réseau
US20240022952A1 (en) Resource Allocation in Non-Public Network
Singh et al. Unified heterogeneous networking design
US20240015630A1 (en) Routing Between Networks Based on Identifiers
US20240015569A1 (en) Quality of service management for 5g networks
US20230269580A1 (en) Securing Media Stream Communications
WO2023081276A1 (fr) Tranche de réseau pour l&#39;accès d&#39;un dispositif sans fil à un réseau

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17727040

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17727040

Country of ref document: EP

Kind code of ref document: A1