Methods and devices for processing virtual domains

Abstract

A wireless transmit / receive unit (WTRU) is connected to a first AP, receives domain identifiers, requests corresponding descriptors and receives a list of descriptors. An application on the WTRU requests a list of domains and attributes corresponding to a service name or service group returned by the WTRU. The application selects one or more domains for communication, the WTRU selects corresponding network resources and the application connects to a local service. After moving to a new location, the WTRU connects to a second AP and receives a second set of domain identifiers, selects one domain identifier that matches the request from the application, and provides these to the application connected to the local service with the help of the WTRU.

Description

Background Art

[0001] With the advent of edge computing, a wireless transmit / receive unit (WTRU) can now utilize local services, such as those hosted in a micro data center in an access network or at a user's residence. This can achieve lower latency and higher privacy. An example of a local service that can be served by a server in a micro data center is a user application lifecycle management agent in a multi-access edge computing (MEC) system [Error! Reference source not found.], which serves a representational state transfer (REST) application programming interface (API). This API enables, for example, listing and launching available MEC applications. The root of the API can be specified by a fully qualified domain name (FQDN) such as mec.provider.com. Currently, research is being conducted on the discovery of server instances for such services and the reselection of another server instance when the WTRU is relocated [Error! Reference source not found.].

[0002] Current issues include, for example, not determining how a WTRU should select an appropriate network interface and domain name server (DNS) server; nor determining how to reselect edge services when changing access points and Internet protocol (IP) routers. The present principle aims to solve at least some of these problems. Summary of the Invention

[0003] A method and a wireless transmit / receive unit (WTRU) for receiving a domain identifier corresponding to a domain; receiving a first domain descriptor, each first domain descriptor including a service name or a service group; selecting a first network resource based on a first domain selected by an application running on the WTRU; receiving a second domain descriptor, each second domain descriptor including a service name or a service group; identifying a domain descriptor that exists between the second domain descriptor and the first domain descriptor; and selecting a second network resource based on a second domain selected by an application running on the WTRU, the second domain existing between the first domain descriptor and the second domain descriptor. Brief Description of the Drawings

[0004] In addition, like reference numerals in the drawings indicate like elements, and in which:

[0005] Figure 1A is a system diagram showing an exemplary communication system in which one or more of the disclosed embodiments can be implemented;

[0006] Figure 1B is shown in accordance with one embodiment Figure 1A is a system diagram of an exemplary wireless transmit / receive unit (WTRU) that can be used within the shown communication system;

[0007] Figure 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the Figure 1A illustrated communication system;

[0008] Figure 1D is a system diagram showing another exemplary RAN and another exemplary CN that can be used within the Figure 1A illustrated communication system;

[0009] Figure 2 is a system diagram showing a system according to an embodiment;

[0010] Figure 3 illustrates the implementation of service name / group support on a WTRU according to an embodiment; and

[0011] Figure 4A and Figure 4B together illustrate a service continuity method message flow according to an embodiment of the present principles.

[0012] Exemplary network for implementing the embodiments

[0013] Figure 1A is a schematic diagram showing an exemplary communication system 100 in which one or more of the disclosed embodiments can be implemented. The communication system 100 can be a multi-access system that provides content such as voice, data, video, messages, broadcasts, etc. to a plurality of wireless users. The communication system 100 can enable a plurality of wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, the communication system 100 can 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 multi-carrier (FBMC), etc.

[0014] As Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, 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. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “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), smart phones, laptop computers, netbooks, personal computers, wireless sensors, hotspots 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., remote 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 commercial and / or industrial wireless networks, etc. Any one of the UEs 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU.

[0015] The communication system 100 may further include base stations 114a and / or base stations 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, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, evolved Node Bs, Home Node Bs, Home evolved Node Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, etc. Although each of the base stations 114a, 114b is depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0016] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. 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 a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographical area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0017] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via 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.). Any suitable radio access technology (RAT) may be used to establish air interface 116.

[0018] 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, etc. For example, base station 114a in RAN 104 and 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 air interface 116. 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 Uplink (UL) Packet Access (HSUPA).

[0019] In one embodiment, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement radio technologies 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-A Pro to establish the air interface 116.

[0020] In one embodiment, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which may use New Radio (NR) to establish the air interface 116.

[0021] In one embodiment, the base station 114a in the RAN 104 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 using, for example, the dual connectivity (DC) principle. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0022] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0023] Figure 1AThe base station 114b therein can be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and can utilize any suitable RAT to facilitate wireless connections in a local area such as a business premise, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In an embodiment, the base station 114b and the WTRUs 102c, 102d can 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 can 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 can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106.

[0024] The RAN 104 can communicate with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or Internet protocol voice (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 can provide call control, billing services, location-based services, prepaid calls, Internet connection, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not shown in Figure 1A it, it should be understood that the RAN 104 and / or the CN 106 can communicate directly or indirectly with other RANs using the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104 that can utilize the NR radio technology, the CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0025] CN 106 can also act as a gateway for WTRU 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The other networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the other networks 112 may include another CN that is connected to one or more RANs, which may employ the same RAT or a different RAT as the RAN 104.

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

[0027] Figure 1B is a system diagram showing an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 may include a processor 118, a transceiver 120, transmit / receive elements 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a chipset 136 for a positioning system such as the Global Positioning System (GPS), and / or other elements 138, etc. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0028] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal encoding, 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 can be coupled to a transceiver 120, which can be coupled to a transmit / receive element 122. Although Figure 1B the processor 118 and the transceiver 120 are depicted as separate components, it should be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0029] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., Figure 1A the base station 114a in) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive signals such as IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive RF and optical signals. It should be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0030] Although the transmit / receive element 122 is depicted as a single element in Figure 1B the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0031] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. For example, thus, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0032] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124 and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. The non-removable memory 130 may include random access memory (RAM), read only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from a memory that is not physically located on the WTRU 102 (such as, a server or a home computer (not shown)) and store data in that memory.

[0033] The processor 118 may receive power from a power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0034] 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 instead of the information from the GPS chipset 136, the WTRU 102 may receive location information via an air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with the embodiments.

[0035] The processor 118 may also be coupled to other elements 138, which may include one or more software modules and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, the elements 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, 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, etc. Element 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; geographical location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

[0037] Figure 1C FIG. is a system diagram showing RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 may communicate with WTRU 102a, 102b, 102c via air interface 116 using E-UTRA radio technology. RAN 104 may also communicate with CN 106.

[0038] RAN 104 may include evolved Node Bs 160a, 160b, 160c, but it should be understood that RAN 104 may include any number of evolved Node Bs while remaining consistent with the embodiment. Each of evolved Node Bs 160a, 160b, 160c may include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In an embodiment, evolved Node Bs 160a, 160b, 160c may implement MIMO technology. Thus, evolved Node B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU 102a.

[0039] Each of evolved Node Bs 160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As Figure 1C shown, evolved Node Bs 160a, 160b, and 160c may communicate with each other via the X2 interface.

[0040] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the foregoing elements is 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.

[0041] The MME 162 may be connected to each of evolved Node Bs 162a, 162b, and 162c in the RAN 104 via the S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 may provide control plane functions for handover between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0042] The SGW 164 may be connected to each of evolved Node Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between evolved Node Bs, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0043] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, and 102c with access to a packet switched network such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0044] CN 106 may facilitate communication with other networks. For example, CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, CN 106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and the PSTN 108. Additionally, 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.

[0045] Although the WTRU is described in Figures 1A to 1D as a wireless terminal, it is contemplated that in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface to a communication network.

[0046] In a representative embodiment, the other network 112 may be a WLAN.

[0047] A WLAN in 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 an 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 destined for an STA may reach the AP and may be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, e.g., where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source and destination STA (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode may sometimes be referred to in this document as an “ad-hoc” communication mode.

[0048] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some representative embodiments, for example, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented in the 802.11 system. For CSMA / CA, the STA (e.g., each STA) (including the AP) may listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, the particular STA may back off. Only one STA (e.g., only one station) may transmit at any given time in a given BSS.

[0049] High Throughput (HT) STAs may communicate using a 40 MHz wide channel, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0050] Very High Throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz channels may be formed by combining consecutive 20 MHz channels. The 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels (which 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 divide the data into two streams. Each stream may be separately subjected to Inverse Fast Fourier Transform (IFFT) processing and time - domain processing. These streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80 + 80 configuration described above may be reversed and the combined data may be sent to the Medium Access Control (MAC).

[0051] 802.11af and 802.11ah support operation modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, the channel operation bandwidth and carriers are reduced in 802.11af and 802.11ah. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

[0052] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operation bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or restricted by an STA (which supports the minimum bandwidth operation mode) from all STAs operating in the BSS. In an example of 802.11ah, for an STA (e.g., an MTC type device) that supports (e.g., only supports) the 1 MHz mode, the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, because an STA (only supporting the 1 MHz operation mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the frequency band remains idle and may be available.

[0053] In the United States, the available frequency band for 802.11ah is 902 MHz to 928 MHz. In Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0054] Figure 1DFIG. 0 is a system diagram of 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 via air interface 116. RAN 113 may also communicate with CN 115.

[0055] 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 the embodiment. Each of gNBs 180a, 180b, 180c may include one or more transceivers to communicate with WTRUs 102a, 102b, 102c via air interface 116. In an embodiment, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 180b, 180c may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, 102c. Thus, gNB 180a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU 102a. In an embodiment, gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0056] WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using various or scalable length subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or having an absolute time length that continuously varies).

[0057] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a stand-alone configuration and / or a non-stand-alone configuration. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, 160c such as Figure 1C ). In the stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In the non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with or connect to gNBs 180a, 180b, 180c while also communicating with or connecting to other RANs (such as evolved Node Bs 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node Bs 160a, 160b, 160c substantially simultaneously. In the non-stand-alone configuration, evolved Node Bs 160a, 160b, 160c can be used as a mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.

[0058] Each of gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, 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, etc. As Figure 1D shown, gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

[0059] Figure 1DThe illustrated CN 115 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 data networks (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of 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.

[0060] AMF 182a, 182b may be connected to one or more of gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may serve as control nodes. For example, AMF 182a, 182b may be responsible for authenticating users of WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, etc. AMF 182a, 182b may use network slicing to customize CN support for WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases (such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc.). AMF 162 may provide control plane functions for handover between the RAN 113 and other RANs (not shown) employing other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0061] SMF 183a, 183b may be connected to AMF 182a, 182b in the CN 115 via the N11 interface. SMF 183a, 183b may also be connected to UPF 184a, 184b in the CN 115 via the N4 interface. SMF 183a, 183b may select and control UPF 184a, 184b and configure the traffic routing through UPF 184a, 184b. SMF 183a, 183b may perform other functions such as managing and allocating 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.

[0062] UPF 184a and 184b can be connected via the N3 interface to one or more of gNBs 180a, 180b, 180c in the RAN 113, and these gNBs can provide access to a packet switched network (such as the Internet 110) to WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPF 184a, 184b can perform other functions such as routing and forwarding packets, implementing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0063] The CN 115 can facilitate communication with other networks. For example, the CN 115 can include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108, or can communicate with the IP gateway. Additionally, the CN 115 can provide access to other networks 112 to the WTRUs 102a, 102b, 102c, and the other networks can include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c can be connected to the DNs 185a, 185b via the UPFs 184a, 184b through the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the local data networks (DNs) 185a, 185b.

[0064] In view of Figures 1A to 1D and Figures 1A to 1D In view of the corresponding descriptions, one or more or all of the functions described herein with reference to one or more of the following can be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-b, evolved Node Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein. An emulation device can be one or more devices configured to mimic one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0065] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation 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 simulation device can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.

[0066] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test laboratory and / or a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement tests of one or more components. The one or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data. Detailed Description

[0067] DNS-SD [Error! Reference source not found.] defines a service discovery method that uses DNS, the so-called PTR, and then SRV and TXT records. First, the client sends a DNS PTR request for a given service type, such as _printer._tcp.local. The DNS system replies with the service name, e.g., PrinterName.printer._tcp.local. Then, the client can query the SRV and TXT records associated with the service name. The SRV record query response is the FQDN of the service instance, e.g., myprinter.example.com, which can be resolved to an IP address in another DNS query. The TXT record query response includes a list of key-value pairs that give additional information about the service instance.

[0068] Another common service discovery method on the Internet is to use DNS canonical name (CNAME) records. For example, www.example.com can be aliased as www.example.com using a CNAME record. <cdn-provider>.net, which alias itself can be aliased using another CNAME record to <instance-id> . <cdn-provider>.net。

[0069] The provisioning domain (PvD, [Error! Reference source not found.]) is a consistent group of network configuration information and can represent the network to which a router grants access. The PvD has an identifier (ID) and attributes that are visible to the WTRU and WTRU applications. The WTRU and WTRU applications can use the attributes to select a suitable PvD. Typically, on a PvD-aware WTRU, a listening or client socket opened by a WTRU application can be associated with the PvD ID; as a result of this association, for that connection, the WTRU uses local resources linked to a given PvD, such as a DNS server, DNS cache, network interface, source IP address, next-hop router, etc. The "DNS server" used in this context typically designates a DNS recursive resolver and, more generally, the entry point (first hop) of the WTRU into the DNS system. In the following text, the expressions "DNS server" and "DNS resolver" designate such an entry point.

[0070] The PvD ID should be globally unique (e.g., as an FQDN by hierarchical means or using a statistically unique ID such as a Universally Unique Identifier (UUID)). The explicit PvD is advertised by the network. To handle non-PvD-aware networks, the WTRU can create an implicit PvD, for example, on the basis of a network interface. Although there is no single method to advertise the explicit PvD, in an IPv6 network, a router can use an IPv6 router advertisement to advertise the PvD ID to the host / WTRU, and the host / WTRU can use (secure) HTTP to fetch the remainder of the PvD descriptor as a JavaScript Object Notation (JSON) object [Error! Reference source not found.]. On a PvD-aware WTRU, all operations related to a connection (e.g., a socket), including DNS requests, caching, and interfaces for sending / receiving packets, can be associated with a PvD. Cached DNS records should not be reused between different PvDs. For multipath, all operations on each individual path connection can be associated with a PvD, which can be different for each path connection.

[0071] Two examples of JSON objects representing PvD attributes are provided. Note that other attributes, such as the PvD ID and DNS server IP address, are typically present in the router advertisement and not in the JSON object.

[0072] The first example represents access to a local edge cloud network PvD:

[0073]

[0074] The second example represents a metering connection protected by a captive portal:

[0075]

[0076] The problems and key issues of traditional solutions will be illustrated by two use cases.

[0077] In the first use case, a mobile phone user is playing a video game that discovers and exploits local edge services (e.g., WTRU location service, video stream rendering service, game application instance at the edge, local chat relay, etc.). The mobile device accesses the network through a wireless access point and through an IP router that provides access to a local network (e.g., a micro data center). When the user changes location, the mobile phone connects to another access point (AP), and in some cases can leave the service area of the first edge computing platform (e.g., in the first micro data center) and enter the service area of the second edge computing platform (e.g., in the second micro data center). The mobile phone discovers a new instance of the edge service that is currently in use, located in the second micro data center and accessed using a given set of network resources (AP, IP router, DNS server, etc.). From this point on, the WTRU uses the service instance located in the second micro data center. This transition can be immediate (e.g., the connection to the first instance is disconnected and re-established with the second instance) or gradual (e.g., the WTRU can continue and complete the existing transaction with the first instance and start a new transaction using the second instance). As in the second use case, in the first use case, the AP can be a WiFi or fixed AP provided by an Internet service provider (ISP) or a home / enterprise operator, a 5G gNodeB or other mobile network AP, or a combination of these.

[0078] In the second use case, a camera (or other IoT sensor) on a vehicle (e.g., a drone) is providing a streaming service to an IoT application instance running on an edge computing platform (e.g., in a micro data center). Initially, the camera / WTRU makes itself discoverable to the IoT application, e.g., by registering with the local discovery edge service. Once the IoT application senses the camera / WTRU, it connects to the camera / WTRU and processes the output of the camera / WTRU. When the vehicle changes location, the vehicle's gateway changes its attachment point to another AP, and in some cases leaves the service area of the first micro data center and enters the service area of the second micro data center. The camera / WTRU makes itself discoverable through the local discovery edge service on the second micro data center. A second instance of the IoT application running in the second micro data center discovers the streaming service provided by the camera and immediately starts listening and processing the stream.

[0079] In both of these usage scenarios, the WTRU needs to select appropriate network resources for the WTRU-to-local service connection (such as network interfaces, IP routers, DNS servers, etc.). In addition, the selection must be performed again during the handover from one AP to the next. Preferably, the handover is performed with low latency such that the change in the edge service area is at least hardly noticeable to the gamer and such that the change does not result in any (or only limited) data loss in the IoT flow usage scenario.

[0080] The edge service operator and / or network operator involved before and after the handover can be different. For example, the handover can occur between a 5G network and an enterprise or home network. Additionally, the edge service provider can be a top application provider or a content delivery network (CDN) provider (such as Google, Facebook, Apple, Akamai) that deploys micro data centers at various points in the access and transport networks.

[0081] As shown in the two usage scenarios, there are at least two key issues: selection (key issue 1) and re-selection (key issue 2) of appropriate network interfaces and IP routers to access local services when re-locating. These key issues are applicable to a general Internet architecture, such as where the WTRU is connected via wireless and wired access points, for example using Wi-Fi and Ethernet technologies.

[0082] Since PvD is designed for the WTRU and WTRU applications to select networks other than IP routers based on the attributes associated with these networks, PvD is used as a building block for network access selection and local service discovery. However, PvD does not provide a mechanism for selecting based on service name or service group after the WTRU has re-located and initially selected PvD.

[0083] The first key issue can be described as follows. After attaching to a new AP, when the WTRU is multi-homed and / or can use multiple routers, how should it select network resources (network interfaces, IP routers, DNS servers, etc.) to discover local services? There are conventional methods in layer 2 (802.11aq, 802.11u) for identifying which AP to attach to based on local service identification. However, there is no such method for layer 3 to select a router based on local service identification, such as in a deployment where the WTRU faces multiple (virtual or physical) routers in a separate site (behind one or more APs). The selection of network resources for accessing local services should address the make-before-break (MBB) problem, for example, selecting new network resources for a second local service instance while the first local service instance is still in use, or the break-before-make (BBM) problem, where the connection to the first local service is lost before a connection to the second local service can be established.

[0084] Thus, with respect to the first key issue, a multi-homed WTRU may not be able to select an appropriate set of DNS resolver, network interface, and IP router to discover and connect to a local service instance.

[0085] The second key issue can be described as follows. After attaching to a second AP, the WTRU should be able to select new network resources (e.g., network interface, IP router, and DNS server) within a short time frame to discover a second instance of a local service. Traditional DNS-based methods for local service discovery require setting an unusually low TTL (e.g., 1 second) for some records to ensure that the DNS system is queried again later after the WTRU relocates to the second AP (as opposed to reusing stale but still valid cached records). This can be wasteful and may cause problems because many network elements and software components can interpret or modify the TTL value differently. Additionally, DNS sniffing / interception-based solutions are ineffective in the long term with the deployment of existing encryption-based technologies such as DNS over Datagram Transport Layer Security (DTLS) or Transport Layer Security (TLS), and the evolution of DNS over (e.g., secure) Hypertext Transfer Protocol (HTTP) or QUIC.

[0086] Thus, with respect to the second key issue, a multi-homed mobile WTRU may not be able to select an appropriate set of DNS resolver, network interface, and IP router to discover and connect to a new instance of a local service to which it is already connected.

[0087] In addition, multiple service providers can also benefit from solving these key issues: for example, multiple concurrent edge computing service providers can serve a geographical area and can deploy non-overlapping service areas.

[0088] It should be understood that in addition to the solutions to these key issues, additional mechanisms may be required to fully implement the discovery and connection / reconnection to local services. There are various mechanisms that can be used for service discovery (e.g., DNS CNAME redirection and DNS-SD), but since they are well-known and since the WTRU application can use a transport protocol such as TCP or QUIC to connect to the local service, they will not be described further. Such a WTRU application can be designed to support opening multiple connections to the local service (e.g., using each connection for a discrete number of application layer requests). Such a WTRU application can support multiple concurrent application-level sessions with different local service instances and implement application-level logic to maintain consistency (e.g., completing an ongoing transaction with a first instance and starting a new transaction with a second instance, e.g., maintaining an isolated data view between the instances). Accordingly, the present principle is intended to provide the WTRU application with the necessary information and notifications to perform these (re)connections.

[0089] In at least one embodiment according to the present principle, the WTRU and PvD signaling are enhanced to support associating the PvD to the application connection based on a service name or service group. The WTRU may also send a notification to the WTRU application when a new matching PvD becomes available. The WTRU application can initiate a connection to a new local service instance via the new PvD, possibly concurrently with the connection to the initial local service instance.

[0090] System architecture

[0091] Figure 2 A system diagram of a system 200 according to an embodiment of the principles of the present invention is shown. The WTRU 210 is mobile and continuously associates with different access points 220A, 220B, 220C (APs, which can be wireless or wired access points) present in the same or different physical sites (e.g., base stations or enterprise locations). IP routers 222A, 222B, 222C, 222D for physical or virtual WTRUs present at these sites can provide access to multiple networks, such as including the Internet 240, local networks 2421, 2422, remote networks via VPN (not shown), etc. In some cases, the IP routers 222A, 222B, 222C, 222D can be co-located with the APs 220A, 220B, 220C, and in other cases, they can be hosted on separate network elements. In these networks, the local networks 2421, 2422 can host local service instances 2441, 2442, 2443, such as including local DNS resolvers and / or local service instances (e.g., MEC discovery service instances). The IP routers 222A, 222B, 222C, 222D advertise the networks to which they provide access as PvDs.

[0092] In the system 200, a local service provider (e.g., an edge cloud service provider) deploys local services (e.g., in a micro data center), an access network operator (e.g., a 5G network operator or an enterprise network operator) provides connectivity to these local services, an application provider provides software application components (WTRU applications 250) running on the WTRU, and the applications use the local services. There are generally different operators and service / application providers in the system 200. Note that an entity can have multiple roles, such as being a network operator and a local service provider, or being an application provider and a local service provider.

[0093] The WTRU applications 250 (e.g., games, IoT applications, client MEC applications, components of the MEC platform) can connect to the local services. The WTRU applications 250 store data about the service type (e.g., mec-service-discovery), data about the server FQDN (e.g., 12345.mec-service-discovery.edge.provider.com), or data about the anycast IP address of the server (e.g., 10.10.10.10). For simplicity, this data is referred to as "service name".

[0094] In some cases, multiple local services may be provided by local service providers, where instances 2241, 2442, 2443 exist in local networks 1 and 2, 2421, 2422. If the instances are provided consistently in each local network, these instances can be grouped into a "service group", for example, in Figure 2 in, edge.provider1.com can be a service group including discovery.edge.provider1.com, the MEC discovery service, and rendering.game-abc.edge1.provider.com, the video rendering service for the game.

[0095] In traditional solutions, the WTRU application 250 already needs to know the service name / group (e.g., FQDN) identification to connect to the service instance. According to this principle, the WTRU application 250 can also use the service name / group ID (the same or different from the service name / group ID used for connection) to select the PvD, and thus select the local network, IP router, DNS server for discovering the service instance. The terms "name" and "group" can be used to indicate the granularity level of the service (e.g., "name" can indicate support for a separate WTRU application, while "group" can refer to a platform that supports multiple WTRU applications).

[0096] The access network operator configures the service name and / or group in the provisioning domain (PvD). The new PvD information element (IE) can include the service name / group, service instance ID, and authentication / authorization token. As will be described, several possible encoding methods can be used.

[0097] The WTRU application 250 uses the service name / group and the associated IE to connect to the local service instance simultaneously or sequentially. Reference will be made to Figure 3 to further describe how the WTRU application 250 interacts with other components of the WTRU 210 to achieve this goal. For example, the WTRU application 250 can first connect to the first service instance (e.g., 2441) through AP A, then reconnect to the first service instance and connect to the second service instance (e.g., 2443) through AP B, and finally reconnect to the second service instance through AP C. There may also be interruptions between these connections (e.g., the WTRU can move directly from AP A to AP C, losing connectivity to the first service instance before establishing a new connection to the second service instance). How the WTRU application handles different service continuity scenarios will be further described below; FIG. 4 shows a service continuity method message flow according to an embodiment of the principles of the present invention.

[0098] Multiple instances of local services (with the same service provider) may be available to the WTRU 210 (e.g., initially or later). This is shown in [Error! Reference source not found.], where AP B 220B provides access to local networks 1 and 2, 2421, 2422, and to local service instances inst1 2441, 2442, and inst2 2443. The WTRU 210 provides a list of available PvDs and their attributes to the WTRU application 250. The WTRU application 250 may use this information to select one or more PvDs that the WTRU application 250 wishes to use to access a single local service instance or multiple local service instances simultaneously (e.g., based on application policy).

[0099] When multiple local service providers are available, the WTRU application 250 may use one or the other. The WTRU application 250 may determine the local service provider to use based on PvD information elements, application configuration, currently used service name / group, and / or user input. In an example where the WTRU 210 is attached to AP A 220A, at startup, the WTRU application 250 may need to determine whether to connect to inst1.edge.provider1.com 2441 or inst1.edge.provider2.com 2443, which belong to service groups edge.provider1.com and edge.provider2.com, respectively, both of which exist in PvD net1.edge.op1.com. Since both service groups are available and since (e.g.) edge.provider1.com has a higher priority than edge.provider2.com in the WTRU application configuration, the WTRU application 250 may use PvD net1.edge.op1.com to connect to instance inst1.edge.provider1.com.

[0100] In some embodiments, PvD-based service name / group support is integrated with other service discovery methods, which can improve overall service discovery efficiency and latency. For example, some APs (e.g., AP A, B, and / or C in this example) can use 802.11aq to enable pre-association service discovery. By methods that utilize this principle, such APs can obtain service names / groups from all routers to which the AP is connected, e.g., obtain PvD IDs from Router Advertisements (RAs), and then obtain PvD attributes via Secure Hypertext Transfer Protocol (HTTPS). The AP can use 802.11aq to advertise the obtained service names / groups. The AAP can limit the AP's advertisements to only service names / groups that the AP can authenticate / authorize (e.g., using the AuthToken described herein). The WTRU can select an AP that advertises the desired service names / groups before association.

[0101] Local service information encoding in PvD

[0102] The WTRU application can use the service name to request a connection, where the service name is an identifier for an individual service such as discovery.mec.edge.provider.com, or use the service group to request a connection, where the service group is an identifier for a group of individual services such as edge.provider.com. The decision to use one or the other can be made by the local service provider and / or application developer. Using a coarser granularity (i.e., service group) can simplify application and PvD configuration because it requires fewer identifiers to be exposed in the PvD. One or more service names / groups can be encoded in the PvD. Service names / groups should generally be FQDNs, although they can take other forms such as strings, anycast IP addresses, etc.

[0103] In addition, the service name / group maps to different instances located in different local networks. The instance ID can thus also be encoded in the PvD to identify a specific instance of an individual service or service group. The instance ID can be a string that can be used as a component of an FQDN, can be an FQDN formed with the service name / group as a prefix, or in some cases can be an IP address.

[0104] Note that using service names / groups to enable local service continuity can lead to a new form of attack where an attacker controlling a router advertises a PvD with a well-known service name / group. A WTRU selecting that PvD for a given service may then lose that service (denial of service attack) or connect to the local service under the attacker's control. In an attempt to prevent such attacks, the service name / group advertised in the PvD can be authenticated, for example, by a signature using a private key owned by the service provider, which can be verified by the WTRU application. In addition to the service name / group and other relevant information (e.g., instance ID, service IP address, etc.), the signature can also cover a unique identifier such as the PvD ID.

[0105] According to this principle, the following information elements can be encoded in the PvD ID and / or PvD descriptor:

[0106] ● A service name / group, e.g., FQDN, that uniquely identifies an individual service or service group.

[0107] ● A service instance ID, e.g., FQDN or FQDN component, that uniquely identifies an instance of an individual service or service group.

[0108] ● A token, authToken, that authenticates the service name / group and instance ID as advertised with the service provider's agreement.

[0109] In the following example, the authToken can be a signature of the service provider's PvD ID and service parameters, e.g., based on the string "{"pvdId":" <pvdid>",

[0110] "serviceInstance":"<instance ID>.<service name>"}”.

[0111] The service name / group can exist as a suffix in the PvD ID. For example, the PvD ID can be constructed as <instance> . <service-name set>(e.g., 1234.edge.provider.com). However, since the PvD ID may be an FQDN in a domain controlled by the access network operator and the service name / group may be an FQDN in a domain controlled by the service provider, it may be preferable to explicitly encode the service name / group and the instance ID into the PvD.

[0112] The explicit service name and instance ID can be encoded, for example, as a new attribute, such as the "services" array of a JSON object, where each object contains the explicit service name and instance information. This new attribute can be preferred over reusing existing "name" or "local name" attributes, which are assumed to be free strings that are human-readable. This new attribute can also be preferred over the existing "dnsZones" array, which is assumed to hold the FQDNs of domains, rather than instances. However, the "name", "local name", and "dnsZones" can be used temporarily, for example, in cases where the new "services" array is not supported anywhere.

[0113] In one example, the service name / group and the instance ID are encoded in the PvD ID, and the token is in the PvD descriptor:

[0114]

[0115] In another example, the service name / group, the instance ID, and the token are encoded in the PvD descriptor. They can be encoded in separate fields (first entry, serviceName and serviceInstance), as a single field where the service name / group is a suffix of serviceInstance (second entry). The IP address of the server can be associated with the service instance (third entry). When this field is named "serviceName", it can hold a service name such as "discovery2.mec.edge.provider.com" or a service group such as "edge.provider.com". For example, this can give:

[0116]

[0117]

[0118] In another example, the service name / group can be encoded using the "name" attribute, and the instance ID can be encoded using the "localized name" attribute:

[0119]

[0120] In another example, the service name / group and instance ID can be encoded in the existing "dnsZones" attribute instead of in the new "service" attribute:

[0121]

[0122] Local service-related APIs and WTRU application behavior

[0123] Figure 3 An implementation of service name / group support on a WTRU 300 in accordance with an embodiment of the present principles is shown.

[0124] A (e.g., local) service-based PvD connection can be implemented using a conventional PvD implementation [Error! Reference source not found.]. In a typical PvD implementation, the PvD mechanism is implemented in the OS kernel 310 (e.g., binding PvD and the associated DNS cache to a socket), and a user space program 320 (e.g., pvdd) runs as a daemon to provide an API to local WTRU applications. Pvdd 320 can typically retrieve / create / modify / delete PvD and PvD information elements through the kernel API 315. A new component 330 (e.g., service name / group support library) of the local WTRU application 340 can communicate with pvdd 320 using the existing pvdd user space API 345 to query a list of available PvDs and their attributes, subscribe / unsubscribe to changes in the PvD list, or changes to the attributes of a given PvD.

[0125] The service name / group support library 330 provides an API 335 to the WTRU application 340 that enables operations such as listing the PvDs associated with a given service name / group; subscribing / unsubscribing to changes in the list of available PvDs with respect to the service name / group; subscribing / unsubscribing to changes to the attributes of a PvD with respect to the service name / group. The WTRU application 340 can utilize the service name / group-based PvD API, for example, to discover a suitable PvD to connect to a local service instance and subsequently connect to a new local service instance that becomes available when the WTRU attaches to a new access point.

[0126] Local service continuity scenario

[0127] To initially connect to a local service instance, a WTRU application can request a list of PvD IDs associated with a service name / group (e.g., via a service name / group support library) and obtain PvD attributes for those PvDs. The WTRU application can then select one of the available PvD IDs based on the attributes and based on application and local policies. For example, as already mentioned, the WTRU or application configuration can declare that provider1.com has a higher priority than provider2.com. For example, to select between available instances, the WTRU application can connect to each instance and select the one with the lowest latency. The WTRU application can register callback functions for added / removed PvDs associated with a given service name / group. When the WTRU application is notified of a new matching PvD ID (e.g., when the callback function is called), the WTRU application can use the TAPS API 325 [Error! Reference source not found.] to open a socket associated with that PvD ID and then use that socket to connect to the local service instance. If multiple matching PvDs are available, the WTRU can select a matching PvD based on local policies (e.g., use the PvD available on a fixed interface, then use the WiFi interface, then use the cellular). If no matching PvD is available, the WTRU application can handle this as a failed connection request.

[0128] From this point forward, the WTRU can be mobile and change its point of attachment. The WTRU can discover new PvD IDs at the new point of attachment. Each new PvD can fall into one of the following cases:

[0129] 1. The PvD that matches the service name / group has a different PvD ID and gives access to a different local network, e.g., with a different instance ID.

[0130] 2. The PvD that matches the service name / group has the same PvD ID as the currently used PvD.

[0131] 3. The PvD that matches the service name / group has a different PvD ID than the currently used PvD, but gives access to the same local network, e.g., with the same instance ID.

[0132] 4. A PvD that does not match the service name / group. Since it does not match the service name / group requested by the WTRU application, the WTRU will not notify the WTRU application in this case.

[0133] Regarding Scenario 1: When the WTRU is relocated into the service area of the second local network, the WTRU will obtain access to the second local network via a second PvD that matches the service name / group requested by the WTRU application. The WTRU notifies the WTRU application and provides the second PvD ID and attributes to that WTRU application. The WTRU application can then open a new socket associated with the second PvD ID and initiate communication with the second local service instance using service discovery methods (e.g., DNS requests with pre-configured FQDN, anycast IP address, DNS-SD, etc.). Since the second PvD ID is different from the first PvD ID, a separate DNS cache will be used for this second connection. Thus, there is no problem of expired DNS records.

[0134] Regarding Scenario 2: Two routers providing access to the same local network can advertise the same PvD ID, e.g., following the decision of the network operator. When the WTRU receives a new router advertisement reusing the first PvD ID, the WTRU can update the local context for that PvD ID, e.g., adding the new network interface and the new router IP address to the existing local context for that PvD ID. From the perspective of the local application, the existing connection using that PvD ID is not modified. However, local applications subscribing to modifications of the PvD attributes can be notified of the new network interface and can decide to migrate their connection to the local service via the new network interface (e.g., using the migration feature of the QUIC protocol). The WTRU application can continue to use the same destination IP address for the local service instance.

[0135] Regarding Scenario 3: Two routers providing access to the same local network can advertise different PvD IDs with the same service name / group and the same instance ID, e.g., following the decision of the network operator. The WTRU application perceiving this second PvD ID can decide to continue using the same destination IP address for the local service instance or let the network select a new instance. This decision can be made by the application developer as an application design trade-off: reusing the IP address results in a shorter discovery time of one RTT (relative to the second PvD), at the cost of not letting the network reselect a new instance relative to the second PvD (not letting the network reselect a new instance relative to the second PvD can be preferred in some systems, e.g., to reduce service latency). Thus, depending on the choice, from the perspective of the WTRU application, Scenario 3 can be similar to Scenario 1 (possibly reselecting a new local service instance) or Scenario 2 (maintaining communication with the same local service instance).

[0136] In all cases, the WTRU application shall be designed for PvD-based local service continuity. This includes WTRU applications capable of performing one or more of the following:

[0137] ● Request a connection based on service name / group (e.g., socket) or PvD,

[0138] ● Register for PvD events based on service name / group,

[0139] ● React to PvD events based on service name / group, e.g., when a new matching PvD is found, initiate a new connection to replace or supplement the first connection to the service.

[0140] ● When applicable, associate application state information with the PvD ID or service instance. For example, cached service discovery information obtained from MEC discovery services on a given PvD may not be valid for use on another PvD.

[0141] PvD-based local service continuity process

[0142] Figure 4A and 4B together illustrate a method 400 for PvD-based local service continuity according to an embodiment of the present principle. Figure 4A illustrates the steps of the method until the WTRU 452 has moved to a new location; Figure 4B illustrates the steps after the move. Note that although the figures may appear similar, they relate to different APs, routers, and local networks, except for the WTRU application 450 and the WTRU 452.

[0143] Briefly, the WTRU application connects to a local service instance on local network 1, and after the WTRU is repositioned, the WTRU application connects to a local service instance on local network 2 (simultaneously or sequentially with the first instance). The entities that exchange messages in [Error! Reference source not found.] and [Error! Reference source not found.] have been introduced in [Error! Reference source not found.]. Regarding the non-limiting implementation example in [Error! Reference source not found.], the WTRU entity in [Error! Reference source not found.] includes a kernel, pvdd, and service name / group support library. AP-A and AP-B are fixed or wireless access points, and router 1 and router 2 are IP (e.g., IPv6) routers.

[0144] In step S402, the WTRU 450 attaches to AP-A 460 (e.g., this step may include a WiFi association process, 5G network registration, and / or PDU session establishment).

[0145] In step S404, router 1 462 sends a request or unsolicited RA including the PvD ID to WTRU 452.

[0146] In step S406, WTRU 452 requests PvD descriptors for each PvD from router 1 462 over HTTPS.

[0147] In step S408, for each request, router 1462 (or another network node serving the PvD descriptor) sends the PvD descriptor to WTRU 452, such as a JSON object. The service name / group, service instance ID, authentication / authorization token may be encoded in the PvD ID and / or PvD attributes.

[0148] Although RA is used to convey PvD information (ID and descriptor) in this exemplary process, alternative methods may be used to convey this information. For example, steps S404 - S408 may be replaced, for example, in a 5G system, with the transmission of PvD information via WTRU policies from the PCF. In this case, attachment may not be required before obtaining the PvD information, and thus step S402 may occur later, for example, before step S422. Other modes of PvD information transmission may also be used, including full or partial configuration / caching of the PvD information. Any of these replacements may also be applied to steps S426 - S432.

[0149] Once the WTRU obtains the PvD information associated with a given PvD ID, the WTRU creates a local context that includes the PvD ID, the PvD parameters from the PvD descriptor, and information elements obtained, for example, from a router advertisement associated with the PvD ID or by other means from the network associated with the PvD. Examples of such information elements include source address prefixes, IP addresses of DNS servers, default gateway addresses. The local context parameters associated with the PvD are used for further operations associated with the PvD (e.g., connection establishment).

[0150] In step S410, the PvD-aware WTRU application 450 starts.

[0151] In step S412, the WTRU application 450 requests from WTRU 452 a list of PvDs and attributes that match one or more service names / groups, and registers for events related to the matching PvDs (e.g., added / removed PvDs, changes in attributes, etc.).

[0152] In step S414, WTRU 452 obtains the current list of PvDs and matches the PvDs based on the requested service name / group.

[0153] In step S416, the WTRU 452 provides the matching PvD ID and associated attributes to the WTRU application 450.

[0154] In step S418, the WTRU application 450 can verify the authenticity of the service name / group and instance ID, for example, using the authToken attribute. The WTRU application 450 that uses the PvD attribute selects one or more PvDs for its communication.

[0155] In step S420, the WTRU application 450 opens a socket (not shown) associated with the selected one or more PvD IDs.

[0156] In step S422, the WTRU 452 selects network resources (including some of the network interface, DNS server and cache, default IP router, etc.) based on the associated PvD. At this time, the WTRU application 450 can communicate with the local network 1 464. The WTRU application 450 discovers and / or connects to local service instances on the local network 1 464.

[0157] In step S424, the WTRU 452 moves to a new location.

[0158] Note that the WTRU may lose the connection to the initial local service instance on the first PvD (BBM case), or it may still be able to communicate with the network 1 via AP-A or AP-B for some time (MBB case).

[0159] As described, the method is now shown in Figure 4B shown.

[0160] Steps S426 - S432 are similar to steps S402 - 408, but for another AP 470 and router 472: The WTRU452 attaches to AP-B 470 and obtains PvD information from router 2 472.

[0161] In step S434, the WTRU 452 detects a PvD in the new PvD that matches the requested service name / group, and in step S436, the WTRU 452 notifies the WTRU application 450 and provides it with the matching PvD ID and attributes.

[0162] In step S438, the WTRU application 450 can verify the authenticity of the service name / group and instance ID, for example, using the authToken attribute. The WTRU application 450 uses the service name / group and instance ID to select the PvD it wishes to use and the WTRU application behavior. As already described, different cases include:

[0163] 1. New PvD ID, different instance IDs (e.g., connected to the same or different local networks): For example, discover and then open a new concurrent connection to a new local service instance on local network 2.

[0164] 2. Same PvD ID, new interface / router: For example, perform a connection migration towards the same local server (e.g., perform a QUIC connection migration if using QUIC, or start using a new path if using MPTCP or MPQUIC).

[0165] 3. New PvD ID, same instance ID (e.g., typically when connected to the same local network): For example, use the same destination IP address and typically different source IP addresses to open a new concurrent connection to the same local server using the new PvD ID. Or, in another example, use the new PvD ID to discover and connect to a second local server. In the last example, the second local server can be the same as the first server or a new server determined by the DNS service.

[0166] In step S440, the WTRU application 450 opens a socket associated with one or more newly selected PvDs.

[0167] In step S442, the WTRU 452 selects network resources (e.g., including network interfaces, DNS servers and caches, default routers, etc.) based on the associated PvD. At this time, the WTRU application 450 can communicate with local network 2 474. The WTRU application 450 discovers and / or connects to local service instances on local network 2 474.

[0168] Although the features and elements have been described above in specific combinations, those 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. Additionally, the methods described herein can be implemented in a computer program, software, or firmware embodied 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 can be used to implement a radio frequency transceiver for the WTRU 102, UE, terminal, base station, RNC, or any host computer.

[0169] In addition, in the above embodiments, processing platforms, computing systems, controllers, and other devices including processors are pointed out. These devices may include at least one central processing unit ("CPU") and a memory. According to the practice of those skilled in the field of computer programming, references to actions and operations or instructions in symbolic representation may be executed by various CPUs and memories. Such actions and operations or instructions may be considered to be "executed", "computer-executed", or "CPU-executed".

[0170] Those of ordinary skill in the art will know that actions and operations or instructions in symbolic representation include the manipulation of electrical signals by the CPU. Electrical systems represent data bits, which may result in the ultimate transformation or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and performing other processing of the signals. A memory location for retaining data bits is a physical location having a specific electrical, magnetic, optical, or organic property corresponding to or representing the data bits. It should be understood that the representative embodiments are not limited to the above platforms or CPUs, and other platforms and CPUs may also support the provided methods.

[0171] Data bits may also be retained on a computer-readable medium, which includes 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 systems readable by the CPU. The computer-readable medium may include cooperative or interconnected computer-readable media that exist uniquely on a processing system or are distributed among multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that the representative embodiments are not limited to the above memories, and other platforms and memories may also support the described methods.

[0172] In an illustrative 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 a mobile unit, a network element, and / or any other computing device.

[0173] There is little difference between the hardware implementation and the software implementation in various aspects of the system. The use of hardware or software is generally (but not always, as the choice between hardware and software may become important in certain contexts) a design choice representing a trade-off between cost and efficiency. There may be various media (e.g., hardware, software, and / or firmware) that can implement the processes and / or systems and / or other technologies described herein, and the preferred medium may vary with the context of the deployment process and / or system and / or other technology. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a medium that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0174] The foregoing detailed description has set forth various embodiments of the devices and / or processes by use of block diagrams, flowcharts, and / or examples. In cases where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented, individually and / or jointly, by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, by way of illustration, general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application specific integrated circuits (ASICs), application specific standard products (ASSPs), field programmable gate array (FPGA) circuitry, any other type of integrated circuit (IC), and / or state machines.

[0175] Although the features and elements have been provided above in a particular combination, those of ordinary skill in the art will understand that each feature or element can be used separately 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 to be illustrative of various aspects. Many modifications and variations can be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly so provided, any element, act, or instruction used in the specification of this application should not be construed as critical or essential to the invention. Based on the foregoing description, functional equivalent methods and devices within the scope of the present disclosure, other than those enumerated herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of such equivalents of those claims that are entitled to the benefits thereof. It should be understood that the present disclosure is not limited to a particular method or system.

[0176] In certain representative embodiments, several portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may equivalently be implemented in integrated circuits as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and / or firmware would be entirely within the skill of those in the art in light of this disclosure. Additionally, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal bearing medium used to actually effect such 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 tape, computer memory, etc.; and transmission type media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0177] The subject matter described herein is sometimes shown with different components included within and / or connected to different other components. It should be understood that such depicted architectures are merely examples, and in fact many other architectures may be implemented to achieve the same functionality. In a conceptual sense, any arrangement of components that achieves the same functionality is effectively "associated" such that the desired functionality can be achieved. Thus, any two components combined herein to achieve a particular functionality can be seen as being "associated" with each other such that the desired functionality is achieved, regardless of the architecture or intervening components. Similarly, any two components so associated can also be seen as being "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components that can be so associated can also be seen as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to, components that physically mate and / or physically interact and / or components that wirelessly interact and / or wirelessly interact and / or components that logically interact and / or can logically interact.

[0178] Regarding substantially any plural and / or singular terms used herein, those skilled in the art may appropriately convert from the plural to the singular and / or from the singular to the plural, as may be contextually and / or applicationally appropriate. For clarity, various singular / plural permutations may be explicitly set forth herein.

[0179] Those skilled in the art should understand that, generally speaking, the terms used in this text, especially in the appended claims (e.g., the subject matter of the appended claims), are usually intended to be "open-ended" terms (e.g., the term "comprising" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "containing" should be interpreted as "containing but not limited to", etc.). Those skilled in the art should also understand that if the intention is to specify a particular number of introduced claim recitation objects, such intention will be explicitly recited in the claim, and in the absence of such recitation, there is no such intention. For example, in cases where only one item is contemplated, terms such as "single" or similar language may be used. To assist understanding, the appended claims and / or the description herein below may include the use of introductory phrases "at least one" and "one or more" to introduce claim recitation objects. However, the use of such phrases should not be construed as implying that any particular claim containing such introduced claim recitation objects is limited to an embodiment containing only one such recitation object by the indefinite article "a" or "an" introducing the claim recitation object. This is the case even when the same claim includes an introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). This also applies to the use of the definite article for introducing claim recitation objects. Additionally, even when a particular number of introduced claim recitation objects is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted as meaning at least the stated number (e.g., in the absence of other modifiers, a bare recitation of "two recitation objects" means at least two recitation objects, or two or more recitation objects). Additionally, in those instances where a convention similar to "at least one of A, B, and C, etc." is used, generally speaking, the meaning of such construction is that those skilled in the art will understand the convention (e.g., "a system having at least one of A, B, and C" will include but not be limited to a system having A alone, having B alone, having C alone, having A and B simultaneously, having A and C simultaneously, having B and C simultaneously, and / or having A, B, and C simultaneously, etc.). In those instances where a convention similar to "at least one of A, B, or C, etc." is used, generally speaking, the meaning of such construction is that those skilled in the art will understand the convention (e.g., "a system having at least one of A, B, or C" will include but not be limited to a system having A alone, having B alone, having C alone, having A and B simultaneously, having A and C simultaneously, having B and C simultaneously, and / or having A, B, and C simultaneously, etc.). Those skilled in the art should also understand that, in fact, regardless of whether in the specification, the claims, or the drawings, any separate words and / or phrases presenting two or more alternative terms should be understood as contemplating the possibility of including one of the terms, any one of the terms, or both of the terms.For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B". Additionally, as used herein, the term "any of" followed by a listing of multiple items and / or multiple categories of items is intended to include the item and / or category of items "any of", "any combination of", "any multiple of", and / or "any combination of multiples of" individually or in combination with other items and / or other categories of items. Further, as used herein, the terms "group" or "groups" are intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[0180] Additionally, in instances where the features or aspects of the present disclosure are described in terms of a Markush group, those skilled in the art will recognize that the present disclosure is also described in terms of any individual member or subgroup of members of the Markush group.

[0181] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all ranges disclosed herein also cover any and all possible sub-ranges and combinations of their sub-ranges. Any listed range can be readily identified as fully describing and enabling the same range to be divided into at least equal halves, thirds, fourths, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as "up to", "at least", "greater than", "less than", etc. includes the recited number and refers to a range that can subsequently be divided into sub-ranges as described above. Finally, as those skilled in the art will understand, a range 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, etc.

[0182] Furthermore, unless otherwise indicated, the claims should not be construed as limited to the order or elements provided. Additionally, the use of the term "means for" in any claim is intended to invoke 35 U.S.C.§112, 6 or the means-plus-function claim format, and any claim without the term "means for" is not intended to be so.

[0183] A processor associated with software can be used to implement the use of a radio frequency transceiver in a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME), or evolved packet core (EPC), or any host. The WTRU can be used in combination with modules and can be implemented in hardware and / or software including the following components: software defined radio (SDR) and other components such as cameras, video camera modules, videophones, speakerphones, vibrating devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, modules, frequency modulation (FM) radio units, near field communication (NFC) modules, liquid crystal display (LCD) display units, organic light emitting diode (OLED) display units, digital music players, media players, video game player modules, Internet browsers, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

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

[0185] In addition, although the present invention has been shown and described with reference to specific embodiments herein, the present invention is not intended to be limited to the details shown. Instead, various modifications can be made to the details within the scope and range of equivalents of the claims without departing from the present invention.

[0186] Throughout the disclosure, those skilled in the art should understand that certain representative embodiments can be used in alternative forms or in combination with other representative embodiments.

[0187] Although the features and elements have been described above in specific combinations, those 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. Additionally, the methods described herein can 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 software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0188] In addition, in the above-described embodiments, processing platforms, computing systems, controllers, and other devices including processors are pointed out. These devices may include at least one central processing unit ("CPU") and a memory. In accordance with the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions may be executed by various CPUs and memories. Such actions and operations or instructions may be considered to be "executed", "computer-executed", or "CPU-executed".

[0189] Those of ordinary skill in the art will appreciate that actions and symbolic representations of operations or instructions include the manipulation of electrical signals by a CPU. Electrical systems represent data bits, which may result in the ultimate transformation or reduction of electrical signals and the retention of data bits at memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of the signals. Memory locations that retain data bits are physical locations having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits.

[0190] Data bits may also be retained on a computer-readable medium, which includes 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 systems readable by a CPU. The computer-readable medium may include cooperative or interconnected computer-readable media that exist solely on a processing system or are distributed among multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that the representative embodiments are not limited to the above memories, and other platforms and memories may also support the methods described.

[0191] Suitable processors include, by way of example, general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0192] In addition, while the invention has been shown and described with reference to specific embodiments herein, the invention is not intended to be limited to the details shown. Instead, various modifications may be made to the details within the scope and range of equivalents of the claims without departing from the invention. < / instance> < / pvdid> < / instance-id>

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receiving a supply domain identifier corresponding to a supply domain and a first supply domain descriptor, each first supply domain descriptor including a service name or a service group; Receiving, from an application running on the WTRU, at least one requested service name or service group; Providing to the application a supply domain identifier that matches the at least one requested service name or service group; Selecting a first network resource based on a first supply domain selected by the application; After WTRU repositioning, receiving a second supply domain descriptor, each second supply domain descriptor including a service name or a service group; Providing to the application a second supply that matches the at least one requested service name or service group; And Selecting a second network resource based on a second supply domain selected by the application.

2. The method according to claim 1, the method further comprising: The application using the first network resource to connect to a first service instance corresponding to the requested service name or service group; And The application using the second network resource to connect to a second service instance corresponding to the requested service name or service group.

3. The method according to claim 2, wherein the first service instance is the same as the second service instance.

4. The method according to claim 2, wherein each of the first supply domain descriptor and the second supply domain descriptor further includes an instance identifier, and wherein the method further comprises: Determining, based on the service name or the service group and the corresponding instance identifier, whether to connect to a service instance having the first service identifier or to a service instance having a new instance identifier using the second network resource.

5. The method according to claim 1, the method further comprising: Requesting the first supply domain descriptor corresponding to the first supply domain identifier.

6. The method according to claim 1, wherein the first supply domain descriptor and the second supply domain descriptor further include at least one of an instance identifier and an authentication or authorization token.

7. The method according to claim 1, the method further comprising: Receiving, from the application, a first request for a first list of supply domains and supply domain attributes that match at least one service name or service group in the request; Providing to the application the first list of supply domains and supply domain attributes that match at least one service name or service group in the first request.

8. The method according to claim 7, the method further comprising: The application verifying the authenticity of at least one received service name or service group; And the application selecting at least one supply domain to communicate with based on the service name or service group.

9. The method according to claim 8, the method further comprising: The application notifying the WTRU of the at least one selected supply domain.

10. The method according to claim 1, the method further comprising: The WTRU connecting to a second network element different from a first network element that provided the first supply domain descriptor to the WTRU; Wherein the second supply domain descriptor is received after connecting to the second network element.

11. A wireless transmit / receive unit (WTRU), the WTRU comprising: A memory that stores processor-executable program instructions; And At least one hardware processor configured to execute the program instructions to: Receive a supply domain identifier corresponding to a supply domain and a first supply domain descriptor, each first supply domain descriptor including a service name or a service group; Receive at least one requested service name or service group from an application running on the WTRU; Provide the application with a supply domain identifier that matches the at least one requested service name or service group; Select a first network resource based on a first supply domain selected by the application; After the WTRU is relocated, receive a second supply domain descriptor, each second supply domain descriptor including a service name or a service group; Provide the application with a second supply that matches the at least one requested service name or service group; And Select a second network resource based on a second supply domain selected by the application.

12. The wireless transmit / receive unit according to claim 11, wherein the at least one hardware processor is further configured to: The application uses the first network resource to connect to a first service instance corresponding to the requested service name or service group; and The application uses the second network resource to connect to a second service instance corresponding to the requested service name or service group.

13. The wireless transmit / receive unit according to claim 12, wherein the first service instance is the same as the second service instance.

14. The wireless transmit / receive unit according to claim 12, wherein each of the first supply domain descriptor and the second supply domain descriptor further includes an instance identifier, and wherein the at least one hardware processor is further configured to determine whether to use the second network resource to connect to a service instance with the first service identifier or to a service instance with a new instance identifier based on the service name or the service group and the corresponding instance identifier.

15. The wireless transmit / receive unit according to claim 11, wherein the at least one hardware processor is further configured to: Request the first supply domain descriptor corresponding to the first supply domain identifier.

16. The wireless transmit / receive unit according to claim 11, wherein the first supply domain descriptor and the second supply domain descriptor further include at least one of an instance identifier and an authentication or authorization token.

17. The wireless transmit / receive unit according to claim 11, wherein the at least one hardware processor is further configured to: Receive from the application a first request for a first list of supply domains and supply domain attributes that match at least one of the service names or service groups in the request; Provide the application with the first list of supply domains and supply domain attributes that match at least one of the service names or service groups in the first request.

18. The wireless transmit / receive unit according to claim 17, wherein the at least one hardware processor is further configured to verify the authenticity of at least one received service name or service group and select at least one provisioning domain to communicate with based on the service name or service group.

19. The wireless transmit / receive unit according to claim 11, wherein the at least one hardware processor is further configured to connect to a second network element different from the first network element that provides the first provisioning domain descriptor to the WTRU; wherein the second provisioning domain descriptor is received after connecting to the second network element.

Images