CN117397231A - Method and device for terminal function distribution - Google Patents

Abstract

The present disclosure relates to methods and apparatus for establishing and maintaining a single PDU session with multiple terminal devices, such as for transferring terminal functions between two WTRUs or distributing performance of terminal functions among multiple WTRUs. Furthermore, a method and apparatus for SLA mapping for terminal function distribution are provided. An SLA for a single PDU session may map between multiple distributed WTRUs based on the functional requirements of network slice selection. The set of devices running the same PDU session's functions may be selected and registered to the appropriate slice based on their required SLA. The network assisted function distribution slice selection function may serve an ongoing single PDU session in the selected WTRU set on multiple slices in the 5G core.

Description

Method and device for terminal function distribution

Cross Reference to Related Applications

The present application claims priority and benefit from U.S. provisional application No. 63/181,332, filed on U.S. patent and trademark office at 29, 4, 2021, and U.S. provisional application No. 63/181,712, filed on U.S. patent and trademark office, each of which is incorporated herein by reference in its entirety as if fully set forth below for all useful purposes.

Background

Mobile communications using wireless communications continue to evolve. The fifth generation (5G) mobile communication Radio Access Technology (RAT) may be referred to as 5G new air interface (NR). The previous generation (legacy) mobile communication RAT may be, for example, fourth generation (4G) Long Term Evolution (LTE).

Mobile telecommunication devices, such as cellular telephones, tablet computers, and the like, sometimes referred to herein generically as wireless transmit/receive units or (WTRUs), have become increasingly popular and have become the primary choice for consumer electronic content and application experience. Also, due to recent advances in various device form factors, the popularity of such devices and the capabilities of such devices (e.g., content presentation devices such as televisions and projectors) have increased significantly. However, when consuming a single experience or content (e.g., playing a video game or watching a movie), the user is typically limited to consuming the content on a single WTRU device, although in fact other better devices for consuming the given content may become available to the user during the period in which the user consumes the content (or, conceivably, may already be available even when consuming the content begins, but for some reason not selected by the user). For example, a user may begin watching a movie on the user's cellular telephone while riding in a car, but then, upon reaching the destination (e.g., the user's home), there are many new choices of equipment for watching the movie (e.g., bedroom television, living room television, tablet computer, or desktop computer). The user may wish to transfer the experience to be consumed to a different device, in some cases the user may wish to transfer a subset of the portions of the experience to a different device, e.g., continue watching the video portion of the movie on the user's cellular telephone, but listen to the audio portion of the movie on the home audio system.

Disclosure of Invention

Embodiments disclosed herein relate generally to wireless communication networks. For example, one or more embodiments disclosed herein relate to methods, apparatuses, and systems for establishing and maintaining a single Packet Data Unit (PDU) session with multiple terminal devices, such as for transferring terminal functions between two WTRUs or distributing performance of terminal functions among multiple WTRUs.

Additionally, some embodiments disclosed herein relate to methods, apparatuses, and systems for Service Level Agreement (SLA) mapping for terminal function distribution. For example, an SLA for a PDU session (e.g., a single PDU session) may map between one or more distributed WTRUs based on one or more functional requirements selected by a network slice. The set of devices running the functionality of a PDU session (e.g., the same PDU session) may be selected and registered to the appropriate slice based on their required SLA. The network assisted function distribution slice selection function may serve an ongoing single PDU session in the selected WTRU set on multiple slices in the 5G core.

In one embodiment, a method implemented in a WTRU for wireless communication includes: receiving an identification of a set of devices that can be used to share one or more terminal functions with the WTRU; selecting at least one device in the set of devices to share terminal functions being performed by the WTRU; generating a Packet Data Unit (PDU) session Identifier (ID) associated with the terminal function; transmitting a PDU session request message, and the PDU session request message including information indicating at least the PDU session ID and a respective identity of each selected device in the set of devices; and receiving a PDU session establishment message after transmitting the PDU session request message. The method may further include distributing terminal functions in the network with each selected device in the set of devices. The method may include: executing a terminal function; and querying a discovery engine for a set of devices available to share terminal functions with the WTRU. The method may also include registering with a discovery engine in the network to indicate availability of the WTRU to share terminal functions with at least one device in the set of devices. The one or more terminal functions may include the terminal function. The PDU session ID may be associated with one or more terminal functions and may be shared between the WTRU and at least one device in the set of devices.

In another embodiment, a method implemented in a WTRU for wireless communication includes: transmitting a first message to the network, and the first message including information indicating any one of: a request for a data session, a WTRU identity to be associated with the data session, a capability of the WTRU, and/or a request for a service to be provided by the network; receiving a second message from the network, wherein the second message includes information indicating any of: WTRU identity, slice identity associated with the requested service, and/or WTRU capabilities; and transmitting a third message to the network, and the third message includes information indicating a request to register the WTRU identity such that the WTRU may use the requested service associated with the slice identity. The method may further include transmitting a fourth message to the network using the requested data session, and the fourth message includes information indicating a slice identity and/or data for the requested service.

In various embodiments, a WTRU including a processor, a receiver, a transmitter, and a memory is configured to implement one or more methods disclosed herein. For example, a WTRU for distributing terminal functions to/from other devices may be configured to: executing a terminal function; querying a discovery engine for devices that can be used to share terminal functions with the WTRU; receiving an identification of a device that can be used to share terminal functions with the WTRU; selecting at least one of the devices (capable of sharing terminal functions) to share the terminal function being performed by the WTRU; generating a PDU session ID corresponding to the terminal function; transmitting a PDU session request message (including at least a PDU session ID and an identification of at least one selected device) to the network; and receiving a PDU session establishment message from the network. The WTRU may be further configured to: transmitting function status information of terminal functions/services to at least one selected device; and communicating with at least one selected device to share the capabilities of the terminal function.

Drawings

A more detailed understanding can be obtained from the following detailed description, which is given by way of example in connection with the accompanying drawings. As with the detailed description, the drawings in such figures are exemplary. Accordingly, the drawings and detailed description are not to be regarded as limiting, and other equally effective examples are possible and contemplated. Additionally, like reference numerals ("ref") in the drawings ("figures") refer to like elements, and wherein:

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

fig. 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in fig. 1A according to one embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;

fig. 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used in the communication system shown in fig. 1A according to one embodiment;

FIG. 2 is a network block diagram illustrating various components of a network according to one embodiment;

Fig. 3 is a diagram illustrating the concept of a single PDU session on a distributed terminal according to one embodiment;

fig. 4 is a signal flow diagram illustrating the establishment of a single PDU session for a plurality of terminal devices according to one embodiment;

fig. 5 is another signal flow diagram illustrating the establishment of a single PDU session for a plurality of terminal devices according to one embodiment;

figure 6 is a block diagram illustrating an example of an exploded slice within a single PDU session for a distributed WTRU/terminal in accordance with one embodiment;

FIG. 7 is a diagram illustrating an example of distributed slicing within a single session for terminal function distribution, according to one embodiment;

FIG. 8 is a diagram illustrating an example architecture for a device-to-device (D2D), device-to-edge (D2E), and device-to-cloud (D2C) scenario in accordance with one or more embodiments;

FIG. 9 is a signal flow diagram illustrating an exemplary process for SLA mapping for terminal function distribution according to one embodiment; and is also provided with

Fig. 10 is a signal flow diagram illustrating an exemplary process for SLA mapping of distributed terminal functions over a PDU session, according to one embodiment.

Detailed Description

1Introduction to the invention

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and/or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the description below. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with embodiments and other examples that are explicitly, implicitly, and/or inherently described, disclosed, or otherwise provided (collectively, "provided"). Although various embodiments are described and/or claimed herein, wherein an apparatus, system, device, etc., and/or any element thereof, performs an operation, procedure, algorithm, function, etc., and/or any portion thereof, it is to be understood that any embodiment described and/or claimed herein assumes that any apparatus, system, device, etc., and/or any element thereof, is configured to perform any operation, procedure, algorithm, function, etc., and/or any portion thereof.

2Exemplary network for implementing the invention

Fig. 1A is a diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messages, broadcasts, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), frequency Division Multiple Access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter Bank Multicarrier (FBMC), and the like.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, public Switched Telephone Networks (PSTN) 108, the internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As an example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and/or a "STA") may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal Digital Assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hot spot or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronic devices, devices operating on a commercial and/or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

Communication system 100 may also include base station 114a and/or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs, home evolved node bs, gnbs, NR node bs, site controllers, access Points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 104/113 that may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), radio Network Controllers (RNCs), relay nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one for each sector of a cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.

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, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as noted above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. For example, a base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interfaces 115/116/117.WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (hspa+). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or High Speed UL Packet Access (HSUPA).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-a Pro) to establish the air interface 116.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use a new air interface (NR) to establish the air interface 116.

In embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using a Dual Connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., enbs and gnbs).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., wireless fidelity (WiFi)), IEEE 802.16 (i.e., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114B in fig. 1A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connections in local areas such as business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, etc. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-a Pro, NR, etc.) to establish a pico cell or femto cell. As shown in fig. 1A, the base station 114b may have a direct connection with the internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106/115.

The RANs 104/113 may communicate with the CNs 106/115, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RANs 104/113 and/or CNs 106/115 may communicate directly or indirectly with other RANs that employ the same RAT as the RANs 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113 that may utilize NR radio technology, the CN 106/115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA, wiMAX, E-UTRA, or WiFi radio technology.

The CN 106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112.PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and/or Internet Protocol (IP) in the TCP/IP internet protocol suite. Network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RANs 104/113 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in fig. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE 802 radio technology.

Fig. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripheral devices 138, etc. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

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 Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood 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 and receive signals from a base station (e.g., base station 114 a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In one embodiment, the transmit/receive element 122 may be an emitter/detector configured to emit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Although the transmit/receive element 122 is depicted as a single element in fig. 1B, 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 signals to be transmitted by the transmit/receive element 122 and demodulate signals received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), read Only Memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may never physically locate memory access information on the WTRU 102, such as on a server or home computer (not shown), and store the data in that memory.

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry battery packs (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 a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with an embodiment.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the number of the cells to be processed, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photographs and/or video), universal Serial Bus (USB) ports, vibrating devices, television transceivers, hands-free headsets, wireless communications devices, and the like,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, activity trackers, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; a geographic position sensor; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and/or humidity sensors.

WTRU 102 may include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. The full duplex radio station may include an interference management unit 139 for reducing and/or substantially eliminating self-interference via hardware (e.g., choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).

Fig. 1C is a system diagram illustrating a RAN 104 and a CN 106 according to an embodiment. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using an E-UTRA radio technology. RAN 104 may also communicate with CN 106.

RAN 104 may include enode bs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enode bs while remaining consistent with an embodiment. The enode bs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In an embodiment, the evolved node bs 160a, 160B, 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or to receive wireless signals from the WTRU 102a, for example.

Each of the evolved node bs 160a, 160B, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, and the like. As shown in fig. 1C, the enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

The MME 162 may be connected to each of the evolved node bs 162a, 162B, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating the user of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and/or WCDMA.

SGW 164 may be connected to each of the evolved node bs 160a, 160B, 160c in RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring user planes during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the contexts of the WTRUs 102a, 102B, 102c, etc.

The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and legacy landline communication devices. For example, the CN 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 CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communication interface with a communication network (e.g., temporarily or permanently).

In representative embodiments, the other network 112 may be a WLAN.

A WLAN in an infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may pass the traffic to the destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Point-to-point traffic may be sent between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

When using the 802.11ac infrastructure mode of operation or similar modes of operation, the AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20MHz wide bandwidth) or a width dynamically set by signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access/collision avoidance (CSMA/CA) may be implemented, for example, in an 802.11 system. For CSMA/CA, STAs (e.g., each STA), including the AP, may listen to the primary channel. If the primary channel is listened to/detected by a particular STA and/or determined to be busy, the particular STA may backoff. One STA (e.g., only one station) may transmit at any given time in a given BSS.

High Throughput (HT) STAs may communicate using 40MHz wide channels, for example, by combining a primary 20MHz channel with an adjacent or non-adjacent 20MHz channel to form a 40MHz wide channel.

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may pass through a segment parser that may split the data into two streams. An Inverse Fast Fourier Transform (IFFT) process and a time domain process may be performed on each stream separately. These streams may be mapped to two 80MHz channels and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to a Medium Access Control (MAC).

The 802.11af and 802.11ah support modes of operation below 1 GHz. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. The 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and the 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery lives above a threshold (e.g., to maintain very long battery lives).

WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs from all STAs operating in the BSS (which support a minimum bandwidth mode of operation). In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only) 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth modes of operation. The carrier sense and/or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because the STA (supporting only 1MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band remains idle and possibly available.

The available frequency band for 802.11ah in the united states is 902MHz to 928MHz. In korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

Fig. 1D is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c over an air interface 116. RAN 113 may also communicate with CN 115.

RAN 113 may include gnbs 180a, 180b, 180c, but it should be understood that RAN 113 may include any number of gnbs while remaining consistent with an embodiment. Each of the gnbs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gnbs 180a, 180b, 180c may implement MIMO technology. For example, gnbs 180a, 180b may utilize beamforming to transmit signals to and/or receive signals from gnbs 180a, 180b, 180 c. Thus, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102a, for example. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on the unlicensed spectrum while the remaining component carriers may be on the licensed spectrum. In embodiments, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the scalable sets of parameters. For example, the OFDM symbol interval and/or OFDM subcarrier interval may vary from one transmission to another, from one cell to another, and/or from one portion of the wireless transmission spectrum to another. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using various or scalable length subframes or Transmission Time Intervals (TTIs) (e.g., including different numbers of OFDM symbols and/or continuously varying absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not accessing other RANs (e.g., such as the enode bs 160a, 160B, 160 c). In an independent configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In an independent configuration, the WTRUs 102a, 102b, 102c may use signals in unlicensed frequency bands to communicate with the gnbs 180a, 180b, 180 c. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs (such as the enode bs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may implement DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102B, 102 c.

Each of the gnbs 180a, 180b, 180c 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 UL and/or DL, support of network slices, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and so on. As shown in fig. 1D, gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.

CN 115 shown in fig. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

AMFs 182a, 182b may be connected to one or more of gNB 180a, 180b, 180c in RAN 113 via an N2 interface and may function as a control node. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slices (e.g., handling of different PDU sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMFs 182a, 182b may use network slices to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra high reliability low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. The AMFs 182b, 182b may provide control plane functionality for switching between the RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi.

The SMFs 183a, 183b may be connected to AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN 115 via an N4 interface. SMFs 183a, 183b may select and control UPFs 184a, 184b and configure traffic routing through UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.

UPFs 184a, 184b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN 113 via an N3 interface that may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-host PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b through an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

In view of fig. 1A-1D and the corresponding descriptions of fig. 1A-1D, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): the WTRUs 102a-102d, base stations 114a-114B, eNodeBs 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMFs 182a-182B, UPFs 184a-184B, SMFs 183a-183B, DNs 185a-185B, and/or any other devices described herein. The emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and/or analog network and/or WTRU functions.

The simulation device may be designed to enable one or more tests of other devices in a laboratory environment and/or an operator network environment. For example, the one or more emulation devices can perform one or more or all of the functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform one or more functions or all functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and/or may perform testing using over-the-air wireless communications.

The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test laboratory and/or a test scenario in a non-deployed (e.g., test) wired and/or wireless communication network in order to enable testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and/or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and/or receive data.

3Distributed terminal functionality

For a number of reasons, there is a need for efficient methods and apparatus for partitioning and transferring terminal functions that allow offloading of specific functions from a first WTRU to one or more other WTRUs to improve the overall user experience (e.g., the gaming experience may be transferred to a larger display and better gaming control equipment to improve the user experience). For example, as described above, a consumer of digital content may be mobile and during consumption of digital content may be in proximity to a more preferred device for consuming particular content and may wish to transfer some or all of this functionality to the different telecommunications device without having to restart the experience or perform a complex series of manual steps to cause the transfer to occur. Furthermore, offloading computationally burdensome functions from a battery-powered mobile device to other line-powered devices may improve battery usage/life of the user's mobile device, while also enabling the enhanced functionality of the other devices to be utilized, thereby improving the overall user experience.

In current wireless network systems, protocol Data Unit (PDU) sessions are established for providing an end-to-end user plane connection between a WTRU and a Data Network (DN) through a User Plane Function (UPF). One PDU may support multiple QoS flows. Thus, each participating device (i.e., WTRU or terminal) establishes a separate PDU session for the corresponding DN prior to performing the function distribution. In addition, the Session Management Function (SMF) of the network is responsible for creating, removing and updating PDU sessions and managing WTRU contexts with UPF.

The present disclosure contemplates three different scenarios for terminal function distribution, namely, device-to-device (hereinafter scenario a), device-to-edge (hereinafter scenario B), device-to-cloud (hereinafter scenario C), as depicted in fig. 2.

In particular, fig. 2 illustrates an exemplary wireless network including various functional components and/or nodes commonly found in 5G networks, including NSSF (network slice selection function), AUSF (authentication server function), NSSAF (network slice specific authentication and authorization function), UDM (unified data management), AMF, SMF, PCF (policy control function), AF (application function), RAN (radio access network), UPF, DN, N31WF (non-3 GPP interworking function), and multiple WTRUs. According to one embodiment, one or more WTRUs (e.g., WTRU 201) may be equipped with a functionality distribution layer including a terminal analyzer, a discovery engine, a user context engine, a functionality manager, and a communication manager, as described in more detail below. Local hub 203, as described in more detail below, may also be included in the network.

The device-to-device interaction (scenario a) according to embodiments may be performed, for example, between WTRU 201 and WTRU 205. A device-to-edge interaction (scenario B) according to an embodiment may be performed between WTRU 201 and another WTRU, such as any one of WTRUs 207, 209, 211, over a network, and a device-to-cloud interaction (scenario C) according to an embodiment may be performed between WTRU 201 and DN 213.

The methods and apparatus disclosed herein allow a set of terminal functions (along with corresponding data and/or status information) to be distributed across multiple terminals/devices in a single PDU session and without disrupting service. The methods and apparatus disclosed herein ensure that ongoing sessions between terminal functions are distributed among selected terminals, while a single PDU session (now distributed) serves the master terminal (i.e., end user).

New components are described in section 3.1 and procedures for using these components to distribute terminal functions over multiple terminals/devices during a single session are described in section 3.3. Section 3.2 presents a local hub device that may be implemented to facilitate the ability to register and discover other devices in the vicinity of the WTRU for function distribution purposes.

3.1Function distribution layer

The terminal function distribution layer relates to the virtualization of terminal functions, management of resources (device local resources and network resources), and the functional lifecycle. The functions at the various layers of the device stack may be divided into ultimately performing these functions on the network, thereby optimizing the resources and user experience.

3.1.1Terminal analyzer

The analyzer provides functional information (e.g., type of HW function, system call) and runtime information (e.g., runtime CPU and energy utilization) about the existing single device function. Such information may be used to make functional lifecycle management and resource management decisions by the functional manager and communications manager components. The component may be implemented as an operating system or application layer service having security rights to collect the information.

3.1.2User context engine

The user context engine may collect user context information by both: sensors in the device (e.g., user location received via GPS receiver) and other services/applications that provide information about user behavior (e.g., user's calendar). The component may be implemented as an operating system or application layer service with API (application protocol interface) calls (e.g., REST API calls) to the corresponding sensor software drivers and web services.

Continuous collection and storage of such information may result in overuse of permanent and non-permanent storage. Thus, in one embodiment, the user context engine may collect and store information only upon receiving a request from a function manager and communication manager component (described below).

3.1.3Discovery engine

For offloading device functions, the function distribution layer should be able to discover previously unknown available devices. In particular, in case the user is moving, a suitable device for offloading functions should be found. The discovery engine may provide an API for actively registering/querying available devices, such as devices at the network edge, devices in the cloud, and devices in the vicinity of the user device (for the function/communication manager component). Alternatively or in addition, it may also actively search for devices in the vicinity of the user by periodically scanning the network and then provide the newly discovered devices to the communications manager component. Such information may in turn be used to make functional offloading/distribution decisions. Alternatively, the discovery engine may discover the new device using a discovery service provided by a network operator, a discovery service provided by a non-3 GPP access network, or a point-to-point device/network (e.g., bluetooth) discovery method.

3.1.4Function manager

In one embodiment, the function manager makes lifecycle management decisions (e.g., turns off functions to save energy) for locally running device functions and makes decisions regarding offloading/distributing the functions to be performed onto discovered devices that are more suitable for the task or otherwise appropriate. Finally, the decisions made may optimize the energy efficiency of the local device, the resource utilization of the device and the network, and the overall user experience. Such decisions may be made based on user behavior (via the terminal context engine), resource consumption (via the terminal analyzer), and/or user mobility/device availability (via the discovery engine).

3.1.5Communication manager

The communication manager is concerned with managing the interconnectivity between devices providing the capability for distributed execution of terminal functions, and between the functions themselves. Such procedures may include selecting (e.g., network selection) and managing functional communication media.

3.2Local hub

An end user device (WTRU) may provide its resources for use by other devices/users in its vicinity, such as computing resources, display screens, speakers, etc. The local hub provides APIs (functionality of the discovery engine) for such resource provider devices to register their capabilities and allow them to be discovered by other devices in the vicinity (e.g., home, campus, shopping mall). Access to the local hub and its APIs (e.g., registration and discovery) may be provided over a wireless network (e.g., wi-Fi). The capabilities and availability information of each registered device is provided to the local hub during registration and stored in the hub until they are de-registered or a specific registration expiration time elapses.

The local hub 203 may operate as a stand-alone entity without any direct connection with the operator's core network, or it may be connected to the operator's network as a non-3 GPP network for extending the network services of the various operators to the connected devices/terminals.

3.3Terminal function distribution during a single PDU session

Fig. 3 depicts the concept of a single PDU session on distributed terminals that are connected to dedicated application functions to perform the distributed functions. As shown, multiple WTRUs 301, 302, 305 share a packet 307 in a single shared PDU session 309 via one or more UPFs 311.

As previously described, this execution may occur in the device itself, as shown in connection with AF 315, at an edge data network, as shown in connection with AF 317, or at a cloud data network, as shown in connection with AF 319.

Figure 4 is a signal flow diagram illustrating an exemplary scenario in which a procedure is used to distribute terminal functions from a primary WTRU 401 to other selected WTRUs/devices (e.g., 403) during a single PDU session, according to one embodiment. Fig. 5 is another signal flow diagram of fig. 4.3.2.2.1-1, based on 3GPP TS23.502v17.0.0 (hereinafter "TS 23.502"), illustrating how the procedure described therein for UE requested PDU session establishment for non-roaming and roaming with local breakout may be modified according to one embodiment. In particular, as shown in fig. 5 and as will be discussed in more detail below, in the embodiment represented in fig. 5, the signal flow from TS23.502 of fig. 4.3.2.2.1-1 will be altered by: (1) Steps 1, 2 and 3 (labeled as steps 1, 2 and 3 in both fig. 4.3.2.2.1-1 of TS23.502 and fig. 5) are modified and steps 15, 16, 17 and 18 are added in fig. 5. In addition, in contrast to fig. 4.3.2.2.1-1 of TS23.502, another UE/WTRU (i.e., a "discovered" UE/WTRU to which terminal functionality is to be transferred) is added in the first column of fig. 5. Thus, all other steps in FIG. 5 may remain substantially the same as the corresponding steps in FIG. 4.3.2.2.1-1 of TS23.502, except for the modification of step 1-3 and the addition of steps 15-18. Note, however, that steps 15-21 of fig. 4.3.2.2.1-1 of TS23.502 are renumbered to steps 19-25 of fig. 5, as steps 15-18 are added in fig. 5.

Referring to fig. 4, a terminal/device that may be used to load untrusted functions registers 410 with the discovery engine 405 (e.g., in a local hub or master device 401). The registration process in the discovery engine collects and stores WTRU IDs that uniquely identify WTRUs within the 5G core (5 GC) network 407. Along with the UE ID, each registered device (e.g., WTRU 403) provides its computing capabilities (e.g., CPU size, RAM size), networking capability (e.g., cellular status) capabilities, and location information (i.e., GPS coordinates) to the discovery engine 405.

Devices may be registered through an API provided by the discovery engine.

Registration may be performed automatically by discovering terminals/devices in the vicinity of the discovery engine.

The WTRU ID may also be a service ID or any other sharable ID that may be used to uniquely identify the terminal/device (or service/function therein).

Master/initiating UE 401 sends a request 412 to discovery engine 405 to query for new discovered/updated terminals/devices. Where the discovery engine 405 resides within the same device 401, callback or IPC procedures may be used to obtain this information. We assume that the master UE has any required access permissions in the discovery engine (e.g., in the local hub) to obtain this information.

Alternatively, the master WTRU 401 may automatically receive updates from the discovery engine regarding newly discovered devices.

The discovery engine 405 responds to the primary WTRU 401 with all the information collected for each registered device during the registration process (414).

The primary WTRU 401 determines the most appropriate distribution of terminal functions among the devices (416). In making the function distribution decision, it uses the information collected from the analyzer, the user context engine, and the discovery engine to decide what function(s) to offload, when (at the appropriate time) to offload functions, and where (the best device) to offload functions.

Alternatively, the selection of the most appropriate distribution of terminal functions may be performed by an entity within the network (e.g., an application function at the edge).

Once the best terminal/device for distribution/offloading is selected, the master UE 401 (communication manager) triggers the function distribution process by establishing a connection with the selected device. It therefore initiates the creation of a PDU session to be shared between all participating devices by first communicating with the 5G core network. In particular, as part of session initiation, master UE 401 generates a session ID. The IDs of the selected devices in step 4 are provided in PDU session request 418 to 5gc 407 along with the generated session IDs for creating a single session to be distributed among the selected devices.

This step 418 corresponds to steps 1, 2 and 3 of both fig. 5 and fig. 4.3.2.2.1-1 of TS23.502, and alters the 3GPP PDU initiation procedure of TS23.502 by incorporating information of the additional UE ID into the "PDU session establishment request".

In case the decision about the most appropriate distribution of the terminal functions is performed by an entity in the network (416), the request may be performed by the corresponding entity (after network triggered PDU session initiation).

Next, 5gc 407 sends a PDU session trigger message 420 to each terminal/device (WTRU ID) identified in message 418.

The 5GC may use an existing triggering procedure (such as SMS) to perform this step.

Alternatively, as shown in fig. 5 (step 15), the Session Management Function (SMF) may send a trigger message 420 to all corresponding terminals/devices.

Each terminal/device (e.g., 403) receiving the PDU session trigger request (420) sends a PDU session establishment request 422 to the 5gc 407. This is similar to step 16 in fig. 5.

The 5gc 407 establishes a PDU session (e.g., PDU session setup message 424) with the WTRU identified in message 418 (e.g., the discovered WTRU 403) using the same session ID. Thus, the corresponding device is added to the same PDU session. This is similar to step 17 in fig. 5, where all selected/discovered UEs are added to the same PDU session.

The 5gc 407 also accepts and establishes a PDU session with the master/initiator terminal/device 401 (PDU session setup message 426). This step is similar to step 18 in fig. 5.

The distribution of terminal functions requires that the function status information be synchronized among multiple devices sharing the same PDU session, as shown in step 428. This includes the transfer of function code and other data used by the function. For example, game information for a game processing function in an initial device (e.g., WTRU 401 in fig. 4) must be transferred to a new device (e.g., WTRU 403 in fig. 4) to which the processing function is being transferred. Early synchronization of the state ensures continuity of function execution between the devices and reduces any further disruption that may be incurred by performing state synchronization during function execution.

Execution of the distributed function is initiated/continued by establishing communication between the corresponding functions, as shown in step 430. In one embodiment, the distribution of terminal functions may be performed using standard 5G protocols for PDU sessions, or may be further modified to optimize function distribution and/or discovery.

4. SLA mapping for terminal function distribution

Mobile devices have become increasingly popular and have become the primary choice for consuming content and application experience. The popularity of these devices with various capabilities (e.g., content presentation devices such as televisions and projectors) has increased due to recent advances in the form factors of the various devices. However, in the case of a consuming experience (e.g., a single experience), the user may be limited to the initial device being used for the experience, even though there may be better devices becoming available around the user during execution (e.g., more devices may come into their vicinity as the user moves), which may limit the experience to one device (e.g., often to its mobile device unless the user manually configures and begins/transitions to their other device).

The division of terminal functionality (e.g., audio/video processing, haptic feedback, XR processing) may allow a user to distribute and/or offload one or more specific functions of a terminal device to other devices to be executed for improving the overall experience (e.g., the gaming experience may be transferred to a larger display and better gaming control equipment to improve the user experience). Furthermore, performing computationally intensive functions on a mobile device with scarce resources may result in battery drain. Offloading computationally burdensome functions to other devices may improve battery usage/life of the devices while allowing (e.g., also allowing) enhanced functions of the other devices to be utilized, thereby improving the overall user experience.

In some examples, network resources may be allocated to WTRUs by allocating specific network slices having characteristics (e.g., URLLC, eMBB) that meet WTRU needs. Although a PDU session may include more than one data stream, slices may be assigned/allocated at the level of the PDU session (e.g., one slice per PDU session). If the WTRU needs multiple slices, multiple PDU sessions may be established with a 5G core (5 GC).

Virtualization of terminal functions may enable dynamic flexible management of functions and performance of functions in a distributed manner (e.g., D2D, D2E, D C). This may allow the terminal to better utilize the capabilities of the excess devices available in the network (e.g., ioT, cloud) to improve performance and user experience. The internal functionality of the resulting terminal sub-components may vary, and thus their computational and communication requirements (e.g., requirements) may also vary (e.g., in an interactive gaming scenario, a low-latency processing component may require a higher Service Level Agreement (SLA) than other components). Distributed execution of functions may add inter-device/inter-function communication delays to overall execution, which may affect application/function requirements and in turn the overall user experience. One or more communication mediums used for optimizing functional communication may improve the overall QoS/QoE performed.

For example, in the case of an integrated/non-virtualized/non-split terminal where a single SLA may be assigned to the entire terminal, using only SLA (e.g., single SLA) sets/classes may not address different needs in different functions. Examples are provided herein that ensure that the needs of individual functions are met while maintaining an overall user experience. Assigning/assigning the same SLA to sub-components (e.g., all sub-components) may result in unused/wasted resources due to over-provisioning or unmet functional requirements (e.g., requirements) due to under-provisioning. Slice networking capability may be implemented/allocated in separate functions (e.g., each separate function) prior to distribution for improving both terminal performance and network performance.

Examples are provided herein for distributing network resources in a distributed manner and expanding SLAs on more than one device for a particular service. In one example, referring to fig. 6, a process is provided for distributing terminal functions within a single PDU session using split slices.

Referring to fig. 7, an exemplary distribution process using distributed slices within a single session is provided. As shown in fig. 7, different data flowing within a single session (e.g., a PDU session distributed across multiple devices) may be assigned different slices based on the needs of the functions already divided and distributed across multiple devices (e.g., as opposed to distributing one slice for the entire session). The SLAs may be partitioned (or may also be partitioned) to match the requirements of the partitioned terminal functions.

Referring to fig. 8, an exemplary architecture for terminal function distribution is provided. As shown in fig. 8, device-to-device (D2D), device-to-edge (D2E), and device-to-cloud (D2C) scenarios using terminal function distribution are shown.

In this example, a Function Distribution Slice Selection (FDSS) may be provided. The FDSS function may allow distributed functions of the WTRU with different QoS requirements to connect to the 5G network slice. The FDSS function may collect the distributed WTRU functional QoS requirements based on device discovery and transmit them in the form of a flag to the network. The FDSS functional block may communicate available devices, distributed functions, and SLAs thereof (e.g., as shown in fig. 8) to a Network Slice Selection Function (NSSF) to enable one or more slices to be registered and available for sessions (e.g., single PDU sessions) distributed based on functional SLA requirements. This function may be part of an existing NSSF.

A distribution of functions may be provided. The terminal function distribution layer may relate to virtualization of terminal functions, management of resources (e.g., device local resources and network networks), and/or functional lifecycles. The functions at the various layers of the device stack may be divided into ultimately performing these functions on the network, thereby optimizing the resources and user experience.

A terminal analyzer may be provided. The analyzer may provide functional information (e.g., type of HW function, system call) and runtime information (e.g., runtime CPU and energy utilization) about existing single device functions. Such information may be used, for example, to make functional lifecycle management and resource management decisions by the functional manager and communication manager components. The terminal analyzer may be implemented as an operating system or application layer service having security rights to collect information.

A user context engine may be provided. The user context engine may collect user context information by both: sensors in the device (e.g., user location received via GPS receiver) and other services/applications that provide information about user behavior (e.g., user's calendar). The user context engine may be implemented as an operating system or application layer service with API calls (e.g., REST API calls) to the corresponding sensor software drivers and web services. Continuous collection and storage of such information may result in the use (e.g., overuse) of permanent and non-permanent storage. The user context engine may collect and store information when (e.g., only upon) receiving a request from the function and communication manager component.

A discovery engine may be provided. For offloading device functions, the function distribution layer may discover previously unknown available devices. In the example of a user being mobile, a suitable device for offloading may be found. The discovery engine may provide an API for actively registering/querying available devices (e.g., for the function/communication manager component). Otherwise, the discovery channel may (e.g., also) actively search for devices around the user by periodically scanning the network and then provide the newly discovered devices to the communications manager component. Such information may in turn be used to make functional offloading/distribution decisions. The discovery engine may discover new devices using discovery services provided by a network operator, discovery services provided by a network, or a point-to-point device/network (e.g., bluetooth) discovery method.

A function manager may be provided. The function manager may make lifecycle management decisions for locally running device functions (e.g., turn off functions to save energy). The function manager may make decisions (e.g., also make) regarding offloading/distributing the functions to be performed to the more appropriate discovered devices. The decisions made may optimize the energy efficiency of the local device, the resource utilization of the device and the network, and the overall user experience. Such decisions may be made based on user behavior (e.g., by a terminal context engine), resource consumption (e.g., by an analyzer), and user mobility/device availability (e.g., by a discovery engine).

A communications manager may be provided. The communication manager may be involved in managing interconnectivity between devices providing capability for distributed execution of terminal functions. The communication manager may relate to (e.g., may also relate to) the interconnectivity between management functions themselves. Such procedures may include selecting (e.g., network selection) and managing functional communication media.

A local hub may be provided. An end-user device may provide its resources (e.g., computing resources/display screen) for use by other devices/users in its vicinity. The local hub may provide APIs (e.g., functionality of a discovery engine) for such resource provider devices to register their capabilities or be discovered by other devices in the vicinity of the user (e.g., home, campus, shopping mall). Access to the hub and its APIs (e.g., registration and discovery) may be provided over a wireless network (e.g., wi-Fi). The capabilities and availability information of each registered device may be provided to the local hub during registration and stored in the hub until they are de-registered or a specific registration expiration time elapses. The local hub may operate as a stand-alone entity, without any direct connection with the operator's core network, or it may be connected to the operator's network as a non-3 GPP network for extending the network services of the various operators to the connected devices/terminals.

In various embodiments, methods and processes for mapping SLAs of distributed terminal functions may be provided. The FDSS function may allow distributed functions of the WTRU with different QoS requirements to connect to the 5G network slice. FDSS may enable multiple slices to be registered and used for sessions (e.g., single sessions) that are distributed based on functional SLA requirements. Network-based solutions via NSSF may be scalable (e.g., not limited to just a single session overall QoS requirement, which may vary). The network-based solution via NSSF may (e.g., may also) allow knowledge of different functions from WTRUs to be recorded so that distributed slice selection may be done based on functional requirements (e.g., per functional requirement) and may be more accurate based on defined SLAs.

Referring to fig. 9, a signaling diagram is provided to illustrate an example of SLAs mapping terminal function distribution. In this example, the call flow of the FDSS (e.g., located in the 5G core network) may establish a new slice based on the functional SLA in use. The FDSS may select different slices for a single PDU session, such as a URLLC slice for haptic sessions within the described game scene, an eMBB for interactive video, and a default mixed best effort slice for sensory information capture user environment (e.g., temperature, light, location, etc.). The proposed solution may minimize the need to define multiple hybrid slices and may (e.g., also) address functional requirements (e.g., more specifically) with respect to runtime.

Referring to fig. 10, an exemplary procedure for SLA mapping of distributed terminal functions during a PDU session is provided.

In the example shown in fig. 9 (and referring also to fig. 10), one or more WTRUs register with a 5G system (e.g., a 5G network slice) and establish an initial PDU session. A terminal/device (e.g., WTRU) may be discovered and selected for distribution of terminal functions. A terminal/device that may be used to load untrusted functions may register with (e.g., plug into or publish to) a discovery engine (e.g., in a local hub). The registration process may collect and store WTRU IDs that may be used to uniquely identify WTRUs within a 5G core (5 GC) network. Along with the WTRU ID, the registration device (e.g., each registration device) may provide its computing capabilities (e.g., CPU size, RAM size, functions), networking capabilities (e.g., cellular status), and location information (i.e., GPS coordinates) to the discovery engine. Devices may be registered through an API provided by the discovery engine. Registration may be performed automatically by discovering nearby terminals/devices. The WTRU ID may be (e.g., may also be) a service ID, or any other sharable ID that may be used to identify (e.g., uniquely identify) the terminal/device and/or services/functions therein. In some cases, the WTRU may provide or send the WTRU ID and/or other information of the WTRU (e.g., computing capability, networking capability, and/or location information) to the discovery engine for distribution of terminal functions, which may occur prior to registration with the 5G system, e.g., when the WTRU is not registered/deregistered, and/or when the discovery engine maintains previously stored WTRU information. Active device search may trigger the device to register with the 5G system.

The master/initiating WTRU may send a request from the discovery engine to query for newly discovered/updated terminals/devices. If the discovery engine resides within the same device, then callback or IPC procedures can be used to obtain this information. The primary WTRU may have access permissions in the discovery engine (e.g., in the local hub) to obtain this information. The primary WTRU may automatically receive updates on the newly discovered device. The discovery engine may respond to the primary WTRU with information (e.g., all information) collected in the registration device (e.g., each registration device). The primary WTRU may determine the most appropriate distribution of terminal functions among the devices. When making a function distribution decision, it can use the information collected from the analyzer, user context engine, and discovery engine to decide what function(s) to offload, when (at the appropriate time) to offload, and where (the best device) to offload. The selection of the most appropriate distribution of terminal functions may be performed by an entity within the network (e.g., an application function at the edge).

The master WTRU (e.g., communication manager) may trigger the function distribution procedure by initiating a connection with the selected device. It may first initiate creation of a PDU session by communicating with the 5G core network to be shared among the participating devices (e.g., all participating devices) having different slice maps. The request may include a flag indicator and/or a list of functions (e.g., a list of functions supported by the SLA) for enabling slice mapping performed by the FDSS. These functions can be supported in a number of ways (e.g., including through a new multi-slice single PDU session ID to be shared by the relevant devices (e.g., all relevant devices) supporting the service). As part of the new PDU session establishment, the primary WTRU may generate a new single PDU session ID. The IDs of the selected (or being selected) devices, the list of functions (e.g., SLAs), and the generated PDU session IDs may be provided to a 5GC (e.g., SMF) for use in creating a single session to be distributed among the selected devices.

Session initiation may alter PDU initiation procedures, such as 3GPP PDU initiation procedures, by incorporating information of the additional WTRU ID into the PDU session establishment request. The decision about the most suitable distribution of terminal functions may be performed by an entity in the network. The request may be performed by the corresponding entity (e.g., after network-triggered PDU session initiation). In some cases, the received (e.g., received by 5 GC) information may be transferred or sent to the FDSS.

In some examples, slice selection may be performed by an FDSS (e.g., NSSF). The AMF may provide a list of S-nsais (e.g., SLAs-nsais) for the FDSS (e.g., NSSF) to select an appropriate slice instance that may satisfy the SLA and may distribute the results to the WTRUs.

The AMF may select an SMF from the slice instances provided by the FDSS/NSSF, and the AMF may provide a distributed PDU session ID (e.g., which may be a new distributed PDU session ID) and a WTRU list for which a PDU session instance (e.g., from the same PDU session ID) may need to be established. By using network initiated PDU session establishment, the 5GC may send a PDU session trigger message to terminals/devices (e.g., all terminals/devices) that have registered to the corresponding slice (e.g., WTRU IDs). The 5GC may use an existing triggering procedure (e.g., such as SMS). A Session Management Function (SMF) may send a trigger message to the corresponding terminals/devices (e.g., all of the corresponding terminals/devices).

Terminals/devices (e.g., all terminals/devices) that receive the PDU session trigger request and have registered with the corresponding slice may send a PDU session establishment request to the 5 GC.

Terminals/devices (e.g., all terminals/devices) that have not registered with their corresponding slices may receive WTRU configuration update requests with corresponding slice information.

A terminal/device (e.g., all terminals/devices) that receives a WTRU configuration update request with corresponding slice information may register with its corresponding slice before a new PDU session with the shared PDU session ID is established.

Examples of terminal function distribution and data/information synchronization may be provided. A core network, such as a 5G core network, may accept (or establish) PDU sessions with a provided terminal/device (e.g., WTRU ID) using the same session ID. The corresponding device may be added to a PDU session (e.g., the same PDU session). The 5GC may accept and establish PDU sessions with the master/initiator terminal/device. The distribution of terminal functions may request or require synchronization of function state information between devices. This may include the transfer of function code and other data used by the function. For example, game information for a game processing function in an initial device may be transferred to a new device to which the processing function is transferred. Synchronizing the states in advance may ensure continuity of function execution between the devices and may reduce any further disruption that may be incurred in performing the state synchronization during function execution. Execution of the distributed function may be initiated/continued by establishing communication between the corresponding functions.

Conclusion(s)

Although the features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of non-transitory computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, 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 associated with the software may be used to implement a radio frequency transceiver for the WTRU 102, WTRU, terminal, base station, RNC, or any host computer.

Furthermore, in the above embodiments, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. References to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories in accordance with practices of persons skilled in the art of computer programming. Such acts and operations, or instructions, may be considered to be "executing," computer-executed, "or" CPU-executed.

Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may result in a final transformation of the electrical signal or a reduction of the electrical signal and a retention of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of the signal. The memory location holding the data bit is a physical location having a particular electrical, magnetic, optical, or organic attribute corresponding to or representing the data bit. It should be understood that the exemplary embodiments are not limited to the above-described platforms or CPUs, and that other platforms and CPUs may also support the provided methods.

The data bits may also be maintained on computer readable media including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by the CPU. The computer readable media may comprise cooperating or interconnected computer readable media that reside exclusively on the processing system or are distributed among a plurality of interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the representative embodiments are not limited to the above-described memories, and that other platforms and memories may support the described methods.

In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer readable instructions stored on a computer readable medium. The computer readable instructions may be executed by a processor of the mobile unit, the network element, and/or any other computing device.

There is little distinction between hardware implementations and software implementations of aspects of the system. The use of hardware or software is often (but not always, as in some contexts the choice between hardware and software may become important) a design choice representing a tradeoff between cost and efficiency. There may be various media (e.g., hardware, software, and/or firmware) that may implement the processes and/or systems and/or other techniques described herein, and the preferred media may vary with the context in which the processes and/or systems and/or other techniques are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may opt for a medium of mainly hardware and/or firmware. If flexibility is paramount, the implementer may opt for a particular implementation of mainly software. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Where such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those skilled in the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, by way of example, 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), application Specific Standard Products (ASSPs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), and/or a state machine.

Although features and elements are provided above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this patent application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Functionally equivalent methods and apparatus, other than those enumerated herein, which are within the scope of the present disclosure, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the terms "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" may mean, as referred to herein: (i) A wireless transmit and/or receive unit (WTRU), such as described below; (ii) Any of several embodiments of the WTRU, such as those described below; (iii) Devices with wireless capabilities and/or with wired capabilities (e.g., tethered) are configured with some or all of the structure and functionality of a WTRU, in particular, such as described below; (iii) A wireless-capable and/or wireline-capable device may be configured with less than all of the structure and functionality of a WTRU, such as described below; or (iv) etc. Details of an exemplary WTRU, which may represent any of the WTRUs described herein, are provided with respect to fig. 1A-1D, fig. 2, and/or fig. 3.

In certain representative implementations, portions of the subject matter described herein can be implemented via an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), and/or other integrated format. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and/or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media such as digital and/or analog communications media (e.g., fiber optic cable, waveguide, wired communications link, wireless communications link, etc.).

The subject matter described herein sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Thus, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to, physically mateable and/or physically interactable components and/or wirelessly interactable components and/or logically interactable components.

With respect to substantially any plural and/or singular terms used herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. For clarity, various singular/plural permutations may be explicitly listed herein.

It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). It will be further understood by those with skill in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is contemplated, the term "single" or similar language may be used. To facilitate understanding, the following appended claims and/or the description herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation object by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation object to embodiments containing only one such recitation object. Even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). In addition, in those instances where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). In those instances where a convention analogous to "at least one of A, B or C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B or C" would include but not be limited to systems having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). It should also be understood by those within the art that virtually any separate word and/or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "a or B" will be understood to include the possibilities of "a" or "B" or "a and B". In addition, as used herein, the term "… …" followed by listing a plurality of items and/or a plurality of item categories is intended to include items and/or item categories "any one of", "any combination of", "any multiple of" and/or any combination of multiples of "alone or in combination with other items and/or other item categories. Furthermore, as used herein, the term "group" or "group" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero.

Additionally, where features or aspects of the disclosure are described in terms of markush groups, those skilled in the art will recognize thereby that the disclosure is also described in terms of any individual member or subgroup of members of the markush group.

As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be readily identified as sufficiently descriptive and so that the same range can be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily divided into a lower third, a middle third, an upper third, and the like. As will also be understood by those skilled in the art, all language such as "up to", "at least", "greater than", "less than", etc., include the recited numbers and refer to ranges that may be subsequently divided into sub-ranges as described above. Finally, as will be understood by those skilled in the art, the scope includes each individual number. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, or the like.

Furthermore, the claims should not be read as limited to the order or elements provided, unless stated to that effect. In addition, use of the term "means for … …" in any claim is intended to invoke 35U.S. C. ≡112,6 or device plus function claims format, and any claims without the term "device for … …" are not intended to be so.

Although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.

Throughout this disclosure, those skilled in the art will appreciate that certain representative embodiments can be used in alternative forms or in combination with other representative embodiments.

Although the features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of non-transitory computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, 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 associated with the software may be used to implement a radio frequency transceiver for a UE, WTRU, terminal, base station, RNC, or any host computer.

Furthermore, in the above embodiments, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. References to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories in accordance with practices of persons skilled in the art of computer programming. Such acts and operations, or instructions, may be considered to be "executing," computer-executed, "or" CPU-executed.

Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may result in a final transformation of the electrical signal or a reduction of the electrical signal and a retention of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of the signal. The memory location holding the data bit is a physical location having a particular electrical, magnetic, optical, or organic attribute corresponding to or representing the data bit.

The data bits may also be maintained on computer readable media including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by the CPU. The computer readable media may comprise cooperating or interconnected computer readable media that reside exclusively on the processing system or are distributed among a plurality of interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the representative embodiments are not limited to the above-described memories, and that other platforms and memories may support the described methods.

No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. In addition, as used herein, the article "a" is intended to include one or more items. Where only one item is contemplated, the term "a" or similar language is used. In addition, as used herein, the term "… …" followed by listing a plurality of items and/or a plurality of item categories is intended to include items and/or item categories "any one of", "any combination of", "any multiple of" and/or any combination of multiples of "alone or in combination with other items and/or other item categories. Furthermore, as used herein, the term "group" is intended to include any number of items, including zero. In addition, as used herein, the term "number" is intended to include any number, including zero.

Furthermore, the claims should not be read as limited to the described order or elements unless stated to that effect. In addition, use of the term "apparatus" in any claim is intended to invoke 35U.S. C. ≡112,any claims that do not have the term "means" are not intended to so.

Suitable processors include, by way of example, 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), application Specific Standard Products (ASSPs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), and/or a state machine.

A processor associated with the software may be used to implement the use of a radio frequency transceiver in a Wireless Transmit Receive Unit (WTRU), a User Equipment (UE), a terminal, a base station, a Mobility Management Entity (MME) or an Evolved Packet Core (EPC) or any host. The WTRU may be used in combination with a module, and may be implemented in hardware and/or software including: software Defined Radio (SDR) and other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, and the like,Module, frequency Modulation (FM) radio unit, near Field Communication (NFC) module, liquid Crystal Display (LCD) display unit, organic light emitting diodeOLED) display unit, digital music player, media player, video game player module, internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module.

Although the present invention has been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor/general purpose computer (not shown). In some embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer.

Furthermore, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.

Claims (18)

1. A method implemented in a wireless transmit/receive unit (WTRU), the method comprising:

receiving an identification of a set of devices that can be used to share one or more terminal functions with the WTRU;

selecting at least one device of the set of devices to share terminal functions being performed by the WTRU;

generating a Packet Data Unit (PDU) session Identifier (ID) associated with the terminal function;

transmitting a PDU session request message, wherein the PDU session request message comprises information indicating at least the PDU session ID and a respective identity of each selected device in the set of devices; and

A PDU session setup message is received after the PDU session request message is transmitted.

2. The method of claim 1, the method further comprising:

the terminal functions are distributed in the network with each selected device of the set of devices.

3. The method of claim 1, the method further comprising:

executing the terminal function by the WTRU; and

querying, by the WTRU, a discovery engine for the set of devices available to share the terminal function with the WTRU.

4. A method according to claim 3, the method further comprising:

registering with the discovery engine in a network to indicate availability of the WTRU to share the terminal function with the at least one device in the set of devices.

5. The method of claim 4, wherein the registering comprises transmitting any one of: the identity of the WTRU, information of the computing capabilities of the WTRU, information of networking capabilities of the WTRU, or information of the location of the WTRU.

6. The method of claim 1, the method further comprising:

transmitting function status information of the terminal function to the at least one selected device; and

Communicate with the at least one selected device to share the capabilities of the terminal function.

7. The method of claim 6, wherein the transmission of the functional status information comprises transmission of a functional code.

8. The method of claim 1, the method further comprising:

user context information is stored, and wherein the at least one device in the set of devices is selected based on the stored user context information.

9. The method of claim 8, wherein the user context information comprises at least one of: 1) Data from sensors in the WTRU and 2) user applications in the WTRU.

10. The method of any preceding claim, wherein the one or more terminal functions comprise the terminal function.

11. The method according to any of the preceding claims, wherein the PDU session ID is associated with the one or more terminal functions.

12. The method according to any of the preceding claims, wherein the PDU session ID is shared with the at least one device of the set of devices.

13. A method implemented in a wireless transmit/receive unit (WTRU), the method comprising:

Transmitting a first message to a network, wherein the first message includes information indicating any of: 1) a request for a data session, 2) a WTRU identity to be associated with the data session, 3) a capability of the WTRU, or 4) a request for a service to be provided by the network;

receiving a second message from the network, wherein the second message includes information indicating any one of: 1) the WTRU identity, 2) a slice identity associated with the requested service, or 3) the capabilities of the WTRU; and

a third message is transmitted to the network, wherein the third message includes information indicating a request to register the WTRU identity such that the WTRU is able to use the requested service associated with the slice identity.

14. The method of claim 13, the method further comprising:

transmitting a fourth message to the network using the requested data session, wherein the fourth message includes information indicating 1) the slice identity and/or 2) data for the requested service.

15. The method of claim 13, the method further comprising:

transmitting a PDU session request message to the network, wherein the PDU session is shared among one or more participant devices having different slice maps;

Receiving SLA-based triggers from the FDSS to attach to the respective slice; and

registering with the network to use the respective slice.

16. The method of claim 15, wherein the PDU session comprises a flag indicator for enabling slice mapping performed by the FDSS.

17. The method of claim 15, wherein the SLA-based trigger from the FDSS to attach to the respective slice is identified by a unique ID.

18. A wireless transmit/receive unit (WTRU) comprising a processor, a receiver, a transmitter, and a memory that implement the method of any of claims 1-17.