Edge application instance discovery and selection based on shared application vertical session

Abstract

In one or more embodiments, one or more devices, systems, and / or methods can provide solutions and / or innovations for 5G system edge computing, edge applications, and / or other wireless systems. For example, edge application instance discovery and selection based on shared application vertical sessions can be handled using one or more of the following techniques: there can be an application vertical session identifier; one or more application vertical session based EAS registration, discovery, and selection procedures; application vertical session based EDN / EES orchestration; and / or application vertical session management.

Description

[0001] This application is a divisional application of Interactive Digital Patent Holding Co., Ltd., filed on March 23, 2023, with application number 202380017198.1, entitled "Invention for Discovery and Selection of Edge Application Instances Based on Shared Application Vertical Sessions".

[0002] Cross-references to related applications

[0003] This application claims the benefit of U.S. Provisional Application Serial No. 63 / 323,396, filed on March 24, 2022, the contents of which are incorporated herein by reference. Summary of the Invention

[0004] In one or more implementations, one or more devices, systems, and / or methods may provide solutions and / or innovations for 5G systems, edge computing, edge applications, and / or other wireless systems. For example, one or more of the following technologies may be used to handle edge application instance discovery and selection based on shared application vertical sessions: the existence of application vertical session identifiers (also referred to as “group identifiers”); one or more application vertical session-based EAS registration, discovery, and selection processes; application vertical session-based EDN / EES provisioning; and / or application vertical session management.

[0005] In one or more embodiments, a server-implemented method includes: receiving information related to a public application from a plurality of wireless transmit / receive units (WTRUs); transmitting a public multi-user group identifier (ID) to the plurality of WTRUs in response to receiving the information; receiving a request indicating the public multi-user group ID; and transmitting an indication of one or more server instances associated with the public multi-user group ID.

[0006] In one or more embodiments, a method implemented by a wireless transmit / receive unit (WTRU) includes: transmitting a message indicating a public multi-user group identifier (ID) to a server; receiving an indication of one or more server instances associated with the public multi-user group ID; and connecting to the one or more server instances.

[0007] In one or more embodiments, a server is configured to: receive information related to a public application from a plurality of wireless transmit / receive units (WTRUs); in response to receiving the information, transmit a public multi-user group identifier (ID) to the plurality of WTRUs; receive a request indicating the public multi-user group ID; and transmit an indication of one or more server instances associated with the public multi-user group ID.

[0008] In one or more embodiments, a WTRU is configured to: transmit a message indicating a public multi-user group identifier (ID) to a server; receive an indication of one or more server instances associated with the public multi-user group ID; and connect to the one or more server instances.

[0009] In one or more embodiments, a server-implemented method includes: receiving from a Wireless Transmit-Receive Unit (WTRU) a request that one or more Edge Application Server (EAS) instances be configured to run sessions shared by application clients located on the WTRU and at least one other session shared by application clients located on the WTRU or another WTRU; and associating the one or more EAS instances with a multi-user group ID.

[0010] In one implementation, a server is configured to: receive from a Wireless Transmit-Receive Unit (WTRU) a request for one or more Edge Application Server (EAS) instances to be configured to run sessions shared by application clients located on the WTRU and at least one other session shared by application clients located on the WTRU or another WTRU; and associate the one or more EAS instances with a multi-user group ID. Attached Figure Description

[0011] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein similar reference numerals in the drawings indicate similar elements.

[0012] Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments.

[0013] Figure 1B This is an example of an implementation scheme that can be implemented. Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the illustrated communication system.

[0014] Figure 1C This is an example of an implementation scheme that can be implemented. Figure 1A System diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the illustrated communication system.

[0015] Figure 1D This is an example of an implementation scheme that can be implemented. Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the illustrated communication system.

[0016] Figure 2 An example of a system architecture for edge computing between a device and an edge data network is illustrated.

[0017] Figure 3 An example of the EAS registration process is shown.

[0018] Figures 4a to 4b An example of the EAS discovery process is shown.

[0019] Figure 5 An example is given of several EAS deployed in different locations within the same EDN.

[0020] Figure 6 An example of the EAS registration, discovery, and selection process based on application vertical sessions is provided.

[0021] Figure 7 An example of EAS discovery notifications based on application vertical sessions is shown.

[0022] Figures 8a to 8b An example of service dispatch is shown.

[0023] Figure 9 An example of EES dispatching and selection based on application vertical sessions is shown.

[0024] Figure 10 An example of EES dispatch notification based on application vertical sessions is shown.

[0025] Figure 11 An example created using AVS with an edge-enabled layer is shown.

[0026] Figure 12 This is a flowchart illustrating an example of a method for setting up server instances and multi-user group identifiers (IDs) for public applications.

[0027] Figure 13 This is a flowchart illustrating an example of a method for accessing one or more server instances associated with a public application using an associated public multi-user group identifier (ID).

[0028] Figure 14 This is a flowchart illustrating an example of a method for configuring one or more Edge Application Server (EAS) instances to run sessions shared by multiple application clients on one or more WTRUs and associating one or more EAS instances with a multi-user group identifier (ID). Detailed Implementation

[0029] As listed in Table 1 below, one or more of the following abbreviations and / or acronyms may be used.

[0030]

[0031]

[0032] Table 1—Example Acronyms

[0033] Figure 1A This is a diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0034] like Figure 1A As shown, the communication system 100 may include wireless transceiver 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, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any one of which may be referred to as a "station" (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, 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 industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0035] The communication system 100 may also include base stations 114a and / or 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be transceiver base stations (BTS), Node Bs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation Node Bs (such as gNode Bs (gNBs)), new radio (NR) Node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0036] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable 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 one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one 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 desired spatial directions.

[0037] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0038] More specifically, as noted above, the 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 stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the 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).

[0039] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0040] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0041] In one implementation, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use the dual connectivity (DC) principle together to implement LTE radio access and NR radio access. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

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

[0043] Figure 1A Base station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

[0044] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs among WTRUs 102a, 102b, 102c, and 102d. 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. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1AAs shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0045] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

[0047] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. For example... Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

[0048] Processor 118 may be a general-purpose processor, a special-purpose 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), any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0049] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF signals and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0051] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals to be received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

[0052] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) 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, keypad 126, and / or display / touchpad 128. Furthermore, 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 such suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in such memory.

[0053] The processor 118 may receive power from the 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.), solar cells, fuel cells, etc.

[0054] 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) about 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 from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0055] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functionality, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. 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. Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0056] 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 DL (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 through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 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 DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0057] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

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

[0059] Each Evolved Node B in Evolved Nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0060] 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 (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

[0062] The SGW 164 can connect to each of the evolved Node Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can 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, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0063] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0064] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0065] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0066] In a representative implementation, the other network 112 may be a WLAN.

[0067] A WLAN in Infrastructure Basic Services 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 interfaces to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP, for example, where a source STA can transmit traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

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

[0069] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0070] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped to two 80MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0071] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. 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 batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0072] WLAN systems supporting multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if other STAs in the AB and BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (which only supports a 1MHz operating mode) is transmitting to the AP, all available frequency bands may be considered busy even if most available bands remain idle.

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

[0074] Figure 1DThis is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0075] RAN 104 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 104 may include any number of gNBs while maintaining consistency with the implementation. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0076] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with an expandable set of parameters. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various or expandable lengths or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0077] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of the gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as evolved Node B 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node B 160a, 160b, and 160c. In a non-standalone configuration, evolved Node B 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0078] Each gNB in ​​gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0080] AMF 182a and 182b can connect to one or more gNBs (gNBs) 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c; supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements); selecting specific SMF 183a and 183b; managing registration areas; terminating Non-Access Stratum (NAS) signaling; and mobility management. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for switching between RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0081] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0082] UPF 184a and 184b can connect via the N3 interface to one or more gNBs (180a, 180b, 180c) in RAN 104. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

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

[0084] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the functions described in one or more of the following items, which may be performed by one or more emulation devices (not shown): WTRU102a to 102d, base stations 114a to 114b, evolved Node B 160a to 160c, MME 162, SGW 164, PGW 166, gNB180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other devices described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0085] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices may perform one or more functions 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. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. For testing and / or performing tests using over-the-air wireless communication, the simulation device may be directly coupled to another device.

[0086] One or more emulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios within test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform tests on one or more components. One or more emulation devices may be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0087] Figure 2 An exemplary architecture 200 for enabling edge applications is illustrated. Typically, the system aspect of a wireless system (e.g., SA6) provides standardized application layer architecture specifications for vertical domains, including architectural requirements, functional architecture, processes, information flow, interoperability with non-3GPP application layer solutions, and / or appropriate deployment models. As shown in the figure, exemplary architecture 200 has several components, which are further discussed in Table 2 below.

[0088]

[0089] Table 2— Figure 2 Exemplary components of an exemplary architecture

[0090] In some cases, application service providers or edge computing service providers may deploy multiple instances of Edge Application Servers (EAS) 204 within a single Edge Data Network (EDN) 206 or across several EDCs. EAS 204 can provide application-level specific functionality to application clients (ACs) 202 on endpoints (e.g., WTRU 203). ACs 202 can connect to EAS 204 to leverage the available services of the application and the benefits of edge computing. A single AC 202 can be associated with one and only one Edge Enabled Client (EEC) 210.

[0091] The Edge Enable Layer (EEL) can provide one or more identifiers for AC 202 and EAS204, as shown in the examples in Table 3 below.

[0092]

[0093] Table 3—Exemplary Identifiers for AC 202 and EAS204

[0094] Such as Figure 3 The exemplary registration process 300 shown, such as the EAS204 registration process, enables an EAS instance to notify, update, and / or delete its information to the EEL via EES208, allowing AC 202 to discover it. An EAS204 instance may register with one (e.g., in some cases only one) EES208, provided that EAS information is described in the EAS configuration file. The EAS204 configuration file may or may not include information that uniquely identifies the EAS instance. For example, the EAS204 endpoint element within the EAS204 configuration file can be used to provide information for AC 202 to communicate with the EAS. The EAS204 endpoint can be an identifier, such as an FQDN or URI, that can be shared with multiple EAS instances. Additionally, the EAS204 configuration file may not include any information identifying any application vertical session or AC 202 instance that a given EAS may be serving or available for service.

[0095] EAS discovery process (such as in...) Figure 4a and Figure 4b Examples 400 and 402 shown enable EEC 210 to discover EAS204 by interacting with EES208 in EDN 206. EEC 210 may select one or more discovered EAS204s and expose the selected EASs to AC 202. Discovery of EAS204 may be based on matching the EAS discovery filters provided by EEC 210 with the EAS profiles registered at EES208. For example, some EAS204 discovery procedures may include: synchronous query (request-response process); and / or asynchronous notification (subscription-notification process). Figure 4a and Figure 4bThese can be applied to both options separately. Furthermore, for both options, the EAS204 discovery filter can be provided by EEC 210 and may include an AC 202 feature list and / or an EAS feature list. The EAS204 discovery filter may not include any ability to identify a specific instance of the EAS used for the selection or to identify an EAS instance that is being served or can be used to serve a specific application vertical session. As described herein, the EAS204 discovery filter may include one or more informational elements such as: an AC 202 feature list; an AC profile; an EAS204 feature list; an EASID; an EAS provider identifier; an EAS type; an EAS scheduler; an EAS geographic service region; an EAS topology service region; service continuity support; a service license level; and service characteristics. One or more of these filters may be optional, and one or more of these filters may be mandatory.

[0096] In some cases, the EEL may not define how AC 202 registers with or identifies EEC 210 via the EDGE-5 reference point using EAS204 discovery / selection parameters. In other cases, (pre-)configured parameters may exist. For example, it may be necessary to determine how AC 202 provides EEC 210 with the information required to identify the appropriate EAS204 instance (specifically, its AC profile) for connection, in order to meet the current and future needs of such wireless systems. The AC 202 profile may not include any application-vertical session or context information or EAS instance identification information used for EAS discovery and selection for communication.

[0097] Figure 5 Examples of several EAS204s deployed in different locations within the same EDN 206 are illustrated (in... Figure 5 The examples are labeled EAS-1A, EAS-1(B), and EAS-1(C), although this example considers fewer or more than three EAS instances. For many applications, if a group of AC 202 instances are participating in a shared application vertical session or context, they may need to interface with a public EAS204 instance. This can include the same WTRU 203 or a separate WTRU 203 (in the context of a single user or multiple users and connected to a public EDN 206 or a different EDN 206) for a single user or multiple users. Figure 5 The WTRUs are labeled WTRU1, WTRU2, and WTRU3, although this example considers AC 202 on fewer or more than three WTRUs.

[0098] In some cases, the EEL may not provide any ability to discover and select a common EAS204 for a group of AC 202 or WTRU 203. This can be a problem and may need to be addressed through one or more of the methods discussed in this document, such as discovering a common EAS204. This problem may raise one or more questions: First, do and how do AC 202 / EEC 210 for different users (e.g., different WTRU 203) select or configure the same EAS204 within EDN 206? Second, even if EEC 210 initially communicates with a different EDN 206, do and how do AC 202 / EEC210 for different users (e.g., different WTRU 203) select or configure a common EAS204? Third, does and how does the EEL support business continuity to ensure that when AC 202 needs to use services from a common EAS204 and requires ACR operation, the ACR operation can be coordinated so that after the ACR operation is completed, the AC again has the services provided by the common EAS.

[0099] In one or more embodiments, the above questions can be addressed herein.

[0100] Table 4 below lists, in a non-exhaustive manner, some examples of application verticals that require a set of AC 202 / WTRU 203s to participate in shared application vertical sessions with public EAS 204 instances.

[0101]

[0102]

[0103] Table 4—Examples of application verticals typically requiring a set of AC 202 / WTRU 203 instances to participate in shared application vertical sessions with public EAS204 instances.

[0104] One or more methods may exist for discovering and selecting public EAS instances. Within an instance (e.g., specifically for a multiplayer game), each AC 202 on all WTRUs 203 participating in the game instance can learn the identifiers and locations of all other WTRUs in the game. Each EEC 210 can transmit this information (e.g., a list of WTRUs 203 with locations) to an EES 208 for public EAS 204 discovery. This approach may require sharing sensitive information (e.g., identifiers and locations) with all ACs 202 and WTRUs 203, which could pose security and privacy risks when players are unknown and untrusted. Furthermore, this implementation does not allow a single WTRU 203 (e.g., a game console or hub device) to participate in two or more separate game sessions served by different EAS 204 instances.

[0105] In the second instance, for EAS204 discovery targeting different users, there may be differences in EEL services, focusing on how the ECSP provides edge service quality levels (e.g., premium users versus regular users). EAS204 can provide EES208 with a list of WTRU 203 identifiers that can be used in EAS selection / discovery. This list can be used to match WTRU 203s in the list with public EAS204 instances. However, this may expose sensitive information (e.g., WTRU 203 identifiers) at the application level (EAS204). How EAS204 learns the set of WTRU 203 identifiers may still need to be addressed. Finally, this approach does not allow a single WTRU 203 (e.g., a game console or hub device) to participate in two or more separate game sessions served by different EAS204 instances.

[0106] Traditionally, EAS204 discovery and selection do not consider any information about application-vertical sessions. An application-vertical session is a group of ACs 202 and EAS204 participating in a broader application-vertical deployment (e.g., a public multi-user, multi-device, or multi-client session). In this case, EAS204 discovery and selection may only consider non-application-vertical session information, such as EAS type (EASID), AC type (ACID), service KPIs (e.g., bandwidth, request rate, response time, etc.), EEC ID, WTRU 203 identifier, etc. Therefore, performing these traditional EAS204 discovery and selection processes independently for each AC 202 and EEC 210 provides little or no guarantee that a group of ACs participating in a public application-vertical session can receive services from a public EAS204.

[0107] Therefore, there is a need to address technologies for discovering public EAS204 instances (e.g., how different users' ACs / EECs select or are deployed to the same EAS). Addressing any additional drawbacks may also be relevant, such as: when the technology requires sharing privacy and security-sensitive information such as the identifier of WTRU 203 and the location of WTRUs at the application level (with AC 202, EAS204, and application layer servers in the cloud); and when the technology does not differentiate between the application vertical session level and the AC 202 level (e.g., limiting the ability of a single AC on a single device to interact with a single EAS204 instance). In considering these drawbacks, additional factors may also need to be addressed, such as: how to enable different ACs 202s located on the same or different WTRUs 203s and of the same or different types to participate in public application vertical sessions; how to discover and select public EAS204 instances of a group of ACs 202s participating in an application vertical session while maintaining privacy (i.e., not exposing sensitive information such as the identifiers and locations between ACs, EASs, or WTRUs 203s); and how the EEL assists in creating application vertical sessions.

[0108] In one or more implementations, the aforementioned issues / questions may be addressed in one or more devices, systems, and / or methods. For example, one or more of the following techniques may be used to handle edge application instance discovery and selection based on shared application vertical sessions: the existence of application vertical session identifiers; one or more application vertical session-based EAS204 registration, discovery, and selection processes; application vertical session-based EDN / EES provisioning; and / or application vertical session management.

[0109] The Application Vertical Session Identifier (ASVID) identifies a "public multi-user session" and can be used by the EEL to assist in the management of application vertical sessions, including the discovery and selection of public EAS204 (or public EAS groups) for the group of AC 202s participating in the session. "Multi-user" can include any combination of AC 202 and EEC 210 on one or more WTRU 203s. It does not necessarily mean a human user, although it can be a human user.

[0110] Application-vertical session-based EAS204 registration, discovery, and selection is an enhanced EEL process that specifically takes ASVID as input. During registration (including updates), the application-vertical session-enabled EAS204 signals the EEL (e.g., EES208) to the application-vertical session identifier that the EAS is serving. Similarly, AC 202 can signal the EEL (e.g., EES208) to which application-vertical sessions the client (AC) will participate in via EEC 210. Using the application-vertical session identifier, EEC 210 and EES208 can potentially match AC / WTRU EAS204 discovery and selection requests with the appropriate EAS instance serving the requested application-vertical session.

[0111] Application-vertical session-based EDN / EES provisioning is an enhanced process in which WTRU 203 selects EDN 206 for connection based on the application-vertical session request from AC 202 of that WTRU. ECS 212 can utilize the availability of the application-vertical sessions served by EAS 204 to select a combination of EDN 206 and EES 208 for EEC 210. If EAS 204 is unavailable to serve the application-vertical session in EDN 206 according to the provisioning request, ECS 212 can signal to the subscribed EEC 210 via a service provisioning notification if EAS later becomes available to serve the requested application-vertical session.

[0112] Application vertical session management is the process that allows WTRU 203 to create application vertical sessions in the EEL and allows other WTRUs to be aware of the application vertical sessions available in the EEL.

[0113] Figure 6 An example of an EAS204 registration, discovery, and selection process 600 based on application vertical sessions is illustrated. As shown in the figure, the EEL can support the interconnection between AC 202 on WTRU 203 and the appropriate EAS204 instance serving its application vertical session via an enhanced EAS registration, discovery, and selection process. An overall process flow with operational examples is presented in the figure.

[0114] The benefit of these enhancements is that they enable AC 202 and / or EEC 210 to discover and select not only EAS204s that provide a specific type of service, but also EAS204s associated with a specific instance of the service. Without this feature, AC 202 and / or EEC 210 might not be able to discover and connect to the application vertical session that the AC wants to join (e.g., a game AC might not be able to connect to the application vertical session of another AC serving the same game).

[0115] like Figure 6 As shown, an exemplary process 600 exists where AC 202 discovers an EAS204 instance serving its application vertical session. Initially, at 602, one or more prerequisites may exist: at the application level, an application vertical session can be created, and an application vertical session ID (AVSID) can be assigned to identify the session. In this example, two application vertical sessions are created, one with AVSID="A" and the other with AVSID="B". Note that "A" and "B" are examples used only to illustrate related technologies and may differ in one or more other implementations based on this disclosure. These AVSIDs may be distributed across the service EAS204 and consuming AC 202 at the application level. In other words, AC 202 may receive AVSIDs in messages from EAS204, the application server, or EEL (if the EEL has such capabilities). If an AVSID is unavailable and needs to be created, the application vertical session AVSID can be created via the EEL using the application vertical session management methods described herein.

[0116] At 604a and 604b, each EAS204 may register with its EES208 and provide its service AVSID, for example via the application vertical session enhancement EAS profile described herein (e.g., Table 5). The EES208 may store the EAS-AVSID relationship to match EEC 208 requests discovered for EAS204 with service EAS or EAS groups. For example, Figure 6 The diagram illustrates EAS1 registered with AVSID="A" and EAS2 registered with AVSID="B". EAS1 and EAS2 may share a common EVSID or have different EVSIDs. EAS204 may have obtained its AVSID from another server (such as a matching server hosted in the cloud or EDN206). Alternatively, the AVSID may have been pre-configured in EAS204, for example, via a configuration file or during EAS orchestration; alternatively, the AVSID may have been provided by an EEL, assuming that the EEL has such capabilities.

[0117] At point 606, when AC 202 needs to interface with EAS 204 serving its application vertical session, the AC can request EAS discovery from EEC 201 and provide its associated application vertical session ID. In this example, ACx 202 on WTRUx 203 requests EAS discovery for AVSID="A". Alternatively, ACx 202 can implicitly trigger EAS discovery at EEC 210 by registering with the EEC and providing the AVSID in the registration. ACx 202 may have obtained the AVSID from a pre-configured profile, from user input, from a matching server hosted in the cloud or in an edge data network, or from EEC 210 (assuming that EEC has such capabilities).

[0118] At 608, EEC 210 can process EAS204 discovery or AC 202 registration requests from AC and transmit the EAS204 discovery request to an EES208 capable of serving the requested application vertical session, including an enhanced AC profile (e.g., as described herein) within the EAS discovery filter. EEC 210 can select the EES208 to serve the application vertical session based on the enhanced AC 202 profile (e.g., the AC profile described herein).

[0119] At 610, upon receiving an EAS204 discovery request, EES208 may perform a lookup of registered EASs that match the EAS request, including finding EASs that match the requested AVSID and selecting only the EAS associated with that AVSID. In the example shown, EES208 selects EAS1 serving AVSID="A". Although this example shows a single EAS204 instance, AC 202 may be served by a group of EASs serving the same AVSID="A".

[0120] At 612, EES208 responds to EEC 210 using the selected EAS204 endpoint and the AVSID that EAS is serving in the enhanced service session context in the EEC context, as disclosed herein.

[0121] At 614, EEC 210 can then respond to request AC 202 using the selected EAS204 endpoint and the AVSID that EAS is serving.

[0122] At 616, application client (AC) 202 can connect to the selected EAS 204 and join an application vertical session. In the illustrated example, ACx 202 on WTRUx 203 connects to EAS1 204 and joins an application vertical session with AVSID="A".

[0123] For 606 to 616, these steps can be repeated for each AC 202 and WTRU 203 participating in the application vertical session.

[0124] At 618, if EAS204 is serving more than one application vertical session, the AVSID can be appended to the application traffic request to differentiate the flow based on the AVSID.

[0125] Figure 7 An example of EAS204 discovery notification 700 based on application vertical sessions is illustrated. The EAS204 discovery subscription / notification process disclosed herein provides a method for asynchronously notifying EEC 210 of the availability of EAS in EDN 206. As shown in the figure, an example of an application vertical session enhanced process for EAS discovery subscription and notification exists. This process can be useful when no EAS204 instance is available to serve AVSID in the EAS discovery request response, as described earlier in this document. EES 208 can use application vertical session enhanced EAS discovery notification to notify EEC 210 of the dynamic availability of EAS204 that can serve one or more application vertical sessions of interest.

[0126] Initially, one or more prerequisites may exist. An application-vertical session can be created, and an AVSID can be assigned to identify that session. When registering with the EEC or requesting EAS204 discovery for the AVSID, the AVSID may be provided to the EEC 210, for example, by AC 202. The EEC 210 may attempt to synchronize the EAS discovery request process (e.g., Figure 6 Furthermore, EES208 may not have any EAS204 available to serve the requested AVSID.

[0127] At 702, EEC 210 can create an application-vertical session with EES208, an EAS204 discovery subscription (e.g., as described herein), thereby providing a set of AVSIDs (e.g., as disclosed herein) in the EAS discovery filter or in the EAS dynamic information filter.

[0128] At 704, later, EAS204 can be instantiated in EDN 206 to serve application vertical sessions identified by its corresponding AVSID. EAS204 can register with EES208 and provide its service AVSID, for example, via a defined enhanced EAS profile (e.g., as disclosed herein).

[0129] At 706, EES208 can use the EAS204 registration information and evaluate that information against the EAS discovery subscription filter, such as the AVSID from the subscription created at 702. EES208 can determine that a notification needs to be sent to EEC 210 because the AVSID matches the subscription request.

[0130] At 708, EES208 can transmit EAS discovery notifications to subscribed EEC 210 and include application vertical session enhancement EAS profiles (e.g., as disclosed herein).

[0131] At 710, EEC 210 can notify AC 202 of EAS204, providing the EAS endpoint and the AVSID that the EAS is serving. AC 202 can then connect to the selected EAS204 and join the application vertical session.

[0132] Figure 8a and Figure 8b An example of service provisioning is illustrated. Typically, within the EEL, EEC 210 can utilize the services of ECS212 to discover EDN 206 and EES208, which can then satisfy the requirements of AC202 on WTRU 203 via a service provisioning process. In some cases, EDN 206 / EES208 service provisioning may consider EAS204 and AC202 type information (e.g., EASID and ACID) from the AC profile. However, in other cases, EDN 206 / EES 208 service provisioning may not consider any application-specific session information. This could lead to EEC 210 / AC 202 discovering EES208s available for WTRU203 in different EDNs 206 without knowing which EAS 204 / EDN 206 can provide the required application vertical session; therefore, there is a problem that EEC 210 must perform EAS204 discovery with each EES212 iteration until the EEC finds an EAS that supports its required AVSID. To resolve this issue, it may be beneficial to discover concurrently signaling the availability of EDN 206 and its EES208 associated with the requested AVSID, where the EAS 204 within such EDN serves or can serve these requested AVSIDs.

[0133] The benefit of this enhancement is that it allows AC 202 and EEC 210 to discover EDN 206 and EES 208, which are available to reach not only EAS 204, which provides a specific type of service, but also EDN and EES, which are available to reach EAS associated with a specific instance of a service (e.g., serving an application vertical session). Without this feature, AC 202 and EEC 210 might not be able to discover and connect to the application vertical session that AC 202 wants to join (e.g., a game AC would not connect to EAS 204, which serves a game match identified by one or more specific AVSIDs).

[0134] At 802a and 802b, EEC 210 sends a service provisioning request or service provisioning subscription request to ECS212.

[0135] Figure 9 An example of an EES208 provisioning and selection process 900 based on an application vertical session is illustrated. This example describes EDN 206 / EES208 service provisioning in an EEC 210 request-response model. In this model, EEC 210 requests EES208 service provisioning for its requested AVSID. ECS 212 can provision EES208 / EDN 206 services for EEC 210 to serve its requested AVSID.

[0136] Initially (not shown), one or more prerequisites may exist. An application vertical session can be created, and an application vertical session ID can be assigned to identify the session. The AVSID can be provided to EEC 210, for example, by AC 202, when registering with EEC 210 or requesting EAS204 discovery for the AVSID.

[0137] At position 902, EEC 210 may transmit a service provisioning request to ECS 212. This service provisioning request may include a set of AC 202 profiles (e.g., as disclosed herein) with the AVSID of the application vertical session used for the AC request.

[0138] At 904, upon receiving the service provisioning request, ECS212 can perform an authorization check. Using an enhanced AC profile provided by EEC 210, including an AVSID (e.g., as disclosed herein), ECS212 can identify and select EES208 and its associated EDN 206 that can serve the request from the application vertical session from AC 202. EES208 can provide ECS212 with EAS204 and the AVSID that it serves in its EDN 206 using an enhanced EES profile (e.g., as disclosed herein) from its EES registration (not shown).

[0139] At 906, ECS212 can return a service provisioning response with an enhanced EDN 206 configuration that includes a list of EES208s with EAS204s and AVSIDs that each EES can serve (e.g., as disclosed herein).

[0140] At 908, the EEC 210 in WTRU 203 can use the enhanced EDN 206 configuration to select an EES208 / EDN 206 that can serve the AC 202 of WTRU (including its application vertical sessions) and perform an EEC 210 registration request to the selected EES, including the AC 202 profile with AVSID (e.g., as disclosed herein).

[0141] At position 910, EES208 can verify EEC 210 registration requests. Using an AC profile with an AVSID, EES208 can determine whether the service request can be fulfilled.

[0142] At position 912, EES208 may return an EEC registration response to EEC 210, including the EEC context ID. The EEC context ID may refer to an enhanced EEC context instance in EES208 (e.g., as disclosed herein).

[0143] Figure 10 An example of an EES208 provisioning notification process 1000 based on an application vertical session is illustrated. This example addresses EDN / EES service provisioning in the EEC 210 subscription notification model. This model can be used to asynchronously notify EEC 210 of the availability of EES208 and EDN 206. In this enhanced process, ECS212 can notify EEC 210 via notification when EAS204 (e.g., serving the requested AVSID) becomes available in EDN 206 and can be discovered via EES208.

[0144] Initially (not shown), one or more prerequisites may exist. An application vertical session may be created, and an application vertical session ID may be assigned to identify the session. When registering with the EEC or requesting EAS204 discovery for an AVSID, for example, the AVSID may be provided to EEC 210 by AC202. EEC 210 may have attempted to enhance the service provisioning request-response model (e.g., as described herein) and found that no EDN 206 and EES208 are available for the requested AVSID.

[0145] At position 1002, EEC 210 may transmit a service provisioning subscription request to ECS 212. This service provisioning subscription may include a set of AC profiles (e.g., as disclosed herein) that provide the AVSID for the application vertical session requested by AC 202.

[0146] At positions 1004 and 1006, ECS212 can create a subscription to EEC 210 and store the requested AC profile along with its AVSID.

[0147] At 1008, (for example, later) EAS204 can be instantiated in EDN 206 to serve application vertical sessions identified by its corresponding AVSID.

[0148] At 1010, in order to notify the EEL of its information, EAS204 may register with EES208 and provide its service AVSID, for example, via an enhanced EAS profile (e.g., as disclosed herein). EES208 may store the relationship between EAS and AVSID in order to match EEC 210 requests discovered for EAS204 with the service EAS.

[0149] At 1012, EES208 may register with or update its registration with ECS212, thereby providing an enhanced EES profile (e.g., as disclosed herein) that includes the EAS204 available to EES208 referenced by its EASID and the AVSID that EAS204 may be serving.

[0150] At 2014, ECS212 can process new or updated EES208 registration information, including EASIDs with associated AVSIDs. ECS212 can determine, based on information received from the EEC in 1002, whether any service provisioning notification needs to be sent to EEC 210 to signal the availability of AVSIDs in EDN 206 / EES208.

[0151] At 1016, ECS212 can issue a service provisioning notification to any EEC 210 that needs to know the availability of AVSIDs from 1014. This service provisioning notification can deliver an enhanced EDN 206 configuration that includes a list of EES208s with EAS204s and AVSIDs available for service for each EES (e.g., as disclosed herein).

[0152] At 1018, to provide AC 202 with access to the ASVID service EAS204, EEC 210 / WTRU 203 can connect to EDN 206 using the enhanced EDN configuration received in 1016. This may include establishing a new PDU session to EDN 206 (if an existing PDU session is unavailable) or updating an existing PDU session. EEC 210 may register with EES208 as indicated in 1016, including an AC 202 profile with the ASVID (e.g., as disclosed herein).

[0153] At 1020, after EEC 210 registers with EES208, EEC can discover EAS204 serving the required AVSID and provide its information to requesting AC 202 (e.g., as disclosed herein).

[0154] At 1022, using the EAS204 information provided by EEC 210 (e.g., the enhanced EAS profile described herein), AC 202 can connect to the selected EAS204 and join the application vertical session.

[0155] For one or more implementations disclosed herein, an enhanced data model may exist for vertical sessions applied to the edge enablement layer. The AC profile may contain information about AC 202. EEC 210, EES208, and ECS212 can use this AC profile to provision WTRU 203 for EEL services. ECS212 can use this AC profile to select which EES208 to use for provisioning WTRU 203. EES208 can use this AC profile to select the EAS204 instance for EAS discovery. EEC 210 can provide AC 202 with EAS endpoint information about the selected / available EAS204 instance. The EAS profile can be enhanced to include AVSID. Table 5 illustrates examples of AC profiles for applying vertical sessions.

[0156]

[0157]

[0158] Table 5—Examples of AC profiles for applying vertical session enhancement

[0159] The EAS204 configuration file may include information used by the EES208 to discover and select EAS instances based on requests from EEC 210. The EES208 may store an EAS configuration file for each registered EAS204. The EAS configuration file can be enhanced to include an AVSID used to identify the sessions served by the EAS204. Table 6 illustrates an example of applying vertical session enhancements to the EAS configuration file.

[0160]

[0161]

[0162] Table 6—Examples of EAS configuration files for applying vertical session enhancement

[0163] The EES configuration file can include information about EES208 and the services it provides. The EES configuration file can be enhanced to include the AVSIDs of application vertical sessions supported by EES208. Table 7 illustrates examples of application vertical session enhancements to the EES configuration file.

[0164]

[0165]

[0166] Table 7—Examples of EES configuration files for applying vertical session enhancement

[0167] The service session context can be enhanced to include an application-specific vertical session identifier for use with the service session context. Table 8 illustrates examples of application-specific vertical session enhancements to the EEC context.

[0168]

[0169] Table 8—Examples of applying vertical session enhancement to EEC context

[0170] EDN configuration information types can be enhanced to include AVSIDs from the "EES List". This information can be used to signal to EEC 210 which application vertical sessions are served by EECs within EDN 206 (via EAS204) and can be discovered via EES208. EDN configuration can be used in ECS212 service provisioning for both request-response and subscription-notification models. Table 9 illustrates examples of enhanced EDN configuration information for application vertical sessions.

[0171]

[0172]

[0173] Table 9—Examples of EDN configuration information for applying vertical session enhancement

[0174] The EAS204 dynamic information filter can be enhanced to notify EEC 210 of dynamic changes (indicated by AVSID) of application vertical sessions served by EAS204 via EAS discovery subscriptions. Table 10 illustrates examples of enhancing the EAS dynamic information filter for application vertical sessions.

[0175]

[0176] Table 10—Examples of applying vertical session enhancement EAS dynamic information filters

[0177] The Application Vertical Session Identifier (AVSID) can be formatted such that it is a combination of multiple identifiers or pieces of information. For example, an AVSID may include: a service provider identifier; a unique number associated with a vertical session or context information fragment; an authorized service identifier, which can be used as a trusted third party to verify that AC 202 / EEC 210 is authorized to provide the AVSID (e.g., as previously described, the AVSID and therefore the authorized service identifier may be provided to the AC via application layer interaction with the service provider, wherein the authorized service identifier may be pre-assigned or pre-negotiated with the mobile network operator); one or more PLMN identifiers that identify the PLMN that can be used to access the service; and / or one or more ECS210 identifiers that can be used to allocate information about EDN 206 and EES208, which can be used to discover EDNs and EESs that can be used to reach the EAS204 associated with the session.

[0178] In one or more embodiments disclosed herein, security issues and solutions may exist, such as security associated with AVSIDs. In some cases, tokens can be used by EEC 210 to authorize access to EES208. Since multiple EAS204s can register to the same EES208, when an authorization token for EES208 access authorization is issued from ECS212 to EEC 210, the token may contain an AVSID to bind the authorization to an EES / AVSID pair. Otherwise, AC 202 / EEC 210 can access EES208 information associated with EAS204s that have different AVSIDs. In some cases, session key bindings to AVSIDs may exist. If a security association is established to protect communication between AC 202 / EAS204 after AC is authorized to access EAS, a session key used for security protection of the communication channel between AC / EEC and EAS can be bound to EAS using an AVSID (e.g., the AVSID should be included as an input parameter when derived from a session key).

[0179] In one or more embodiments disclosed herein, management techniques for application vertical sessions (AVS) may exist. Application vertical session management may require EEL to provide support for creating and deleting AVS. AVS creation may be required when AC 202 or EEC 210 initiates an AVS, or AVS creation may be useful for pre-provisioning AVS before use. As in some embodiments discussed herein, AVS and AVSID may be known at EAS204 or AC 202. Additionally or alternatively, techniques for provisioning AVSIDs using an edge enable layer may also exist.

[0180] Figure 11An exemplary process 1100 created using an edge-enabled AVS layer is illustrated. Within this exemplary process, a method exists for creating an application vertical session provided by the edge-enabled layer.

[0181] Initially, at 1102, EEC 210 may exist on the first WTRU 203 (e.g., EEC1) and perform the EAS204 discovery process described herein; thus, the EEC can obtain a list of EAS that meet the EEC criteria specified in the EAS discovery request. The EAS204 discovery request may contain AVSIDs that EEC1 210 can attempt to discover, in which case it may not accept any EAS in the list (e.g., if the AVSID does not exist). In this use case, EEC1 210 does not provide an AVSID and receives a list of existing EAS204s.

[0182] At 1104, EEC1 210 can initiate AVS creation, which in EEC1 means obtaining the parameters required to create an AVS in EEL. For example, this action can be triggered by a request issued by AC 202 using EEC1 210; or, for example, by a user; or, for example, by a predefined AVS configuration existing at WTRU1 203; or, for example, by receiving a message such as an SMS; or, for example, by another external source such as another WTRU 203 or a server. In any case, the information required to create the AVS can be provided by the source that triggered the AVS initiation. AVS parameters may include an AVS identifier (AVSID) that uniquely identifies the AVS source, a friendly AVS name that allows users to identify the AVS, a list of users or terminals allowed to join the AVS, a maximum number of users allowed to join the AVS, the location (e.g., geographical or topological) where the AVS can be used, and / or the duration the AVS will exist.

[0183] At 1106, EEC1 210 may send an EAS204 selection request to EES208 to indicate its intention to use EAS; EEC1 may include AVS parameters in the request to indicate to EES that it needs to create an AVS.

[0184] At 1108, upon receiving an EAS204 selection request with AVS parameters, EES208 may store the AVS parameters in, for example, the EEC context, and may assign an AVSID if no AVSID is included in the EAS selection request. This AVSID can be used to uniquely identify the AVS. Alternatively, in some systems, if no suitable EAS is available, the EAS204 selection request may trigger the instantiation of the EAS. In this case, the AVS parameters are not required; they may include the AVSID configured in 1110 through EAS204 orchestration and AVS notification messages.

[0185] At 1110, EES208 can notify the newly created AVS to the selected EAS204. Although Figure 11 As not shown, EAS204 may have subscribed to EES208 to receive AVS management events in a manner similar to that used for subscribing to ACR management events as described herein. AVS notifications may include AVS parameters. If EAS204 can support the newly received AVS, it may store the AVS parameters and AVSID and return a success indication to EES208. If the notification does not include an AVSID, EAS204 may create an AVSID to uniquely identify the AVS. If EAS204 cannot support the newly received AVS, it may not store these parameters and return an error indicating failure to EES208.

[0186] At 1112, if EAS204 can support the newly received AVS, the EAS can use the newly received AVSID to perform a registration update of its EAS configuration file at EES208. Alternatively, if EAS204 is instantiated at 1108, it can perform this operation by performing EAS registration with EES208.

[0187] At 1114, EES208 may transmit an EAS204 selection response to EEC1 210. This response may include the following information elements: the result of the EAS204 selection and / or the AVSID. If the AVS is not successfully created, the EAS204 selection response may contain an error message indicating the reason for the failure. Upon receiving the AVSID, EEC1 210 may store the AVSID and notify AC 202.

[0188] At 1116, AC 202, which exists on the first WTRU 203, connects and begins exchanging application traffic with EAS204 associated with AVSID.

[0189] At 1118, EEC 210 may exist on a second WTRU 203 (e.g., EEC2 210 is instantiated thereon) and may perform the EAS discovery process described herein; thus, EEC may obtain a list of EAS204 that satisfy the EEC criteria specified in the EAS discovery request.

[0190] EEC2 210 may have received the AVSID from the first WTRU 203: for example, it may have received the AVSID from a request issued by AC 202 using EEC2 (e.g., an AVSID exchanged between ACs); or, for example, it may have received the AVSID from a user; or, for example, it may have received the AVSID from a message such as an SMS; or, for example, it may have received the AVSID from an external source such as another WTRU 203 or a server. In this case, EEC2 210 may include the AVSID in the EAS discovery request, and EES 208 may use the AVSID to identify the EAS 204 hosting the AVS and return the address of the EAS hosting the AVS to EEC2.

[0191] Alternatively, EEC2 210 may not have an AVSID, where EEC2 sets a flag in the EAS discovery request indicating that it wants to discover AVSs available at EES208. EES208 may provide a list of all available AVSIDs in the EAS discovery response and may include some AVS parameters, such as the AVS friendly name; EES may filter the available AVSs returned to EEC2 210 by using WTRU identifier, user identifier, AC identifier, or WTRU location.

[0192] At 1120, after receiving the list of EAS204 from the EAS discovery, EEC 210 can select an EAS. EEC 210 can select EAS 204 based on AVSIDs it may have already received at 1118. If EEC 210 does not know which AVSID to select, it can present a list of available AVSIDs to the user of WTRU 203 for manual selection.

[0193] At 1122, AC 202, which exists on the second WTRU 203, connects and begins exchanging application traffic with EAS204, which serves AVSID.

[0194] Figure 12 This is a flowchart illustrating an example of a method for setting up a server instance and multi-user group identifier (ID) for a public application such as Public Application Client 202.

[0195] At 1202, a server such as an Edge Enabled Server (EES) 208 or an Edge Configuration Server (ECS) 212 receives information related to public applications such as a public application client 202 from multiple WTRUs 203.

[0196] At 1204, in response to receiving this information, the server transmits a common multi-user group identifier (ID) to multiple WTRU 203s.

[0197] At 1206, the server receives (for example, from one or more WTRUs from multiple WTRUs 203, the Edge Enabled Client (EEC) 210 or other components) indicating the public multi-user group ID.

[0198] And at 1208, the server (e.g., to the EEC 210 or other components of one or more WTRUs in a plurality of WTRUs 203) transmits instructions to one or more server instances (e.g., instances of other servers within one or more EAS204, EES208, ECS212 or EDN 206) associated with the public multi-user group ID.

[0199] Figure 13 This is a flowchart illustrating an example of a method for accessing one or more server instances associated with a public application (such as public application client 202) using an associated public multi-user group identifier (ID).

[0200] At 1302, WTRU 203 transmits a message to the server indicating a public multi-user group identifier. Examples of servers include EES208, EAS204, and ECS212, and examples of messages include EAS discovery requests, service provisioning requests, requests to identify one or more EAS instances associated with a public multi-user group ID, and requests to dispatch one or more EES instances associated with a public multi-user group ID.

[0201] At 1304, WTRU 203 receives an indication of one or more server instances associated with the public multi-user group ID. For example, the one or more server instances may be located within EDN 206 and may be one or more instances of one or more of EAS204, EES208, or ECS212.

[0202] And at 1306, WTRU 203 connects to one or more of these server instances.

[0203] Figure 14This is a flowchart illustrating an example of a method for configuring one or more Edge Application Server (EAS) instances to run sessions shared by multiple application clients on one or more WTRUs and associating one or more EAS instances with a multi-user group identifier (ID).

[0204] At 1402, the server receives from WTRU 203 a request for one or more EAS instances (e.g., one or more instances of EAS204) to be configured to run sessions shared by application clients 202 located on that WTRU and sessions shared by at least one other application client 202 located on that WTRU 203 or another WTRU 203. The server may include one or more of EAS204, EES 208, or ECS212 and is located within EDN 206.

[0205] Furthermore, at 1404, the server associates one or more EAS instances with a multi-user group ID.

[0206] As stated in the text, any description relating to the examples, embodiments and / or figures is merely illustrative of exemplary techniques and is not intended to limit the description; furthermore, elements of the examples, embodiments and / or figures (such as one or more steps of a process) may be reordered, made optional and / or combined with elements of other figures.

[0207] As described herein, a higher layer can refer to one or more layers in a protocol stack, or a specific sublayer within a protocol stack. A protocol stack may include one or more layers in a WTRU or network node (e.g., eNB, gNB, other functional entities, etc.), where each layer may have one or more sublayers. Each layer / sublayer may be responsible for one or more functions. Each layer / sublayer may communicate directly or indirectly with one or more other layers / sublayers. In some cases, these layers may be numbered, such as Layer 1, Layer 2, and Layer 3. For example, Layer 3 may include one or more of the following: Non-Access Stratum (NAS), Internet Protocol (IP), and / or Radio Resource Control (RRC). For example, Layer 2 may include one or more of the following: Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and / or Media Access Control (MAC). For example, Layer 3 may include Physical (PHY) layer type operations. The higher the layer number, the higher the layer is relative to other layers (e.g., Layer 3 is higher than Layer 1). In some cases, the foregoing examples may be referred to as the layer / sublayer itself, regardless of the layer number, and may be referred to as a higher layer as described herein. For example, from highest to lowest, a higher layer may refer to one or more of the following layers / sublayers: NAS layer, RRC layer, PDCP layer, RLC layer, MAC layer, and / or PHY layer. Any reference to a higher layer in connection with a process, device, or system herein refers to a layer above that process, device, or system. In some cases, a reference to a higher layer herein may refer to a function or operation performed by one or more layers described herein. In some cases, a reference to a higher layer herein may refer to information sent or received by one or more layers described herein. In some cases, a reference to a higher layer herein may refer to configuration sent and / or received by one or more layers described herein.

[0208] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of 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 optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented by a wireless transmit receive unit (WTRU), characterized by: The method comprises: transmitting (606, 802a, 902) a message indicating a common multi-user group identifier, ID, to a server, wherein the server is an edge enabler server, EES, wherein the message is an edge application server, EAS, discovery request; receiving (614, 806a, 906) an indication of one or more server instances associated with the common multi-user group ID; and connecting to the one or more server instances.

2. The method of claim 1, wherein transmitting the message to the server comprises transmitting a service orchestration request to an edge configuration server, ECS.

3. The method of claim 1, wherein the one or more server instances: are associated with the common multi-user group ID; and are located within an edge data network, EDN.

4. The method of claim 1, wherein: the server comprises an edge enabler server, EES; and the message comprises a request to identify one or more edge application server, EAS, instances associated with the common multi-user group ID.

5. The method of claim 1, wherein: the server comprises an edge configuration server, ECS; and the message comprises a request to orchestrate one or more edge enabler server, EES, instances associated with the common multi-user group ID.

6. The method of claim 1, wherein the WTRU runs an application client, AC, and an edge enabler client, EEC, wherein the AC provides the common multi-user group ID to the EEC prior to transmitting the message, wherein transmitting the message is performed by the EEC, wherein the receiving the indication is performed by the EEC, wherein the one or more server instances are associated with the common multi-user group ID, wherein the one or more server instances are located within an edge data network, EDN, wherein the one or more server instances are one or more edge application server, EAS, instances or a plurality of edge enabler server, EES, instances, and wherein: the server is an edge configuration server, ECS, the service orchestration request and the message comprise a service orchestration request to identify one or more edge application server, EAS, instances associated with the common multi-user group ID, or the server is an edge configuration server, ECS, and the message comprises a service orchestration request to orchestrate the EES instances associated with the common multi-user group ID.

7. A wireless transmit receive unit (WTRU) comprising a processor operably coupled to a transceiver, characterized in that, the processor is configured to: transmit (606, 802a, 902), via the transceiver, a message indicating a common multi-user group identifier, ID, to a server, wherein the server is an edge enabler server, EES, wherein the message is an edge application server, EAS, discovery request; receive (614, 806a, 906), via the transceiver, an indication of one or more server instances associated with the common multi-user group ID; and connect to the one or more server instances.

8. The WTRU of claim 7, wherein transmitting the message to the server comprises transmitting a service orchestration request to an edge configuration server (ECS).

9. The WTRU of claim 7, wherein the one or more server instances: are associated with the common multi-user group ID; and are located within an edge data network (EDN).

10. The WTRU of claim 7, wherein: the server comprises an edge enabler server (EES); and the message comprises a request to identify one or more edge application servers (EAS) instances associated with the common multi-user group ID.

11. The WTRU of claim 7, wherein: the server comprises an edge configuration server (ECS); and the message comprises a request to orchestrate one or more edge enabler server (EES) instances associated with the common multi-user group ID.

12. The WTRU of claim 7, wherein the WTRU runs an application client (AC) and an edge enabler client (EEC), wherein the AC provides the common multi-user group ID to the EEC prior to transmitting the message, wherein transmitting the message is performed by the EEC, wherein the receiving the indication is performed by the EEC, wherein the one or more server instances are associated with the common multi-user group ID, wherein the one or more server instances are located within an edge data network (EDN), wherein the one or more server instances are one or more edge application servers (EAS) instances or a plurality of edge enabler server (EES) instances, and wherein: the server is an edge configuration server (ECS), the service orchestration request and the message comprise a service orchestration request to identify one or more edge application servers (EAS) instances associated with the common multi-user group ID, or the server is an edge configuration server (ECS) and the message comprises a service orchestration request to orchestrate the EES instances associated with the common multi-user group ID.

Images