WO2017173259A1 - Procédés et fonction ngef pour la divulgation de services par tranche de réseau - Google Patents

Procédés et fonction ngef pour la divulgation de services par tranche de réseau Download PDF

Info

Publication number
WO2017173259A1
WO2017173259A1 PCT/US2017/025359 US2017025359W WO2017173259A1 WO 2017173259 A1 WO2017173259 A1 WO 2017173259A1 US 2017025359 W US2017025359 W US 2017025359W WO 2017173259 A1 WO2017173259 A1 WO 2017173259A1
Authority
WO
WIPO (PCT)
Prior art keywords
ngef
request
network
slice
wtru
Prior art date
Application number
PCT/US2017/025359
Other languages
English (en)
Inventor
Mahmoud Watfa
Guanzhou Wang
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 WO2017173259A1 publication Critical patent/WO2017173259A1/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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service

Definitions

  • a network slice may include, for example, a logical connection of functions residing in various nodes of a wireless communication system and may allow a user to obtain services or network capacity on a per service basis.
  • Network slicing has also been discussed in other groups such as Next Generation Mobile Networks (NGMN).
  • a system, method, and apparatus for service exposure with network slicing may include receiving a request from an application server (AS) to modify a network slice.
  • a network node or next generation exposure function (NGEF) may authorize the request based on parameters associated with the request.
  • the network node or NGEF may then send the authorized request to a database to be further authorized for characteristics associated with the network slice.
  • the network node or NGEF may then receive a response from the database.
  • the response may include an authorization, wherein the characteristics associated with the network slice include services of the network slice and a list of wireless transmit/receive units (WTRUs) authorized to access the network slice.
  • WTRUs wireless transmit/receive units
  • the network node or NGEF may then send a request to modify a network slice to a control plane (CP) node or network function (NF).
  • the network node or NGEF may then receive a result of the request to modify the network slice.
  • the result may include characteristics associated with the modified network slice.
  • the network node or NGEF may then send a network slice modification response to the AS indicating a result of the request.
  • An architecture is described for service exposure. This architecture may depend on configurations or deployments of network slices. Each network slice may have a specific exposure function (EXP FXN). The main exposure function may be the NGEF which may delegate requests to the EXP FXN.
  • One or more network components may have policies to determine which slices are necessary to expose a set of services.
  • the service type may be identified by as an external service ID (ESID) and it may map to one or more network slices that are identified by a network slice identification (NSID).
  • ESID external service ID
  • NSID network slice identification
  • the network may contact a network node to create or modify a slice based on a request from an AS.
  • the NGEF or another network node may determine the slice characteristics based on local policies, slice blueprints, and/or AS requirements.
  • the created slice may have its own local exposure function.
  • the NGEF may receive requests to expose one or more services.
  • the NGEF determines which slices are to be contacted for the service exposure. The determination may be based on local policies and/or subscription information. [0009] Services may be exposed by more than one slice, for example, an
  • NGEF may consolidate event reporting from different slices, send a consolidated report to the AS and indicate the service ID for this report or exposure.
  • a system, method, and apparatus for service exposure with network slicing may comprise receiving a request, from an apphcation server, to create or modify a network slice.
  • the request may include one or more first network slice parameters including: an application identifier (App ID), an external service ID, an indication of a service type or at least one target WTRU.
  • a target network slice may be determined based on the parameters of the received request.
  • the request may be forwarded, through a local NGEF, to a control plane network function (CP NF).
  • a response may be received, through the local NGEF, from the CP NF including network slice parameters.
  • a network slice modification response message may be sent to the apphcation server including a result of the received request and corresponding second network slice parameters.
  • the determination of the target network slice may be based on a mapping of the external service ID to a target network slice ID.
  • FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;
  • FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;
  • WTRU wireless transmit/receive unit
  • FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;
  • FIG. 2 is a diagram of an example system for network slice components;
  • FIG. 3 is a diagram of another example system for network slice components
  • FIG. 4 is a diagram of yet another example system for network slice components
  • FIG. 5 is a diagram of an example solution for network slicing
  • FIG. 6 is a diagram of an example solution for network selection
  • FIG. 7 is a diagram of an example solution for network slice selection
  • FIG. 8 is a diagram of an example architecture for service exposure in an Evolved Packet System (EPS).
  • EPS Evolved Packet System
  • FIG. 9 is a diagram of an example architecture for service exposure with network slices
  • FIG. 10 is a flowchart which illustrates a request processing method performed by an NGEF
  • FIG. 11 is an list of characteristics which may describe an exemplary network slice
  • FIG. 12A is a diagram of an example procedure for modifying, by an application server (AS), a network slice;
  • AS application server
  • FIG. 12B is a continuation of FIG. 12A;
  • FIG. 13 is a diagram of an example procedure for submitting a request for service exposure
  • FIG. 14 is a diagram of an example procedure for reporting a notification.
  • FIG. 15 is a flowchart of an exemplary method for exposing a number of WTRUs in an area.
  • FIG. 1A 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, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs 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
  • 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, the Internet 110, and/or the other 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.
  • BTS base transceiver station
  • AP access point
  • the base station 114a may be part of the RAN 104, 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. For example, 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 (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple -input multiple-output
  • the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 116 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the base station 114a in the RAN 104 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 116 using wideband CDMA (WCDMA).
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downhnk Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
  • the base station 114a and the WTRUs are identical to the base station 114a and the WTRUs.
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGERAN
  • the base station 114b in FIG. 1A may be a wireless router, Home
  • Node B, Home eNode B, or access point 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.
  • the RAN 104 may be in communication with the core network
  • the core network 106 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 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high- level security functions, such as user authentication.
  • the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT.
  • the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • the core network 106 may also serve as a gateway for the
  • 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.
  • TCP transmission control protocol
  • UDP user datagram protocol
  • IP internet protocol
  • the networks 112 may include wired or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 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. 1A 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 /touchp ad 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 processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • 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 116.
  • 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 116.
  • 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 /touchp ad 128 (e.g., a liquid crystal display (LCD) display unit or organic hght-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 /touchp ad 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 nonremovable 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 116 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
  • the peripherals 138 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.
  • 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.
  • FM frequency modulated
  • FIG. 1C is a system diagram of the RAN 104 and the core network 106 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 106.
  • the RAN 104 may include eNode-Bs 140a, 140b, 140c, 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 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 140a, 140b, 140c may implement MIMO technology.
  • the eNode-B 140a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 140a, 140b, 140c 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. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.
  • the core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. 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.
  • MME mobility management entity gateway
  • PDN packet data network
  • the MME 142 may be connected to each of the eNode-Bs 140a,
  • the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
  • the MME 142 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 144 may be connected to each of the eNode
  • the serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the serving gateway 144 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 144 may also be connected to the PDN gateway 146, 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 146 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 106 may facilitate communications with other networks.
  • the core network 106 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 106 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 106 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the core network 106 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.
  • WLAN 160 may include an access router 165.
  • the access router may contain gateway functionality.
  • the access router 165 may be in communication with a plurality of access points (APs) 170a, 170b.
  • the communication between access router 165 and APs 170a, 170b may be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol.
  • AP 170a is in wireless communication over an air interface with WTRU 102d.
  • each one of the associated FIGs may include a UE, STA, or other device configured to operate in a wireless communication system.
  • a network slice may include, for example, a logical collection of functions residing in various nodes of a wireless communication system that may allow a user to obtain services or network capacity on a per service basis.
  • control plane (CP) and user plane (UP) nodes are grouped per slice or across slices, the type of network functions that are run by these CP and UP nodes, how is a slice selected, for example, have been discussed in 3GPP.
  • some discussions involve the type of information that the RAN may use to select a network slice, for example using information provided by a WTRU or other inputs from CP nodes.
  • a network slice may have independent CP and UP nodes, or may share CP nodes but have independent UP nodes, or may share CP functions and have independent CP functions and UP nodes.
  • An access network may be consistently shared among slices regardless of any network slice method selected.
  • FIG. 2 shows an example network slice arrangement 200 with two CN instances 204, 206.
  • a WTRU 202 may obtain services from different network slices and different CN instances 204, 206. In this way, a logical separation or isolation between CN instances is achieved.
  • Group A has an independent subscription management/mobility management entity for each network slice handling the WTRU.
  • FIG. 3 shows an example network slice arrangement 300 with shared CN CP functions 302 and independent CP and UP instances 304, 306.
  • Group B provides for a common identity/subscription management and mobility management between network slices, while other functions such as the more session related aspects of the CP and UP reside in individual network shces.
  • FIG. 4 shows an example network slice 400 with shared CN CP functions 402 and independent UP instances 404, 406.
  • Group C assumes that control plane handling is shared in common between shces, while the user plane(s) are handled as different network slices.
  • An instance of a CP or UP may refer to all functionality required to perform CP or UP functionality. However, the term function as used herein may refer to a subset of, or portion of, a CP or UP.
  • FIG. 5 shows an example embodiment 500 for network slicing that has been discussed in 3GPP. It is modeled towards Option C as shown in FIG. 4, which may have a shared CP function but independent UP nodes and functions.
  • the discussed solution includes a Core Network Instance 502 that comprises of a single set of CP functions 504 and a single set of UP functions 506.
  • a Core Network Instance may be dedicated for the WTRUs that belong to the same WTRU type. Identifying the WTRU type is done by using a specific parameter, e.g., the WTRU Usage Type, and/or information from the WTRU's subscription.
  • a set of CP functions 504 may be responsible, for example, for supporting WTRU mobility if demanded or for admitting the WTRU 514 into the network by performing authentication and subscription verification.
  • a set of UP functions 506 in a Core Network Instance may be responsible for providing a specific service to the WTRU and for transporting the UP data of the specific service.
  • one set of UP functions 506 in Core Network Instance#l 502, as shown in FIG. 5 may provide an enhanced mobile broadband service to the WTRU, whereas another set of UP functions 508 in Core Network Instance#2 510 may provide a critical communication service to the WTRU.
  • a default Core Network Instance that matches to the WTRU Usage Type may be assigned to the WTRU.
  • Each WTRU 514 may have multiple UP connections to different sets of UP functions that are available via different Core Network Instances simultaneously.
  • a Core Network Selection Function (CNSF) 512 may be responsible for: (1) selecting which Core Network Instance 502, 510 to accommodate a WTRU 514 by taking into account the WTRU's subscription and the specific parameter, for example, the WTRU Usage Type parameter; (2) selecting which CP functions within the selected Core Network Instance that the Base Station should communicate with, for example, by using the specific parameter, WTRU Usage Type; (3) selecting which set of UP functions that a base station should establish the connection for transport UP data of different services. This selection of UP function is done by using the specific parameter, for example, WTRU Usage Type and Service Type. Information regarding first and second network slices may be stored 516 at a WTRU.
  • FIG. 6 shows an alternative solution proposal 600 for network slice components and selection that has been discussed in 3GPP.
  • the proposed solution includes a slice selection and routing function 602 that may be provided by a RAN, for example, similar to a NAS Node Selection Function. Alternatively, a CN provided function may perform the same task.
  • the slice selection and routing function 602 may route signaling to a CN instance 604- 612 based on WTRU provided 614 and any available CN provided information.
  • As all network instances of the PLMN 616 share radio access there may be a need for separating any access barring and (over)load control per slice. That may be accomplished comparable to separated access barring and (over)load control procedures provided per PLMN operator for network sharing. With that approach, there may be CN resources that cannot be fully separated, for example, transport network resources. Any RAN internal slicing or managing of shared RAN resources is for RAN WGs.
  • FIG. 7 illustrates another solution discussed in 3GPP, in which a
  • multi-dimensional descriptor is used for slice selection.
  • this proposed solution includes, a selection principle for enabling selection of an appropriate function to deliver a certain service within a class of functions designed for a certain use case.
  • selection criteria should enable selection of the proper network slice for a certain application and also the proper functional components within the network slice for a certain service requested by a WTRU 702-706 at any time.
  • An application running on the WTRU 702-706 may provide a multi-dimensional descriptor.
  • the multi-dimensional descriptor may contain at least the following: Application ID and Service Descriptor.
  • a service descriptor may identify an enhanced mobile broadband (eMBB) service, critical communication (CriC) service, or a massive mchine type communications (mMTC) service.
  • the network may use the multi-dimensional descriptor along with other information, for example, subscription information available in the network, to choose an appropriate network slice and network functions. This may be referred to as the multi-dimensional selection mechanism.
  • Network slice and function selection may use a two-step selection mechanism or may involve more than two steps.
  • the selection function in the RAN may use the application ID as part of the multidimensional descriptor to select the appropriate core network slice.
  • the selection function within the core network may use the service descriptor as part of the multi-dimensional descriptor, to select the appropriate network functions within the network slice.
  • Network slice and function selection may also use a one step selection mechanism.
  • the selection function within the RAN or the selection function in the core network may use the application ID and Service Descriptor (multi-dimensional descriptor) to select the appropriate network slice, network functions and may redirect a WTRU accordingly.
  • WTRU 1 702 is configured to be serviced by MMl 708, SMI 710, and PCI 712 of CN slice A 714.
  • WTRU 2 704 is configured to be serviced by MM3 716, SM3 718 and PC3 720 of CN slice B 722.
  • WTRU 3 706 is configured to be serviced by SM2 722 and PC2 724 of CN slice C 726.
  • the EPS system may support some level of service exposure via a network node that is called Service Capability Exposure Function (SCEF).
  • SCEF Service Capability Exposure Function
  • FIG. 8 shows a general architecture 800 of an SCEF 802.
  • the SCEF 802 may interact with more specific network functions or entities 804-810. For example, if an application server (AS) would like to be notified of the availability of a device, alternatively implying that the network is exposing a monitoring event, then the SCEF 802 may interact with an HSS directly, or indirectly with an MME via the HSS. Interaction with an application may be provided by one or more application programming interfaces (APIs) 812-818.
  • AS application server
  • APIs application programming interfaces
  • the EPS may support exposure for several services related to group based services, monitoring services and other services that are considered in 3GPP. Monitoring services that are exposed in EPS are described herein in detail.
  • the EPS system may expose several monitoring services as detailed in 3GPP TR 23.789. The following is a list of monitoring events that were concluded as part of the monitoring enhancement work in 3 GPP. Section 8.2 of 3 GPP TR 23.789 describes monitoring events as described herein.
  • a one-time roaming status or serving network of a WTRU may be considered to change infrequently and information required may be available at an HSS. It is recommended that the combined MME / Serving GPRS Support Node (SGSN) (MME/SGSN) + HSS solution of clause 6.3 of 3 GPP TR 23.789 is specified for this event. A change in the roaming status or serving network of a WTRU may be detected. When this change is detected, it is recommended that the combined MME/SGSN + HSS solution of clause 6.3 is specified.
  • SGSN Serving GPRS Support Node
  • a location of a WTRU may be determined by a network element or may be reported by the WTRU. For a one-time current location of WTRU, it is recommended that the combined MME/SGSN + HSS solution of clause 6.3 is specified for this event. If dynamic policy and charging control (PCC) is used for a given WTRU, and an SCEF is able to locate the Policy and Charging Rules Function (PCRF) serving this WTRU, for example an active IP Connectivity Access Network (IP-CAN) session exists, then based on operator preferences, existing mechanisms specified in TS 23.203 may be used for this event. It should be noted that the MME may require an appropriate configuration as in TS 23.401.
  • PCRF Policy and Charging Rules Function
  • the combined MME/SGSN + HSS solution of clause 6.3 is specified for this event. If dynamic PCC is used for a given WTRU, and SCEF is able to locate the PCRF serving this WTRU (i.e. active IP-CAN session exist), then based on operator preferences, existing mechanisms specified in TS 23.203 may be used for this event. It should be noted that MME may require appropriate configuration (see TS 23.401). Upon determining a change of a location area, a report may be created. It is recommended that the combined MME/SGSN + HSS solution (clause 6.3) is specified for this event. A continuous reporting of location may be performed. It is recommended that the combined MME/SGSN + HSS solution (clause 6.3) is specified for this event.
  • An association between an MTC Device and a UICC may be changed.
  • the combined MME/SGSN + HSS solution of clause 6.3 is specified.
  • For a loss of connectivity it is recommended that combined MME/SGSN + HSS solution of clause 6.3 is specified for this event. It is recommended that the combined MME/SGSN + HSS solution of clause 6.3 is specified for WTRU reachability. It is recommended that the combined MME/SGSN + HSS solution of clause 6.3 is specified for communication failure. This event is limited to reporting of RAN/NAS failure cause code values. If dynamic PCC is used for a given WTRU, and an SCEF is able to locate the PCRF serving this WTRU, i.e.
  • RAN/NAS Release Cause is only sent by the MME to the PDN GW if this is permitted according to MME operator's policy as in TS 23.401, clause 5.4.4.2.
  • a number of WTRUs present in a certain area may be reported.
  • This event may be limited to one time reporting of the number of WTRUs present in a certain area. For one time reporting it is recommended that the combined MME/SGSN + HSS solution of clause 6.3 is specified for this event.
  • This event request may be sent directly to the serving node(s) by the SCEF. Serving nodes may report the event directly to SCEF. The exact methods that are used to expose these events may be found in 3GPP TR 23.789.
  • a network may be composed of several slices, with some functions shared, or not shared, across slices.
  • the function that exposes services may need to be determined, especially with respect to whether or not it is shared, or whether some of the functions are shared across some slices and if slices may have isolated/independent exposure functions.
  • the current EPS exposes a set of services via the SCEF.
  • the manner in which the SCEF interacts with the particular network entity may depend on the service that is being exposed.
  • the EPS system may have a known architecture and hence the network nodes with which interactions are needed for service exposure may be defined.
  • 5G systems may have a completely different architecture, especially with control plane (CP) and user plane (UP) separation, the network node and the method to expose the same service may be different in a 5G system than in the EPS system.
  • CP control plane
  • UP user plane
  • An Application Server may be allowed to modify a network slice.
  • AS Application Server
  • the methods and apparatuses described herein provide methods and systems which address this requirement.
  • 3GPP is studying creating a network slice based on the requirement of the 3rd party or customized network function on-demand.
  • modify a network slice may mean any of the following: create a network slice, modify a network slice, or release a network slice.
  • a network slice may refer to one or more network functions or control plane functions. Modifying a network slice may include adding or deleting a CP function or a UP function in the core network instance.
  • Methods are provided for ensuring that current services are exposed. Additionally, methods to expose current functions are described herein. Methods which address how the current services may be exposed in the context of network slicing should be defined. For example, to ascertain a number of WTRUs in a certain location, the request from the AS may be related to a particular service type and hence a particular slice. Alternatively, the request may be for all WTRUs regardless of the service type and hence slice, which means that all slices would be impacted by this request.
  • a WTRU may have access to two or more slices and may also have a data session with one or more ASs.
  • an AS requests the exposure of a particular service
  • for a WTRU that may have access to 2 or more slices it may be necessary to determine which of the 2 slices (which may include both slices) should be contacted for exposing this service. For example, assuming that the WTRU accesses two slices over which it contacts two servers ASl and AS2. These servers may be only accessed over specific slices, e.g. slice 1 and slice 2, respectively.
  • ASl requests to be notified when the WTRU is reachable, then a determination should be made as to whether ASl is notified if the WTRU contacts slice 2.
  • FIG. 9 shows an example architecture 900 for service exposure in a network that supports slicing, which may be used in or in combination with any of the embodiments described herein. The following description described an overview of nodes shown in FIG. 9.
  • a Next Generation Exposure Function (NGEF) 902 may be similar to an SCEF of EPS. However, the NGEF 902 may perform new functions and may connect to CP nodes directly, using either a shared 904 or non-shared CP function 906-910. The non-shared CP function nodes may be within a particular slice. The NGEF may connect to a database system such as an HSS.
  • An Exposure Function (EXP FXN) 912-916 may be specific to a particular network slice and may connect to a shared CP node.
  • the EXP FXN may also connect, directly or indirectly (via a shared CP node) to the NGEF.
  • the EXP FXN may in turn connect to a non-shared CP node within the slice.
  • an EXP FXN may connect to an HSS and although this is only shown for EXP FXN 1 912, it may apply to all other EXP FXNs per slice.
  • the EXP FXN may also connect directly to an AS as shown for EXP FXN 3 916. This may also apply to all other EXP FXNs. It should be noted that the EXP FXN may not be available altogether.
  • a Shared CP 904 may refer to a set of CP functions that may be shared by different network slices.
  • the shared CP function or node 904 may connect directly to the NGEF 902 and may also connect directly to an EXP FXN 912-916 or to a non-shared CP node 906-910 either directly or indirectly via an EXP FXN 912-916.
  • the shared CP node may connect directly to the AS.
  • a non-shared CP function or node 906-910 may refer to a set of
  • a non-shared CP may connect directly to a shared CP function or node, to an EXP FXN 912-916, or to an NGE 902.
  • a non-shared CP function or node may connect to a database such as the HSS. This may apply to all non-shared CP nodes although FIG. 9 only depicts the non-shared CPl. It should be noted that a slice may not necessarily contain a non-shared CP function.
  • a main NGEF may be sufficient to expose services for at least one slice.
  • each slice may have its own local NGEF, referred to as an EXP FXN.
  • NGEFs is deployed, the following functions may be performed by the NGEF as a first step for service exposure.
  • FIG. 10 is a flowchart which illustrates a request processing method 1000 performed by an NGEF.
  • the NGEF may maintain a mapping between an external network or service ID 1002, hereinafter referred to as an external service ID (ESID) and an internal network slice identification (NSID).
  • ESID may be of any form such as a number or a service identifier or descriptor.
  • the NGEF may be configured with local mappings that enable it to determine which slice, based on the ESID, a request is for.
  • a request received 1004 from an AS may be applicable to more than one (including all) slices and the request from the AS may provide a list of ESIDs or an ESID may be omitted altogether. Alternatively, the request may include a target ESID to "all". Thus, a request that is received 1004 at the NGEF may be applicable to more than on NSID. The request may also include additional parameters which may need to be reviewed 1006.
  • One parameter may include a list of device IDs for which the request is sent, from the AS.
  • the NGEF may determine 1008 which slice(s), for example, the NSID that may serve the identified WTRUs.
  • the NGEF may use a local mapping to make such a determination.
  • mappings proposed above may also use other parameters such as an application ID.
  • the AS may provide an ⁇ ESID, application ID, Device ID ⁇ and the NGEF may use its mapping information to retrieve a NSID or WTRU ID, or ⁇ NSID, WTRU ID ⁇ based on the received information and local mapping.
  • the NGEF may contact a database function and provide the received information for which the request is submitted, for example, ⁇ ESID, application ID, Device ID ⁇ .
  • the database function e.g. an HSS, may provide the NSID and/or a list of WTRU ID.
  • an NSID may refer to any of the following: an address of the control plane (CP) function that is responsible to provide the service that is requested; the address of the CP function may be the address of the node that hosts a shared CP function, or a node that hosts a non-shared CP function; the CP function may be any network function (NF) or any node that hosts one or more network functions (NFs); an address of a user plane (UP) function that is responsible to provide the service that is requested.
  • CP control plane
  • CP function may be the address of the node that hosts a shared CP function, or a node that hosts a non-shared CP function
  • the CP function may be any network function (NF) or any node that hosts one or more network functions (NFs)
  • UP user plane
  • the NGEF may directly contact 1010 the
  • CP or UP functions that may assist in the exposure of a service. For example, if the service to be exposed is detection of WTRU reachability, then a CP node or NF, which the WTRU contacts e.g. when transitioning from idle to connected mode, may send a report to the service exposure entity that in turn may send this indication to the AS.
  • the NGEF may be the only exposure entity in the network that receives the requests from the AS, performs authorization, and contacts the necessary CP of NFs in the network or slice so that the service may be exposed accordingly.
  • the NGEF may only perform a subset of the functions required for exposing services and may delegate the rest 1012 to the EXP FXNs as a form of hierarchical service exposure.
  • the NGEF may only perform authorization of a request from an AS, determine the NSID as in element 1008, and contact the EXP FXN associated with that NSID.
  • the NGEF may also forward a list of WTRU IDs for which the request is needed, and the address of the AS that submitted the request.
  • the EXP FXN may in turn contact the appropriate CP nodes or NFs in the network and send the WTRU ID for which a particular service may be exposed.
  • the EXP FXN may directly contact the AS using the address provided by the NGEF.
  • the EXP FXN may then send a response, which is received 1014 by the NGEF.
  • a WTRU is reachable for mobile terminated (MT) data, that may be reported when a WTRU makes contact with any slice with which it is registered or allowed to obtain services.
  • MT mobile terminated
  • the WTRU/user, or the network, or both may have preferences such that events on one slice may not be reported to other slices.
  • a WTRU may have two sessions with one or more
  • the WTRU sessions or services may be different in nature. As such, these services or sessions may be running on different network slices.
  • An AS hosting a particular service or session may request a notification when the WTRU is available for that service or session, which is running on a slice NSID 1. If the WTRU is then reachable on slice NSID 2, then, although the WTRU may be reachable by NSID 1, the policies of the network may be such that events and/or reports across slices may remain isolated and not exchanged across NSID 1 and NSID 2. Alternatively, the WTRU/user, or network, or both WTRU/user and network may not have such restrictions.
  • either the HSS, the NGEF and/or the EXP FXN may verify the policy with respect to inter-slice event reporting. If no restriction is available, the database and/or the NGEF may submit a "reachability notification" request on all the slices that the WTRU is accessing. It should be noted that such restrictions may be in place on a per WTRU basis, and/or per application or per service type basis.
  • a network operator may expose a service which may give the AS or 3 rd party service providers, hereafter referred to as an AS, the ability to dynamically request the creation of at least one network slice with certain characteristics.
  • AS may use an exposure function like the disclosed NGEF.
  • the AS may include the following parameters in the request, which are in general referred to as the network slice characteristics or service characteristics including a type of service that the slice will run, for example services for machine communication, critical communication, or the like.
  • Another service characteristics includes an identifier of the network slice for, example, an ESID.
  • FIG. 11 illustrates characteristics 1100 of an exemplary network slice.
  • Characteristics 1100 may include, but are not limited to, the following: the type of services/connections 1102 and 1104 that may be desired to be provided by the slice, for example, IP services, non-IP transfer service and if applicable the exact type of non-IP data, whether or not data may be sent over the control plane; QoS requirements of the network slice 1106, which may include the QoS parameters and the values required for the operation of the slice e.g. latency requirements, priority of data transfer, etc.; and security requirements 1108 for example, whether encryption and integrity protection may be required for CP, UP or both, and whether specific security parameters are to be used for certain applications.
  • Another characteristic of a network slice may include an indication or determination of whether or not a separate exposure function is required for the slice 1110. It should be noted that this exposure function may be specific to the created slice so that the ASs may contact this local exposure function, for example, the NGEF that is specific to this slice, to have a service exposed. However, to request the modification of the slice itself, the AS may either contact the local NGEF or the main NGEF of the network which was initially contacted to create this slice in the first place.
  • the NGEF that is specific to the slice that is created as per request from the AS is referred to as a Local NGEF (LNGEF).
  • LNGEF Local NGEF
  • Other characteristics may include a list of (external) device identities 1112 that may be allowed to use a particular slice, including the information that the WTRU should provide to the RAN for selection of this slice; whether or not the slice may be modified 1114, e.g. resource increases, other functions deployed, etc; a time for which the slice is to be used and after it may be released 1116; or other specific parameters for the operation of a network, which may include, but are not limited to a periodic registration timer for a WTRU 1116; required mobility levels that should be supported e.g.
  • a power savings type may be choosen from either extended discontinuous reception (eDRX), Power Saving Mode (PSM) or both. This may also include the parameters that may be relevant for the operation of a particular power saving mode e.g. the active time for PSM, or the discontinuous reception (DRX) timer for eDRX, etc.
  • Other parameters may include a list of application IDs and/or AS
  • IDs 1120 that may be allowed to contact the NGEF that are specific to a particular slice; the type of services that should be exposed by this slice, for example, the list of monitoring events, the list of group messaging services, for example, MBMS, SMS, etc; the layers and solutions for congestion control, for example, support for access barring, support or no support for backoff mechanisms and the layers (e.g. radio vs higher layer) where this is supported; the type of transport that is supported in the CN e.g. GTP or other tunnels; support for SDN or not and the type of routing protocols to use in general; the type of RAT that may be associated with the slice e.g. E-UTRAN, new 5G RAT, WiFi, etc. Also, whether or not other technologies including fixed access may be used.
  • IMS voice a characteristic for indication
  • the AS may indicate a priority level for some of the characteristics.
  • the AS may request a creation of a slice such that the service requirements indicate that very small delays and a particular QoS are required.
  • one of these service requirements in this example, may state that the service requirements are "very small delays” and a "particular QoS" has a higher priority over the other.
  • the network may choose the service requirements with the higher priority. That is, amongst a set of indicated service requirements or characteristics, the network may prioritize certain requirements, for example, based on local pohcies per application ID or AS ID, etc., and may create the slice with the chosen characteristics.
  • the NGEF may use local information to authorize the request per AS ID, application ID or the like, or it may contact a database for authorization and the NGEF should provide the characteristics of the required shce either including the detailed description or a slice blue print.
  • the database may authorize the request and provide an address of the NF that is responsible to process the request.
  • the NGEF may receive a message from a database, indicating a response to create a shce (with a certain characteristic) and may also receive the address of the NF that should be contacted. The NGEF should then contact the NF as indicated from a database or from local information. The NGEF may send a request to the NF for the creation of a network shce.
  • the term "creation” may be used as an example of an action to take, however, it may also be mean modification, e.g. an expansion or reduction in any resource or function that is physical or virtual, or a termination/release of a network shce, or network slice resources and/or functions.
  • the NGEF may provide a final list of characteristics and/or a slice blue print as determined previously.
  • a NF may receive a request to create a slice using a set of characteristics or a slice blueprint.
  • the term "blueprint” may refer to a blueprint with a set of well-known characteristics or a list of characteristics.
  • the NF may use local pohcies to determine the final blueprint which is used to create the slice.
  • the NF may create the slice and may respond to the NGEF.
  • the NF may indicate, for example, in the response message, the status of the creation request, and if accepted the NF may indicate the blueprint according to which the slice is created.
  • the NGEF may receive an indication or a message, for example from an NF, with an indication about the status of a request to create a network slice.
  • the NGEF may also receive the blueprint according to which the slice was created.
  • the NGEF may acknowledge the indication, for example by sending an acknowledgement message to an NF.
  • the NGEF may then send a message to the AS to indicate the status of the request for a network slice creation and the characteristics with which it was created.
  • the LNGEF may take any of the actions that have been disclosed for the NGEF above.
  • the NF may create an LNGEF with the characteristics or a blueprint. For example, only a certain list of WTRUs may access the slice.
  • the AS may be allowed and may have the means to change any of the characteristics and/or WTRUs that access the slice by either communicating with the NGEF or the LNGEF.
  • the LNGEF may perform local authorization for the requests that come from the well-known application ID or AS ID, as part of the requested characteristics that the AS may provide to the NGEF, using the characteristic information it received from an NGEF.
  • the AS or a set of ASs may contact the
  • the AS may contact the NGEF and may provide the updates characteristics.
  • the NGEF may take again the actions described above to modify the slice.
  • the (L)NGEF may be notified about a slice being out of operation.
  • the (L)NGEF may contact the AS to indicate that the slice itself is not operating and may indicate a time after which operation may be resumed.
  • FIGs. 12A and 12B An overall procedure 1200 is shown in FIGs. 12A and 12B, which may be used in or in combination with any of the embodiments described herein.
  • the NGEF 1208 or LNGEF 1204 may also delegate the slice creation request to the network slice manager or orchestrator.
  • the NGEF 1208 may translate aforementioned information in the request to a network slice blueprint which may be used by the network slice manager or orchestrator to create a proper slice.
  • the (L)NGEF may be pre-configured with a set of network slice templates or blueprints, with each template/blueprint catering to a specific potential service requirement. For example, there may be a slice blueprint for ultra-low latency services configured in the NGEF.
  • the NGEF may select that slice blueprint. After a slice blueprint is selected, it may pass the blueprint to the network service manager or orchestrator for the instantiation of the new network slice. The mapping between the application requirements and available slice blueprints may not be exact. If no appropriate network slice blueprint can be located for the application request, the NGEF may reject the application request. Alternatively or in combination, the NGEF may propose to use a blueprint which may compromise some of the application's requirements or may be the closest or most similar to what is been requested (as per network operator policies).
  • the AS 1210 may send a request 1212, to the NGEF 1208, for modification (i.e., creation, modification e.g. add new FN, add resources, etc., or release) of a network slice.
  • the AS may indicate the required service characteristics of the slice.
  • the AS 1210 may also provide other information including but not limited to:
  • the AS may also provide a parameter that will be used by the WTRUs to reference this network slice.
  • the parameter may be the "WTRU Usage Type", or "Dedicated Core Network Type”, etc., which may be used by the RAN to select this network slice.
  • the NGEF may authorize the request 1214 and may verify if the parameters (any of those proposed above) are allowed for this request and, for example, for this AS and/or WTRUs.
  • An ACK 1216 may be sent back to AS with an indication of a success of failure of authorization request 1214.
  • the NGEF may send the request 1218 to a database 1206, e.g. an
  • the NGEF may further request authorization for the particular characteristics that is received.
  • the database node 1206 may authorize the request 1220 and may, for example, determine that different network shce characteristics or blueprint is allowed for the AS.
  • the database may also determine the list of WTRUs that are allowed to access this shce and also the parameters that these WTRUs may provide to the RAN for selecting a slice.
  • the database may also determine the address of the NF or CP or NSID to which this request should be sent.
  • the database may respond 1222 to the NGEF 1208 and may provide any of the parameters that have been determined in the previous step as described in the paragraph above.
  • the NGEF may determine the address of the NF or CP or NSID to which this request may be sent.
  • the NGEF may also determine different network slice characteristics or it may set the characteristics to those received from the database.
  • the NGEF may determine the characteristics based on the priority associated with the specific parameters in the characteristics.
  • a database node may determine the characteristics. As explained earlier, the QoS requirement for the shce may have more importance than handover support, etc.
  • the NGEF 1210 may send a request 1224 to modify a network slice.
  • the NGEF 1210 may include in the request 1224 characteristics of the slice, for example, the ESID, a list of WTRUs, etc.
  • the request 1224 to modify a network slice may be sent to EXP FXN 1 1204 and may be forwarded to the CP in NS1 1202.
  • the NF or CP node 1202 may modify, for example create, the slice accordingly 1226.
  • the node may provide to the RAN the parameter value that is used for selection of this slice e.g. the DCN Type, "WTRU Usage Type" or other parameter that is received (optionally from the NGEF) and that may be provided by the WTRU to the RAN for the purpose of slice selection.
  • This node may modify the slice according to local policies such that the characteristics may be different from the required received characteristics.
  • a LNGEF 1228 may also be created for this slice if requested and if permitted by the local policies.
  • the NF or CP 1202 may respond 1230 to the NGEF 1208 and may indicate the result of the request.
  • the NF or CP may also indicate the characteristics associated with the modified network slice.
  • the NF or CP may also indicate the address of the LNGEF that is associated with this slice.
  • the NGEF 1208 may save 1232 the context for this slice, for example, the ESID, NSID, slice characteristics, WTRU IDs that are allowed on this slice, or the like.
  • the NGEF may send a network slice modification response 1234 to the AS 1210 and may indicate the result of the request.
  • the NGEF may also indicate the characteristics with which the slice is created and the address of the LNGEF.
  • the NGEF may also indicate whether or not the AS should contact the NGEF or the LNGEF for particular services. For example, the NGEF may indicate that the AS should contact the LNGEF for service exposure.
  • the NGEF may list the services that are allowed to be exposed by this LNGEF.
  • the NGEF may also indicate if the NGEF should be used by the AS for exposure of certain services.
  • the NGEF may also indicate if the AS may contact the NGEF for other modification requests related to this network slice, for example, per ESID.
  • the AS 1210 may contact the LNGEF 1228 to request a service exposure 1236 for a list of allowed services, for example, as indicated by the NGEF.
  • the LNGEF 1228 may submit a request for service exposure. It should be noted that the interaction between the AS 1210 and the LNGEF 1228 may be the same like the interaction between the AS 1210 and the NGEF 1208 as is described herein.
  • An ACK 1238 may be sent from LNGEF 1228 to AS 1210.
  • the AS 1210 may contact the NGEF 1228 for other modifications
  • the NGEF 1208 may take any of the actions previously described above, for example, for authorization.
  • the NGEF 1208 may send the request 1242 to the LNGEF 1228 to modify the network slice
  • the NGEF may also send this request to the CP or NF that is responsible for modifying the network slice, for example, to the same CP or NF that processed the previous modification request.
  • the NGEF may save the address of the CP or NF or NSID that previously processed the initial request.
  • the same actions that may be taken by the CP or NF function when the previous request was received may also be taken again by this node.
  • the LNGEF may receive the request 1242 to modify a network slice.
  • the LNGEF may contact a database, not shown, to get the address of the CP or NF that may process this request.
  • the LNGEF may also be configured with the address of the CP or NF node that may process this request.
  • the LNGEF may send the modification request to the determined node.
  • the NF or CP may respond 1244 with the result after the modification request is processed.
  • the LNGEF may respond to the NGEF about the result of the request.
  • the NGEF 1208 may respond to the AS 1210 and may provide the results of the modification request and may include any of the characteristics that have been modified and includes the new values related to these parameters.
  • Embodiments for exposing existing services in a 5G system are described herein. Embodiments are described with reference to exposing monitoring events as primary services, however the embodiments disclosed may also apply to other services.
  • FIG. 13 shows a configuration or submission of a request 1300, which may be used in or in combination with any of the embodiments described herein. The following is a description of the example procedure of FIG. 13.
  • An AS 1302 may contact an NGEF 1304 and may request 1316 a service exposure, for example, monitoring an event, and may include at least one ESID, a list of device IDs (optionally per ESID), application ID (optionally per ESID), service type/ID, amongst other parameters that may also be included.
  • the NGEF 1304 may authorize 1318 the request using local authorization information and policies. It may verify 1320 whether the AS is allowed to submit this request, for example for the identified devices, for the identified ESID, etc.
  • the NGEF may be configured with policies that indicate if an event, for example for a particular AS or service type or ESID, may be configured in one network slice only or it may be configured in multiple slices. For example, the policies may indicate that a WTRU's reachability notifications for a particular AS may be obtained from, and hence may be configured in, more than one slice in which the WTRU is accessing.
  • An acknowledgement response 1322 may be sent by NGEF 1304 to AS 1302.
  • the NGEF 1304 may contact a database, e.g. an HSS 1306, and may provide a list of device ID (these may be external device IDs), AS ID, ESID, service ID/type, etc 1324.
  • the NGEF may also indicate the NSID if available, e.g. from a mapping function.
  • the database 1306 may verify 1326 if the request may be allowed, for example for the identified devices, for the identified ESID, etc.
  • the database may perform a mapping from external device ID to internal WTRU ID.
  • the database may determine the list NSID that may be affected by, for example, need to be contacted by, the request and hence may determine the addresses corresponding to each NSID. It should be noted that the address may be that of a CP function or at least one NF.
  • the database may be configured with policies that indicate if an event, for example, for a particular AS or service type or ESID, may be configured in one network slice only or it may configured in multiple slices.
  • the policies may indicate that a WTRU's reachability notifications for a particular AS may be obtained from, and hence may be configured in, more than one slice in which the WTRU is accessing.
  • the database may also be configured with policies related to whether or not the request should be submitted directly to the CP or NFs or to an EXP FXN.
  • the database e.g. HSS 1306, may respond 1328 to the NGEF
  • NGEF 1304 may provide a list of NSID, a list of WTRU ID for example per NSID, an indicator of whether or not an service (e.g. a monitoring event) may be obtained from only one NSID, or from more.
  • the database also may provide a list of NSID addresses.
  • the database e.g. HSS, may also indicate for which event or NSID or a list of WTRUs, etc., that the NGEF may need to submit the request 1330 to an EXP FXN 1308, or alternatively to a CP or NF directly. If an EXP FXN 1308 is used, the addresses for the EXP FXNs may also be included.
  • NGEF 1304 may submit a request 1340 to EXP FXN 2 1310, which may then forward the request 1342 to CP/NF in NS2 1314.
  • the NGEF 1304 may use the received addresses, for example, from the database, or the addresses determined using local policies/information, of the NSID or CP or NFs that need to be contacted for the request.
  • the NGEF 1304 may also determine to contact an EXP FXN if the local policies indicate so or if an EXP FXN address is received from the database.
  • the NGEF 1304 may contact at least one EXP FXN or CP node, which may also be a node hosting a NF, and may indicate the list of WTRU IDs, AS ID, service ID/type, AS address.
  • the NGEF may also provide to the EXP FXN a mapping between a NSDI to ESID.
  • EXP FXN may take all of the actions above and contact 1332 at least one CP node or NFs 1312.
  • EXP FXN 1 1308 may store a mapping between an internal WTRU ID and an external device ID, and the address of an AS to which a message, for example a notification report, should be sent for a service exposure.
  • the EXP FXN may have (locally or received from another node e.g. NGEF or a database) a mapping from. It should be noted that the NGEF may perform the action above towards more than one CP/NF node and/or EXP FXN node.
  • the NGEF 1304 may contact EXP FXN 1 1308 and EXP FXN 2 1310, and/or CP/NF 1 1312 and/or CP/NF 2 1314.
  • the CP node 1312 may receive the request and may save the parameters needed for this service 1334, e.g. the AS ID and/or address, the actual service to provide, for example, monitoring WTRU reachability, etc.
  • CP node 1314 may perform the same function 1344 and respond 1346 to EXP FXN 2 1310.
  • EXP FXN 2 1310 may forward response 1348 toward NGEF 1304.
  • the CP node may acknowledge the request 1336 towards the
  • EXP FXN 1308 and/or the NGEF 1304.
  • the EXP FXN 1308 may acknowledge the request 1338 towards the NGEF 1304.
  • FIG. 14 illustrates reporting a notification for exposure of a service 1400, which may be used in or in combination with any of the embodiments described herein.
  • sending a notification, for example, to expose a monitoring event or service, from the network to the AS is described herein.
  • the embodiment is explained with one CP/NF as an example, but it may apply to all other CP/NF nodes in the system.
  • a CP/NF node 1404 may detect a condition or event 1416 for which a reporting is needed.
  • the node may send a notification report 1418 to the entity that may be notified, e.g. the EXP FXN 1408 or the NGEF 1412, using the address that is stored locally.
  • the notification may include a hst of WTRU IDs, App ID, NSID, etc.
  • the EXP FXN may receive a report 1418 from a CP/NF node
  • the EXP FXN may use local information to send the report 1420 to a next node 1412.
  • the next node may be an AS 1414 or an NGEF 1412.
  • the EXP FXN may perform a mapping 1422 from an internal WTRU ID to an external device ID and also from NSID to ESID, etc.
  • the EXP FXN may use local configuration to determine which node to send the notification report message 1424 to. This may be per request (as indicated in the previously received configuration) or per App ID, or ESID, etc.
  • the EXP FXN may send the notification to the determined node using the determined address.
  • the NGEF may receive a notification message about a service that should be exposed to an AS.
  • the notification may be about the WTRU reachability i.e. to notify the AS that the WTRU has made contact or has established a connection with one of the CP or NFs in the network.
  • the NGEF may map the NSID from which this notification is received to an ESID.
  • the NGEF may also map the internal WTRU ID to an external device ID.
  • the NGEF may send a notification report message to the AS.
  • the NGEF may verify if another related exposure service request was submitted towards another CP or NF in another slice.
  • the NGEF may contain a mapping between a request and the target NSID (and for example, other parameters such as ⁇ NSID, WTRU ID, service ID/type, etc. ⁇ ).
  • the NGEF may determine that the same configuration or request was submitted to another network slice and that it is no longer needed as only one report is required. Based on this determination, the NGEF may send a request to the target NSID (that is not the entity from which the given notification report has been received) to cancel the service or event reporting.
  • the target node to which this cancellation request 1426 is sent may be an EXP FXN 1406.
  • the action 1428 may also be performed by an EXP FXN towards a CP or NF 1402. This embodiment above may also be performed by a database node, e.g. HSS 1410.
  • a CP or NF 1402 may delete the request 1430.
  • the CP or NF 1402 may send a cancelation acknowledgement 1432 to EXP FXN 2 1406.
  • EXP FXN 2 1406 may forward cancelation acknowledgement 1434 to NGEF 1412.
  • a database node may also take any of the actions above, for example, the embodiments disclosed may be applicable to a database node as well.
  • CP function may take the role of the EXP FXN described above.
  • FIG. 15 is a flowchart which illustrates an exemplary method for exposing a number of WTRUs in an area 1500.
  • the current EPS system may expose a service, specifically the "number of WTRUs in an area" 1502, which may help an AS to determine how many WTRUs are registered in an area.
  • a request from an AS for such service exposure may lead to inaccurate responses from the network if the AS is targeting a particular set of WTRUs or WTRUs that use a specific service type.
  • an AS that provides health related services to smartphone users may not be interested to know about the number of WTRUs that run machine-type communications or applications, for example, water meters.
  • the may AS provide a list of service types when requesting any service to be exposed, especially when requesting the number of WTRUs in an area.
  • the service type may be an ESID as disclosed.
  • an NGEF When an NGEF receives a request to expose a service 1504, where the request contains a service type or a list of service types or ESID for which this request is valid, the NGEF may use a local mapping function 1506 or table to determine network slices that should be contacted for this request. The determination may also be done based on the application ID or the AS ID. Alternatively, the NGEF may verify with a database 1508 to determine the set of network slices to which this request should be sent. The embodiments disclosed above regarding how the service exposure request is submitted and reported back by the NGEF may apply here as well.
  • NGEF may wait until all responses are received from the network slices 1512, EXP FXNs, CP or NFs, the NGEF may consolidate the responses and may send a report 1514 to the AS with the consolidated response and an ESID as have been disclosed above.
  • NGEF may receive a request to report a WTRU location.
  • the WTRU may be connected to multiple slices as have been described above.
  • the NGEF use local information, for example, based on a mapping from an ESID to NSID, or AS ID/application ID to NSID, etc., to determine which network node (EXP FXN, CP or NF) should report this.
  • the NGEF may also have rules with respect to which of the network slices it has to contact for a one time WTRU location when the WTRU does have access to multiple slices simultaneously. Some exemplary rules are disclosed herein.
  • the NGEF may contact a database to determine which slice to send the request to.
  • the NGEF may use a mapping as have been described above.
  • the mapping may have a priority rule associated with it where: a slice identity or a network slice may have a higher priority over others for particular services, and/or application ID; a slice may not be allowed for exposing a service as have been described in the previous section; and the determination of the slice is based on any of the ESID, application ID, AS ID, and device external ID.
  • the NGEF may have rules and/or policies to contact the next slice where the WTRU also has registered with or received a service from.
  • the next network slice to try may be any slice where the WTRU is also known to have registered with or have received a service from.
  • the NGEF may request this information from a database e.g. an HSS, which may provide a list of network slice IDs for a particular service exposure, and the database may also provide an indication of whether the service may be obtained from more than one slice, and if yes the slice ID and, for example, the priority with which to contact that slice.
  • the current EPS system may expose a service, specifically the "One-time last known location of WTRU".
  • the current EPS may supports registration with only one network, i.e. there is no support for WTRUs accessing multiple slices. When the WTRU is accessing multiple slices, it may be necessary to consider how such service will be exposed. To do so, the following embodiments are disclosed:
  • the NGEF may take any of the actions disclosed herein, for example, the NGEF may verify whether this service may be obtained from more than one network slice, and furthermore the NSID from where this service may be obtained.
  • the NF or CP that contains this information may also save a time-stamp for the WTRU location, i.e. the time associated with the identified or retrieved WTRU location.
  • the NF and/or CP node that may provide this service report to the NGEF may also provide this timestamp.
  • the NGEF may receive multiple reports for "One-time last known location of WTRU" per network slice. If received, the NGEF may take the following actions depending on the policies of the network that may be locally saved in the NGEF or retrieved by the NGEF from a database, for example, an HSS:
  • the NGEF may collect the responses from different network slices and may verify which response has the latest timestamp associated with a location of the WTRU.
  • the NGEF may send the associated location along with the latest timestamp to the AS.
  • the NGEF may also send the ESID that maps to the network slice from which this is obtained.
  • the NGEF may have policies to send more than one location of the WTRU as one or more information reports, and the NGEF may include the associated ESID for each of the location information reports, which may indicate the service type and implicitly the NSID of the network from which this information is received.
  • the NGEF may send a location report without including the ESID that maps to an NSID.
  • a continuous WTRU location may be exposed.
  • the current EPS system may expose a service, specifically the "Continuous reporting of Location" for a particular WTRU. Again, the WTRU may be accessing different slices at the same time. As such, the NGEF may need to determine which network slice should be contacted for exposing this service.
  • the NGEF may take any of the following actions to report such information or provide such service: the NGEF may take any of the actions that have been discloed; the NGEF may choose a network slice based on the load or the number of such (or other) requests that have been sent to the different network slices and thus, the NGEF may try to maintain a balanced number of requests across all the slices; the granularity or the type of location information that is required to be reported may be different across the network slices.
  • the AS may indicate a preference for the location service, e.g. at a cell level, geographical coordinate level, etc. As such, the NGEF may choose, based on local information, the network slice that best matches the request of the AS.
  • the current EPS system may expose a service, specifically the "WTRU connection properties".
  • the connection properties may be dependent on RAT conditions or other core network conditions, e.g. load on the UP components.
  • the CN conditions may also be different from one network slice to the other.
  • the radio access networks or technologies that may be used to access more than one slice may be different.
  • the WTRU may use E-UTRAN to access one slice, and a new 5G RAT and WiFi to access another network slice.
  • the NGEF may take any of the following actions to expose such a service:
  • the NGEF may take any of the actions that have been described above, for example, to determine which network slice may be contacted to expose such a service, for example, based on a mapping from ESID to NSID, or a lack of such a mapping.
  • the NGEF may receive reports from more than one network slice where the report may indicate the connection properties of the WTRU.
  • the connection properties may contain a RAT type, and overall description of the connection or quality of the connection (either on the RAN or CN side).
  • the NGEF may consolidate the reports from all the network slices and may send a single report containing any of the following: a connection description per slice or ESID or service type; a connection description that reflects the best connection properties from all the network slices; a connection property that is an average of all the connection properties; and a connection property that reflects the worst connection that the WTRU is receiving.
  • 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.

Landscapes

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

Abstract

La présente invention concerne un procédé et un appareil pour divulguer des services par tranche de réseau. Le procédé peut consister à recevoir, en provenance d'un serveur d'applications, une demande pour créer ou modifier une tranche de réseau. La demande peut inclure un ou plusieurs premiers paramètres incluant : un identifiant d'application, un identifiant de service externe, une indication d'un type de service ou au moins une unité WTRU cible. Une tranche de réseau cible peut être déterminée sur la base des paramètres de la demande reçue. La demande peut être transférée, par le biais d'une NGEF locale, à une CP NF. Une réponse peut être reçue, par l'intermédiaire de la NGEF locale, en provenance de la CP NF, incluant des paramètres de tranche de réseau. Un message de réponse avec modification de tranche de réseau peut être envoyé au serveur d'applications incluant un résultat de la demande reçue et des seconds paramètres correspondants de tranche de réseau.
PCT/US2017/025359 2016-04-01 2017-03-31 Procédés et fonction ngef pour la divulgation de services par tranche de réseau WO2017173259A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662317175P 2016-04-01 2016-04-01
US62/317,175 2016-04-01

Publications (1)

Publication Number Publication Date
WO2017173259A1 true WO2017173259A1 (fr) 2017-10-05

Family

ID=58549231

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/025359 WO2017173259A1 (fr) 2016-04-01 2017-03-31 Procédés et fonction ngef pour la divulgation de services par tranche de réseau

Country Status (1)

Country Link
WO (1) WO2017173259A1 (fr)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108495358A (zh) * 2018-03-09 2018-09-04 西安电子科技大学 一种基于nfv的网络切片选择方法
EP3474603A1 (fr) * 2017-10-20 2019-04-24 Deutsche Telekom AG Procédé pour contrôler l'accès d'un équipement utilisateur à un réseau de communication mobile ayant au moins une tranche de réseau, système, réseau de communication mobile, programme et produit-programme d'ordinateur
CN110324284A (zh) * 2018-03-30 2019-10-11 华为技术有限公司 接入ims的方法和通信装置
US10582432B2 (en) 2017-05-04 2020-03-03 Comcast Cable Communications, Llc Communications for network slicing using resource status information
US10616934B2 (en) 2017-12-08 2020-04-07 Comcast Cable Communications, Llc User plane function selection for isolated network slice
CN111165025A (zh) * 2017-10-16 2020-05-15 华为技术有限公司 协同终端切片功能和网络切片功能
US10764789B2 (en) 2017-08-11 2020-09-01 Comcast Cable Communications, Llc Application-initiated network slices in a wireless network
CN112055977A (zh) * 2020-08-03 2020-12-08 北京小米移动软件有限公司 业务的切片激活方法、业务的切片激活装置及存储介质
CN112753234A (zh) * 2018-09-27 2021-05-04 康维达无线有限责任公司 3gpp专用lan
CN112819054A (zh) * 2021-01-25 2021-05-18 中国联合网络通信集团有限公司 一种切片模板配置方法及装置
EP3800918A4 (fr) * 2018-06-30 2021-08-04 Huawei Technologies Co., Ltd. Procédé et appareil de communication
US11153813B2 (en) 2017-08-11 2021-10-19 Comcast Cable Communications, Llc Network slice for visited network
US11871271B2 (en) 2021-05-17 2024-01-09 Cisco Technology, Inc. Dynamic switching for user equipment between unique cell and shared cell operating modes based on application traffic
US11882611B2 (en) 2021-05-17 2024-01-23 Cisco Technology, Inc. Dual-connectivity support for user equipment in a hybrid cell virtualized radio access network architecture
US11950218B2 (en) 2021-05-14 2024-04-02 Cisco Technology, Inc. Auto-configuration of hybrid cells supporting shared cell and unique cell operating modes for user equipment in virtualized radio access network architectures

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3 Generation Partnership Project; Technical Specification Group Services and System Aspects; Feasibility Study on New Services and Markets Technology Enablers; Stage 1 (Release 14)", 3GPP STANDARD; 3GPP TR 22.891, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG1, no. V14.0.0, 18 March 2016 (2016-03-18), pages 1 - 95, XP051088163 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Architecture for Next Generation System (Release 14)", 14 March 2016 (2016-03-14), XP051086091, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/Latest_SA2_Specs/Latest_draft_S2_Specs/> [retrieved on 20160314] *
3GPP: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for service capability exposure (Release 13) 3GPP TR 23.708 V13.0.0 (2015-06)", 21 June 2015 (2015-06-21), INET, pages 1 - 37, XP055381202, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/specs/archive/23_series/23.708/23708-d00.zip> [retrieved on 20170613] *

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10582432B2 (en) 2017-05-04 2020-03-03 Comcast Cable Communications, Llc Communications for network slicing using resource status information
US11889370B2 (en) 2017-05-04 2024-01-30 Comcast Cable Communications, Llc Handover procedure using resource status information
US11134424B2 (en) 2017-05-04 2021-09-28 Comcast Cable Communications, Llc Communications for network slicing using resource status information
US11690005B2 (en) 2017-08-11 2023-06-27 Comcast Cable Communications, Llc Network slice for visited network
US11153813B2 (en) 2017-08-11 2021-10-19 Comcast Cable Communications, Llc Network slice for visited network
US10764789B2 (en) 2017-08-11 2020-09-01 Comcast Cable Communications, Llc Application-initiated network slices in a wireless network
US11818608B2 (en) 2017-08-11 2023-11-14 Comcast Cable Communications, Llc Third party charging in a wireless network
US11412418B2 (en) 2017-08-11 2022-08-09 Comcast Cable Communications, Llc Third party charging in a wireless network
CN111165025A (zh) * 2017-10-16 2020-05-15 华为技术有限公司 协同终端切片功能和网络切片功能
CN111165025B (zh) * 2017-10-16 2022-05-24 华为技术有限公司 协同终端切片功能和网络切片功能
EP3474603A1 (fr) * 2017-10-20 2019-04-24 Deutsche Telekom AG Procédé pour contrôler l'accès d'un équipement utilisateur à un réseau de communication mobile ayant au moins une tranche de réseau, système, réseau de communication mobile, programme et produit-programme d'ordinateur
US10616934B2 (en) 2017-12-08 2020-04-07 Comcast Cable Communications, Llc User plane function selection for isolated network slice
US11102828B2 (en) 2017-12-08 2021-08-24 Comcast Cable Communications, Llc User plane function selection for isolated network slice
CN108495358A (zh) * 2018-03-09 2018-09-04 西安电子科技大学 一种基于nfv的网络切片选择方法
CN110324284B (zh) * 2018-03-30 2020-10-27 华为技术有限公司 接入ims的方法和通信装置
CN110324284A (zh) * 2018-03-30 2019-10-11 华为技术有限公司 接入ims的方法和通信装置
EP3800918A4 (fr) * 2018-06-30 2021-08-04 Huawei Technologies Co., Ltd. Procédé et appareil de communication
US11522761B2 (en) 2018-06-30 2022-12-06 Huawei Technologies Co., Ltd. Communication method and apparatus
CN112753234A (zh) * 2018-09-27 2021-05-04 康维达无线有限责任公司 3gpp专用lan
CN112055977B (zh) * 2020-08-03 2023-12-19 北京小米移动软件有限公司 业务的切片激活方法、业务的切片激活装置及存储介质
CN112055977A (zh) * 2020-08-03 2020-12-08 北京小米移动软件有限公司 业务的切片激活方法、业务的切片激活装置及存储介质
CN112819054B (zh) * 2021-01-25 2023-06-30 中国联合网络通信集团有限公司 一种切片模板配置方法及装置
CN112819054A (zh) * 2021-01-25 2021-05-18 中国联合网络通信集团有限公司 一种切片模板配置方法及装置
US11950218B2 (en) 2021-05-14 2024-04-02 Cisco Technology, Inc. Auto-configuration of hybrid cells supporting shared cell and unique cell operating modes for user equipment in virtualized radio access network architectures
US11871271B2 (en) 2021-05-17 2024-01-09 Cisco Technology, Inc. Dynamic switching for user equipment between unique cell and shared cell operating modes based on application traffic
US11882611B2 (en) 2021-05-17 2024-01-23 Cisco Technology, Inc. Dual-connectivity support for user equipment in a hybrid cell virtualized radio access network architecture

Similar Documents

Publication Publication Date Title
WO2017173259A1 (fr) Procédés et fonction ngef pour la divulgation de services par tranche de réseau
US20210368347A1 (en) Network slicing operation
US11234213B2 (en) Machine-to-machine (M2M) interface procedures for announce and de-announce of resources
KR102320063B1 (ko) 서비스 슬라이스 선택 및 분리를 위한 방법
US11956332B2 (en) Edge aware distributed network
EP4190006A1 (fr) Optimisations de plan utilisateur au moyen d&#39;une analyse de données de réseau
US20180007497A1 (en) METHODS, APPARATUSES AND SYSTEMS DIRECTED TO PROXIMITY SERVICES (ProSe) DIRECT DISCOVERY
JP5860070B2 (ja) ユーザ要素間セッション転送の認可
WO2018232253A1 (fr) Fonction d&#39;exposition de réseau
WO2022115733A1 (fr) Réduction au minimum de l&#39;interruption de service
JP2017107574A (ja) 通信ネットワーク内でコンテンツストレージサブシステムを管理するための方法および装置
US20240172175A1 (en) Method and appartuses for group paging for signal efficiency in 5g network
WO2023192097A1 (fr) Procédés, dispositifs et systèmes de gestion de tranche de réseau initiée par ue au niveau d&#39;une couche d&#39;activation de service
US20110116447A1 (en) Media performance management

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: 17718205

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17718205

Country of ref document: EP

Kind code of ref document: A1