Patent Description:
In one or more embodiments, a method implemented by a wireless transmit receive unit (WTRU) includes: sending, to a server, a message indicating a common multi-user group identifier (ID); receiving 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.

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

<CIT> discloses a method of establishing communication, comprising communicating, by a user equipment (UE), key performance indicators requested by an application executing in the UE, to an edge data network; receiving parameters associated with a plurality of edge application servers in the edge data network, wherein the parameters identify processing capabilities of the plurality of edge application servers and where selected using the key performance indicators; selecting, by a user equipment (UE), an edge application server from the plurality of edge application servers based on the parameters; and processing the data associated with the application using the selected edge application server.

<NPL>" as "Key Issue #<NUM>" in paragraph <NUM> but does not provide a solution to said issue, as shown in Table <NUM>-<NUM>.

<NPL>", does not disclose the use of a group ID for all users of a multiplayer session so that they end up in the same EAS, but rather attempts to solve the issue by relying on the fact that if the same algorithm is used by all EESs in an EDN to select an EAS, and if they are fed the same location information, then all users should end up in the same EAS.

<CIT> discloses a method comprising, receiving, by a server computer, a request to establish a group identifier for a group. The method further comprises generating, by the server computer, the group identifier for the group. The method further comprises transmitting, by the server computer to a plurality of user devices operated by a plurality of users, group invitations to join the group.

A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying figures, wherein like reference numerals in the figures indicate like elements.

As listed in Table <NUM> below, one or more of the following abbreviations and/or acronyms may be used.

For example, the communications systems <NUM> 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 Spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

As shown in <FIG>, the communications system <NUM> may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) <NUM>, a core network (CN) <NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.

Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN <NUM>, the Internet <NUM>, and/or the other networks <NUM>. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface <NUM> using NR.

The WTRU <NUM> may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and/or simultaneous. In an embodiment, the WTRU <NUM> may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

For example, the CN <NUM> may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN <NUM>, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.

The AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. 11e DLS or an <NUM>.

The primary channel may be a fixed width (e.g., <NUM> wide bandwidth) or a dynamically set width. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in <NUM> systems.

11af and <NUM>. 11af and <NUM>. 11n, and <NUM>. 11af supports <NUM>, <NUM>, and <NUM> bandwidths in the TV White Space (TVWS) spectrum, and <NUM>. 11ah may support Meter Type Control/Machine-Type Communications (MTC), such as MTC devices in a macro coverage area.

11n, <NUM>. 11ac, <NUM>. 11af, and <NUM>. If the primary channel is busy, for example, due to a STA (which supports only a <NUM> operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or lasting varying lengths of absolute time).

For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN <NUM> 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.

For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions,.

<FIG> illustrates an example architecture <NUM> for enabling edge applications. Generally, system aspects for wireless systems (e.g., SA6), may address application-layer-architecture specifications for standardized verticals, including architecture requirements, functional architecture, procedures, information flows, interworking with non-3GPP application-layer solutions, and/or deployment models as appropriate. As shown, there are several components of the example architecture <NUM> that are further discussed in Table <NUM> below.

In some cases, an application service provider, or edge computing service provider, may deploy several instances of an Edge Application Server (EAS) <NUM> within a single Edge Data Network (EDN) <NUM> or across several EDNs. An EAS <NUM> may provide application-level specific functions to Application Clients (AC) <NUM> on terminals (e.g., WTRUs <NUM>). An AC <NUM> may connect to an EAS <NUM> in order to utilize available services of the application with the benefits of edge computing. A single AC <NUM> may be associated with one and only one Edge Enabler Client (EEC) <NUM>.

An Edge Enabler Layer (EEL) may provide one or more identifiers for AC's <NUM> and EAS's <NUM>, as provided in the example of Table <NUM> below.

An EAS <NUM> registration procedure(s), such as the example registration procedure <NUM> shown in <FIG>, may enable an EAS instance to inform, update, and/or delete its information with the EEL, via an EES <NUM>, to enable its discovery by ACs <NUM>. An EAS <NUM> instance may register with one (e.g., in some cases only one) EES <NUM>, providing the EAS information is described in an EAS Profile. The EAS <NUM> profile may or may not include information that uniquely identifies an EAS instance. For example, the EAS <NUM> Endpoint element within the EAS <NUM> Profile may be used to provide information for an AC <NUM> to communicate with an EAS. The EAS <NUM> Endpoint may be some identifier, such as a FQDN or URI, that may be shared with multiple EAS instances. Additionally, the EAS <NUM> Profile may not include any information that identifies application vertical sessions or AC <NUM> instances that any given EAS may be serving or available to serve.

An EAS discovery procedure(s), such as the examples <NUM> and <NUM> shown in <FIG>, respectively, may enable an EEC <NUM> to discover EASs <NUM> by interacting with an EES <NUM> in an EDN <NUM>. The EEC <NUM> may select one or more discovered EASs <NUM> and expose selected EASs to an AC <NUM>. The discovery of an EAS <NUM> may be based on matching EAS discovery filters provided by the EEC <NUM> with EAS profiles registered at the EES <NUM>. For example, some EAS <NUM> discovery procedures may include: a synchronous query (request-response procedure); and/or, an asynchronous notification (Subscribe-notify procedures). <FIG> may apply to both options, respectively. Further, for both options, the EAS <NUM> discovery filters may be provided by the EEC <NUM>, and may include a list of AC <NUM> characteristics and/or a list of EAS characteristics. The EAS <NUM> discovery filters may not include any ability to identify a specific instance of an EAS for selection or to identify an EAS instance serving or available to serve specific application vertical sessions. As described herein, an EAS <NUM> discovery filter may include one or more information elements, such as: a list of AC <NUM> characteristics; AC profile; list of EAS <NUM> characteristics; EASID; EAS provider identifier; EAS type; EAS schedule; EAS geographical service area; EAS topological service area; service continuity support; service permission level; service feature. One or more of these filters may be optional, and one or more of the filters may be mandatory.

In some cases, the EEL may not define how an AC <NUM> registers or identifies EAS <NUM> discovery/selection parameters to the EEC <NUM>, via the EDGE-<NUM> reference point. In other cases, there may be (pre)configured parameters. For example, how an AC <NUM> provides to the EEC <NUM> the information needed to identify an appropriate EAS <NUM> instance for connection, specifically its AC Profile, may need to be determined in order to address current and future needs of such a wireless system. The AC <NUM> Profile may not include any application vertical-session or context information or EAS-instance identification information for EAS discovery and selection for communication.

<FIG> illustrates an example of several EASs <NUM> (labeled EAS-1A, EAS-<NUM>(B), and EAS-<NUM>(C) in <FIG>, although the example contemplates fewer or more than three EASs) deployed in different locations of the same EDN <NUM>. For many applications, a set of ACs <NUM> may need to interface with a common EAS <NUM> instance, if they are participating in a shared-application vertical session or context. This may include ACs <NUM> on the same WTRU <NUM> or separate WTRUs <NUM> (labeled WTRU1, WTRU2, and WTRU3 in <FIG>, although the example contemplates fewer or more than three WTRUs), for a single user or multiple users, and connected to a common EDN <NUM> or different EDNs <NUM>.

In some cases, the EEL may not provide an any capability for a set of ACs <NUM> or WTRUs <NUM> to discover and select a common EAS <NUM>. This may be an issue, and may need to be addressed by one or more approaches, as discussed herein (e.g., discovery of a common EAS <NUM>). This issue may raise one or more questions: First, whether and how the ACs <NUM>/EECs <NUM> of different users (e.g., different WTRUs <NUM>) can select or be provisioned the same EAS <NUM> within an EDN <NUM>? Second, whether and how the ACs <NUM>/EECs <NUM> of different users (e.g., different WTRUs <NUM>) can select or be provisioned a common EAS <NUM>, even if initially the EECs <NUM> are communicating with different EDNs <NUM>? Third, whether and how the EEL can support service continuity to ensure that when ACs <NUM> require the use of service from a common EAS <NUM> and an ACR operation is needed, ACR operations can be coordinated so that upon completion of the ACR operations the ACs again have services provided by a common EAS.

In one or more embodiments, the above questions may be addressed herein.

Some examples of application verticals that require a set of ACs <NUM>/WTRUs <NUM> to participate in a shared-application vertical session with a common EAS <NUM> instance are listed, non-exhaustively, in Table <NUM> below.

There may be one or more approaches to common-EAS-instance discovery and selection. In one instance, (e.g., specifically addressing multiplayer games) each AC <NUM> on all WTRUs <NUM> participating in a game instance may learn the identities of all the other WTRUs in the game and their locations. Each EEC <NUM> may send this information (e.g., list of WTRUs <NUM> with location) to the EES <NUM> for common EAS <NUM> discovery. This approach may require sensitive information (e.g., identity and location) to be shared with all ACs <NUM> and WTRUs <NUM>, which can be a security and privacy risk when players are not known and trusted. Additionally, this embodiment does not enable a single WTRU <NUM> (e.g., a gaming console or hub device) to be engage in two or more separate game sessions served by different EAS <NUM> instances.

In a second instance, for EAS <NUM> discovery for different users, there may be EEL service differentiation that is focused on how an ECSP can provide edge-service quality levels (e.g., premium users vs. normal users). An EAS <NUM> may provide a list of WTRU <NUM> Identifiers to the EES <NUM> that can be used in EAS selection / discovery. This list could be used to match WTRUs <NUM> in the list to a common EAS <NUM> instance. However, this may expose sensitive information (e.g., WTRU <NUM> identifiers) at an application level (EAS <NUM>). How the EAS <NUM> learns the set of WTRU <NUM> identifiers may still need to be addressed. Finally, this approach does not enable a single WTRU <NUM> (e.g., a gaming console or hub device) to be engage in two or more separate game sessions served by different EAS <NUM> instances.

In legacy cases, EAS <NUM> discovery and selection does not take into consideration any information on application vertical sessions. An application vertical session is a set of ACs <NUM> and EASs <NUM> participating in a broader application vertical deployment (e.g., common multi-user, multi-device, or multi-client session). EAS <NUM> discovery and selection in such cases 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 <NUM> Identifier, etc. As a result, these legacy EAS <NUM> discovery-and-selection procedures are executed independently for each AC <NUM> and EEC <NUM>, with little or no ability to ensure that a set of ACs participating in a common application vertical session can receive service from a common EAS <NUM>.

Accordingly, there is a need for techniques that address, for example, discovery of a common EAS <NUM> (e.g., how the ACs/EECs of different users can select or be provisioned the same EAS). It may also be relevant to address any additional shortcomings, such as: where a technique requires that privacy and security sensitive information, such as WTRU <NUM> identities, WTRU location, etc., is shared at the application-level (with ACs <NUM>, EASs <NUM>, and application-layer servers in the cloud); additionally, where techniques do not differentiate the application vertical-session level and AC <NUM> level (e.g., limiting the ability of separate ACs on a single device to interact with separate EAS <NUM> instances). In considering these shortcomings, additional factors may also be addressed, such as: How to enable different ACs <NUM> located on the same or different WTRUs <NUM> and of the same or different types to engage in a common application vertical session; How to enable the discovery and selection of a common EAS <NUM> instance for a set of ACs <NUM> participating in an application vertical session, while maintaining privacy (i.e., not exposing sensitive information, like identity and location between ACs, EASs, or WTRUs <NUM>); How can the EEL assist in creating an application vertical session.

In one or more embodiments, the above 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 address shared application vertical-session-based edge-application instance discovery and selection: there may be an application-vertical-session-identifier; one or more application-vertical-session-based EAS <NUM> registration, discovery, and selection procedures; application-vertical-session-based EDN/EES provisioning; and/or, application-vertical-session management.

An Application Vertical Session Identifier (ASVID) identifies a "common multi-user session" and may be used by an EEL to assist in the management of an application vertical session, including the discovery and selection of a common EAS <NUM> (or group of common EASs) for the set of AC's <NUM> participating in a session. "Multi-user" may include any combination of ACs <NUM> and EECs <NUM> on one or more WTRUs <NUM>. It does not imply a human user although it may be a human user.

Application-vertical-session-based EAS <NUM> registration, discovery, and selection are enhanced EEL procedures that specially consider ASVIDs as input. An EAS <NUM> that supports application vertical sessions signals to the EEL (e.g., EES <NUM>) during registration (including updates) the application-vertical-session identifiers that the EAS is serving. Similarly, an AC <NUM> may signal to the EEL (e.g., EES <NUM>) with which application vertical sessions the client (AC) will be participating via the EEC <NUM>. With application-vertical-session identification, the EEC <NUM> and EES <NUM> may be able to match AC/WTRU EAS <NUM> discovery and selection requests with the appropriate EAS instances serving their requested application vertical sessions.

Application-vertical-session-based EDN/EES provisioning is an enhanced procedure that selects an EDN <NUM> for connection by a WTRU <NUM> based on its AC <NUM> application-vertical-session requirements. The ECS <NUM> may utilize these requirements to select an EDN <NUM> and EES <NUM> combination for an EEC <NUM>, based on the availability of application vertical sessions that are served by EASs <NUM>. If an EAS <NUM> is not available to serve an application vertical session in an EDN <NUM> on a provisioning request, the ECS <NUM> may signal a notification to a subscribed EEC <NUM> with a service provisioning notification if an EAS becomes available to service the requested application vertical session at a later time.

Application-vertical-session management is a procedure that allows a WTRU <NUM> to create an application vertical session in the EEL and allows other WTRUs to learn about application vertical sessions available in the EEL.

<FIG> illustrates an example of an application-vertical-session-based EAS <NUM> registration, discovery, and selection procedure <NUM>. As shown, the EEL may support the interconnection of ACs <NUM> on WTRUs <NUM> with the appropriate EAS <NUM> instances that are serving their application vertical sessions, via enhanced EAS registration, discovery, and selection procedures. As shown, there is an overall procedure flow with an operational example.

A benefit of these enhanced procedures is that they enable the AC <NUM> and/or EEC <NUM> to discover and select an EAS(s) <NUM> that not only provide(s) a certain type of service, but also enable(s) the AC and/or EEC to discover EAS(s) <NUM> that are associated with a particular instance of a service. Without this feature, the AC <NUM> and/or EEC <NUM> might be unable to discover and connect to the application vertical session that the AC wants to join (e.g., a gaming AC might be unable to connect to an application vertical session serving other ACs in the same game).

As shown in <FIG>, there is an example procedure <NUM> of an AC <NUM> discovering an EAS <NUM> instance that is serving its application vertical session. Initially, at <NUM>, there may be one or more prerequisites: at the application-level, an application vertical session may be created, and an Application Vertical Session ID (AVSID) may be assigned to identify the session. In the example, two application vertical sessions are created, one with AVSID = "A" and another with AVSID "B". Note, "A" and "B" are examples merely for illustration of the related techniques and may vary in one or more other embodiments based on this disclosure. The AVSIDs may be distributed at the application-level across serving EASs <NUM> and consuming ACs <NUM>. In other words, the AVSID may be received by an AC <NUM> in a message from an EAS <NUM>, an application server, or the EEL (if the EEL has such capabilities). If an AVSID is not available and needs to be created, the methods for application-vertical-session management described herein may be utilized to create an AVSID for an application vertical session via the EEL.

At 604a and 604b, each EAS <NUM> may register with their EES <NUM> and provide their serving AVSIDs, for example via an application-vertical-session enhanced EAS profile as described herein (e.g., Table <NUM>). The EES <NUM> may store the EAS-to-AVSID relationships in order to match EEC <NUM> requests for EAS <NUM> discovery to a serving EAS or groups of EASs. For example, <FIG> shows EAS1 registering with AVSID = "A" and EAS2 registering with AVSID = "B". EAS1 and EAS2 may share a common EASID or may have different EASIDs. The EAS <NUM> may have obtained an AVSID from another server such as a match-making server that can be hosted in the cloud or in an EDN <NUM>. Alternatively, the AVSID may have been pre-configured in the EAS <NUM>, for example via a configuration file or via configuration at EAS orchestration time; alternatively the AVSID may have been provided by the EEL assuming the EEL has such capabilities.

At <NUM>, when an AC <NUM> needs to interface to an EAS(s) <NUM> serving its application vertical session, the AC may request EAS discovery from the EEC <NUM> and provide its associated Application Vertical Session ID(s). In the example, ACx <NUM> on WTRUx <NUM> requests EAS discovery for AVSID = "A". Alternatively, the ACx 202may implicitly trigger an EAS discovery at the EEC <NUM> by registering with the EEC and providing the AVSID in the registration. The ACx <NUM> may have obtained the AVSID from a pre-configured file, or from a user input, or from a match-making server hosted in the cloud or in an edge data network, or from the EEC <NUM> assuming the EEC has such capabilities.

At <NUM>, the EEC <NUM> may process the EAS <NUM> discovery or AC <NUM> registration request from the AC and send an EAS <NUM> discovery request, including an enhanced AC profile(s) (e.g., such as described herein) within EAS discovery filter(s) to an EES <NUM> that is capable of serving the requested application vertical session. The EEC <NUM> may select the EES <NUM> that provides service for an application vertical session based on an enhanced AC <NUM> profile, such as the AC profile described herein.

At <NUM>, upon receiving the EAS <NUM> discovery request, the EES <NUM> may perform a lookup of registered EASs matching EAS requirements including finding an EAS(s) that match(es) the requested AVSID(s) and selects only EAS(s) associated with the AVSID(s). In the example shown, the EES <NUM> selects EAS1 which is serving AVSID = "A". Although the example is showing a single EAS <NUM> instance, the AC <NUM> could be served by a group of EASs that are serving the same AVSID = "A".

At <NUM>, the EES <NUM> responds to the EEC <NUM> with the selected EAS <NUM> endpoint(s) and the AVSID(s) that the EAS(s) is serving in an enhanced Service Session Context in the EEC Context, such as disclosed herein.

At <NUM>, the EEC <NUM>, in turn, may respond to the requesting AC <NUM> with the selected EAS <NUM> endpoint(s) and the AVSID(s) that the EAS(s) is(are) serving.

At <NUM>, the Application Client (AC) <NUM> may connect to the selected EAS(s) <NUM> and join the application vertical session. In the illustrated example, ACx <NUM> on WTRUx <NUM> connects to EAS1 <NUM> and joins into the application vertical session having AVSID = "A".

For <NUM> - <NUM>, these steps may be repeated for each AC <NUM> and WTRU <NUM> participating in the application vertical session.

At <NUM>, if an EAS <NUM> is serving more than one application vertical session, the AVSID may be appended to application traffic requests to differentiate flows based on AVSID.

<FIG> illustrates an example of an application-vertical-session-based EAS <NUM> discovery notification <NUM>. The EAS <NUM> discovery subscription / notification procedures, as disclosed herein, may offer a method to inform an EEC <NUM> about the availability of an EAS in an EDN <NUM> asynchronously. As illustrated, there is an example of an application-vertical-session enhanced procedure for EAS Discovery subscriptions and notifications. This procedure may be useful when no EAS <NUM> instances were available to serve an AVSID(s) in an EAS Discovery request response, as described previously herein. The EES <NUM> may use the application-vertical-session enhanced EAS discovery notification to inform the EEC <NUM> of the dynamic availability of an EAS(s) <NUM> that may serve one or more application vertical sessions of interest.

Initially, there may be one or more prerequisite. An application vertical session(s) may be created, and an AVSID(s) may be assigned to identify the session. The AVSID may be provided to the EEC <NUM>, for example, by the AC <NUM> when registering with the EEC or requesting EAS <NUM> discovery for an AVSID(s). The EEC <NUM> may attempt a synchronous EAS Discovery request procedure (e.g., <FIG>) and no EASs <NUM> may be reported by the EES <NUM> as available to service the requested AVSIDs.

At <NUM>, the EEC <NUM> may create an application-vertical-session EAS <NUM> discovery subscription with the EES <NUM> (e.g., as described herein), providing a set AVSIDs in EAS discovery filters or in EAS dynamic information filters (e.g., as disclosed herein).

At <NUM>, at a later time, an EAS <NUM> may be instantiated in an EDN <NUM> to serve the application vertical session(s) that are identified by their respective AVSIDs. The EAS <NUM> may register with an EES <NUM> and provide its serving AVSIDs, for example via an enhanced EAS profile defined, e.g., as disclosed herein.

At <NUM>, the EES <NUM> may use the EAS <NUM> registration information and evaluate the information against EAS discovery subscription filters, for example the AVSIDs from the subscription created at <NUM>. The EES <NUM> may determine that a notification needs to be issued towards the EEC <NUM>, since the AVSID(s) matches the subscription request.

At <NUM>, the EES <NUM> may send the EAS Discovery notification to the subscribed EEC <NUM> and include the application-vertical-session(s) enhanced EAS profile (e.g., as disclosed herein).

At <NUM>, the EEC <NUM> may inform the AC <NUM> about the EAS <NUM>, providing the EAS endpoint(s) and the AVSID(s) that the EAS(s) is serving. The AC <NUM> may connect to the selected EAS(s) <NUM> and join the application vertical session.

<FIG> illustrate an example of service provisioning. Generally, in an EEL, the EEC <NUM> may utilize services of the ECS <NUM> to discover EDNs <NUM> and EESs <NUM> that can serve the needs of ACs <NUM> on a WTRU <NUM> via the service-provisioning procedure. In some cases, EDN <NUM>/EES <NUM> service provisioning may consider EAS <NUM> and AC <NUM> type information (e.g., EASID and ACID) in the AC Profile. However, in some cases EDN <NUM>/EES <NUM> service provisioning may not consider any application-vertical-session information. This may cause an EEC <NUM>/AC <NUM> to discover EESs <NUM> in different EDNs <NUM> that may be available to the WTRU <NUM> without knowing which EAS <NUM>/EDN <NUM> can provide the needed application vertical session; consequently, there is an issue where the EEC 210has to iterate performing EAS <NUM> discovery with each EES <NUM> until the EEC finds an EAS that supports its desired AVSID(s). To address this, it may be beneficial to discover and signal the availability of EDNs <NUM> and their EESs <NUM> in relation to requested AVSIDs that are served or can be served by EASs <NUM> within such EDNs.

A benefit of this enhanced procedure is that it allows the AC <NUM> and EEC <NUM> to discover EDN(s) <NUM> and EES(s) <NUM> that can be used to reach EAS(s) <NUM> that not only provides a certain type of service, but also it allows the AC and EEC to discover EDN(s) and EES(s) that can be used to reach EAS(s) that are associated with a particular instance of a service (e.g., serving an application vertical session). Without this feature, the AC <NUM> and EEC <NUM> may not be able to discover and connect to the application vertical session that the AC <NUM> wants to join (e.g., the gaming AC would not connect to EAS(s) <NUM> serving a game match identified by a particular one or more AVSIDs).

At 802a and 802b, the EEC <NUM> issues, to the ECS <NUM>, a service provisioning request or a service provisioning subscription request.

<FIG> illustrates an example of an application-vertical-session-based EES <NUM> provisioning-and-selection procedure <NUM>. This example describes EDN <NUM>/EES <NUM> service provisioning in the EEC <NUM> request-response model. In this model, the EEC <NUM> requests EES <NUM> service provisioning providing its requested AVSIDs. The ECS <NUM> may provision the EEC <NUM> with an EES <NUM>/EDN <NUM> that can service its requested AVSIDs.

Initially (not shown), there may be one or more prerequisites. An application vertical session(s) may be created, and an Application Vertical Session ID(s) may be assigned to identify the session. The AVSID may be provided to the EEC <NUM>, for example, by the AC <NUM> when registering with the EEC <NUM> or requesting EAS <NUM> discovery for an AVSID(s).

At <NUM>, the EEC <NUM> may send a service provisioning request to the ECS <NUM>. The service provision request may include a set of AC <NUM> Profiles with AVSIDs for the AC-requested application vertical sessions (e.g., as disclosed herein).

At <NUM>, upon receiving the service provisioning request, ECS <NUM> may perform an authorization check. Using the EEC <NUM> provided enhanced AC Profile(s), which include AVSID(s) (e.g., as disclosed herein), the ECS <NUM> may identify and select an EES(s) <NUM> and associated EDN(s) <NUM> that can service the application-vertical-session's(s') requests from the ACs <NUM>. The EES <NUM> may provide the ECS <NUM> with the EAS(s) <NUM> and AVSID(s) that are served in their EDN <NUM> using an enhanced EES profile (e.g., as disclosed herein) from their EES registration (not shown).

At <NUM>, the ECS <NUM> may return a service-provisioning response with an enhanced EDN <NUM> configuration(s) that includes a list of EESs <NUM> with the EAS(s) <NUM> and AVSID(s) that each EES can serve (e.g., as disclosed herein).

At <NUM>, the EEC <NUM> in the WTRU <NUM> may use the enhanced EDN <NUM> configuration to select the EES(s) <NUM>/EDN(s) <NUM> that can service the WTRU's AC(s) <NUM> including their application vertical sessions and to perform an EEC <NUM> registration request to the selected EES(s), including an AC <NUM> profile(s) with AVSIDs (e.g., as disclosed herein).

At <NUM>, the EES <NUM> may validate the EEC <NUM> registration request. Using the AC profile(s) with AVSIDs, the EES <NUM> may determine if the requests for service can be fulfilled.

At <NUM>, the EES <NUM> may return an EEC registration response to the EEC <NUM>, including an EEC context ID. The EEC context ID may refer to an enhanced EEC context instance in the EES <NUM> (e.g., as disclosed herein).

<FIG> illustrates an example of an application-vertical-session-based-EES-<NUM>-provisioningnotification procedure <NUM>. This example may address the EDN/EES service provisioning in the EEC <NUM> subscription-notification model. This model may be used to asynchronously inform an EEC <NUM> of the availability of an EES <NUM> and an EDN <NUM>. In this enhanced procedure, the ECS <NUM> may inform the EEC <NUM> via a notification when an EAS <NUM> (e.g., servicing a requested AVSID(s)) becomes available in an EDN <NUM> and is discoverable via an EES <NUM>.

Initially, not shown, there may be one or more prerequisites. An application vertical session(s) may be created, and an Application Vertical Session ID(s) may be assigned to identify the session. The AVSID(s) may be provided to the EEC <NUM>, for example, by the AC <NUM> when registering with the EEC or requesting EAS <NUM> discovery for an AVSID(s). The EEC <NUM> may have attempted the enhanced-service-provisioning request-response model (e.g., as described herein) and found there are no EDNs <NUM> and EESs <NUM> available for the requested AVSID(s).

At <NUM>, the EEC <NUM> may send a service-provisioning-subscription request to the ECS <NUM>. The service-provisioning subscription may include a set of AC Profiles that provide AVSIDs for the AC <NUM> requested application vertical sessions (e.g., as disclosed herein).

At <NUM> and <NUM>, the ECS <NUM> may create a subscription for the EEC <NUM> and store the requested AC Profiles with their AVSIDs.

At <NUM>, (e.g., at a later time) an EAS <NUM> may be instantiated in an EDN <NUM> to serve the application vertical session(s) that are identified by their respective AVSIDs.

At <NUM>, in order to inform the EEL of its information, the EAS <NUM> may register with the EES <NUM> and provide its serving AVSIDs, for example via the enhanced EAS profile (e.g., as disclosed herein). The EES <NUM> may store the EAS-to-AVSID relationships in order to match EEC <NUM> requests for EAS <NUM> discovery to a serving EAS.

At <NUM>, the EES <NUM> may register or update its registration with the ECS <NUM>, providing an enhanced EES profile (e.g., as disclosed herein) that includes EASs <NUM> available to the EES <NUM> referenced by their EASIDs and the AVSID(s) that an EAS <NUM> may be serving.

At <NUM>, the ECS <NUM> may process the new or updated EES <NUM> registration information, including EASIDs with associated AVSIDs. The ECS <NUM> may determine if any service provisioning notifications need to be issued to an EEC <NUM> to signal AVSID availability in an EDN <NUM>/EES <NUM>, based on the information received from an EEC(s) in <NUM>.

At <NUM>, the ECS <NUM> may issue a service provisioning notification to any EECs <NUM> that need to be informed about AVSID(s) availability from <NUM>. The service-provisioning notification may send an enhanced EDN <NUM> configuration(s) that includes a list of EESs <NUM> with the EAS(s) <NUM> and AVSID(s) that each EES can serve (e.g., as disclosed herein).

At <NUM>, in order to provide an AC <NUM> access to an ASVID-serving EAS <NUM>, the EEC <NUM>/ WTRU <NUM> may connect to the EDN <NUM> using the enhanced EDN configuration received in <NUM>. This may include the establishment of a new PDU session to the EDN <NUM>, if an existing PDU session is not available, or an update to an existing PDU session. The EEC <NUM> may register with the indicated EES(s) <NUM> from <NUM>, including an AC <NUM> profile(s) with AVSIDs (e.g., as disclosed herein).

At <NUM>, after the EEC <NUM> registers with an EES <NUM>, the EEC may discover the EAS(s) <NUM> serving the needed AVSID(s) and provide their information to the requesting AC(s) <NUM> (e.g., as disclosed herein).

At <NUM>, with the EEC <NUM> provided EAS <NUM> information (e.g., the enhanced EAS profile as described herein), the AC(s) <NUM> may connect to the selected EAS(s) <NUM> and joins/join the application vertical session.

For one or more embodiments disclosed herein, there may be an enhanced data model for edge-enabler-layer application vertical session(s). An AC Profile may contain information about an AC <NUM>. The AC Profile may be utilized by the EEC <NUM>, EES <NUM>, and ECS <NUM> to provision a WTRU <NUM> for EEL service. The ECS <NUM> may select with which EES <NUM> to provision a WTRU <NUM>, using the AC profile. The EES <NUM> may use the AC Profile to select EAS <NUM> instances for EAS discovery. The EEC <NUM> may provide EAS endpoint information to an AC <NUM> on selected/available EAS <NUM> instances. The EAS Profile may be enhanced to include AVSIDs. Table <NUM> illustrates an example of an application-vertical-session enhanced AC profile.

An EAS <NUM> profile may include information that the EES <NUM> utilizes to discover and select EAS instances upon request from the EEC <NUM>. The EES <NUM> may store an EAS Profile for each registered EAS <NUM>. The EAS Profile may be enhanced to include AVSID for identifying sessions that the EAS <NUM> serves. Table <NUM> illustrates an example of an application-vertical-session enhanced EAS profile.

An EES profile may include information about an EES <NUM> and the services that it provides. The EES profile may be enhanced to include AVSID for application vertical sessions that the EES <NUM> may support. Table <NUM> illustrates an example of an application-vertical-session enhanced EES profile.

An Service Session Context may be enhanced to include the Application Vertical Session Identifier(s) for a service session context. Table <NUM> illustrates an example of an application-vertical-session enhanced EEC context.

EDN Configuration Information type may be enhanced to include the AVSID(s) within the "List of EESs". This information may be used to signal to an EEC <NUM> what application vertical sessions are served by an EEC (via EASs <NUM>) within an EDN <NUM> and discoverable via the EES <NUM>. The EDN Configuration may be utilized in ECS <NUM> service provisioning for the request-response model and the subscribe-notify model. Table <NUM> illustrates an example of an application-vertical-session enhanced EDN configuration information.

EAS <NUM> dynamic information filters may be enhanced to notify an EEC <NUM> of dynamic changes to application vertical sessions, indicated by AVSID, served by an EAS <NUM> via EAS Discovery subscriptions. Table <NUM> illustrates an example of an application-vertical-session enhanced-EAS dynamic-information filter.

An Application Vertical Session Identifier (AVSID) may be formatted such that it is a union of multiple identifiers or pieces of information. For example, the AVSID may include: a service provider identifier; a unique number that is associated with a vertical session or piece of context information; an authorization service identifier that can be used as a trusted third party to verify that the AC <NUM>/EEC <NUM> is authorized to provide the AVSID (e.g., as described earlier, the AVSID, and therefore the authorization service identifier, may be provided to the AC via application-layer interaction with the service provider, where the authorization service identifier may be pre-assigned, or pre-negotiated with the mobile-network operator); one or more PLMN Identifiers that identify PLMNs that may be used to access the service; and/or, one or more ECS <NUM> identifiers that may be used to be provisioned with information about EDN(s) <NUM> and EES(s) <NUM> that can be used to discover EDN(s) and EES(s) that can be used to reach EAS(s) <NUM> that are associated with the session.

In one or more embodiments disclosed herein, there may be security problems and solutions, such as security associated with AVSID(s). In some cases, a token may be used for EEC <NUM> authorization to access EES <NUM>. Since multiple EASs <NUM> can register with the same EES <NUM>, when an authorization token(s) is issued from the ECS <NUM> to the EEC <NUM> for the EES <NUM> access authorization, the token may contain the AVSID to bind the authorization with the EES/AVSID pair. Otherwise, the AC <NUM>/EEC <NUM> can access EES <NUM> info associated with EAS <NUM> with different AVSID. In some cases, there may be session key binding with the AVSID. If a security association is established to protect the communication between the AC <NUM>/EAS <NUM> after the AC is authorized to access the EAS, the session key for security protection of the communication channel between AC/EEC with EAS may be bound to the EAS using the AVSID (e.g., the AVSID should be included as the input parameters when derived from the session key).

In one or more embodiments disclosed herein, there may be management techniques for application vertical sessions (AVS). Application-vertical-session management may require the EEL to provide support for creating and deleting AVS. AVS creation may be required when an AC <NUM> or EEC <NUM> initiates an AVS or may alternatively be useful for pre-provisioning AVS ahead of usage. As some of the embodiments discussed herein, the AVS and AVSID may be known at the EAS <NUM> or AC <NUM>. In addition or in the alternative, there may also be techniques for provisioning the AVSID using the edge-enablement layer.

<FIG> illustrates an example procedure <NUM> of AVS creation using the edge-enabled layer. In this example procedure, there is a method for creating an application vertical session provided by the edge-enablement layer.

Initially, at <NUM>, the EEC <NUM> may be present on a first WTRU <NUM> (e.g., EEC1) and may perform the EAS <NUM> discovery procedure as described herein; as a result, the EEC may obtain a list of EASs that meet the EEC criteria specified in the EAS discovery request. The EAS <NUM> discovery request may contain an AVSID that EEC1 <NUM> may try to discover, in which case it may not receive any EAS in the list (e.g., if the AVSID does not exist). In this use case, the EEC1 <NUM> did not provide an AVSID and received a list of existing EAS(s) <NUM>.

At <NUM>, the EEC1 <NUM> may initiate AVS creation, which in EEC1 means acquiring the parameters needed to create an AVS in the EEL. For example, this action may be triggered from a request originating from an AC <NUM> using EEC1 <NUM>; or, for example, this action may be triggered by a user, or for example this action may be from a pre-defined AVS configuration present at WTRU1 <NUM>; or, for example, this action may be triggered by receiving a message such as a SMS, or, for example, this action may be triggered by other external sources such as another WTRU <NUM> or server. In any case, the information required to create an AVS may be provided by the source that triggered the AVS initiation. The AVS parameters may include an AVS identifier (AVSID) that uniquely identifies the AVS resource, may include a friendly AVS name that may allow a user to recognize the AVS, may include a list of users or terminals that are allowed to join the AVS, may include a maximum number of users allowed to join an AVS, may include a location (e.g., geographical or topological) where the AVS can be used, and/or, may include a duration for which the AVS will exist.

At <NUM>, the EEC1 <NUM> may send an EAS <NUM> selection request to the EES <NUM> to indicate its intention of using the EAS; the EEC1 may include the AVS parameters in this request to indicate to the EES that it needs to create an AVS.

At <NUM>, upon receiving the EAS <NUM> selection request with the AVS parameters, the EES <NUM> may store the AVS parameters, for example in the EEC context, and may allocate an AVSID if no AVSID was included in the EAS selection request. This AVSID may be used to uniquely identify the AVS. Alternatively in some systems, the EAS <NUM> selection request may trigger the instantiation of an EAS if no suitable EAS is available. In this case, the AVS parameters which may include an AVSID provisioned with the orchestration of the EAS <NUM> and the AVS notification message in <NUM> is not needed.

At <NUM>, the EES <NUM> may notify the selected EAS <NUM> of the newly created AVS. Not shown in <FIG>, the EAS <NUM> may have subscribed to the EES <NUM> to receive AVS management events in a similar manner as described herein for subscribing to ACR management events. The AVS notification may include the AVS parameters. If the EAS <NUM> can support the newly received AVS, then the EAS may store the AVS parameters and AVSID, and return a success indication to the EES <NUM>. If the notification did not include an AVSID, then the EAS <NUM> may create an AVSID to uniquely identify the AVS. If the EAS <NUM> cannot support the newly received AVS, it may not store the parameters and returns an error indicating the failure to the EES <NUM>.

At <NUM>, if the EAS <NUM> can support the newly received AVS, then the EAS may perform a registration update of its EAS profile at the EES <NUM> with the newly received AVSID. Alternatively, if the EAS <NUM> was instantiated in <NUM>, it may perform this by performing an EAS registration with the EES <NUM>.

At <NUM>, the EES <NUM> may send an EAS <NUM> selection response to the EEC1 <NUM>. The response may include the following information elements: the result of the EAS <NUM> selection, and/or the AVSID. If the AVS was not successfully created, the EAS <NUM> selection response may contain an error message indicating the reason of failure. Upon receiving the AVSID, the EEC1 <NUM> may store the AVSID and inform the AC <NUM>.

At <NUM>, the AC <NUM> present on the first WTRU <NUM> connects and starts exchanging application traffic with the EAS <NUM> associated with the AVSID.

At <NUM>, an EEC <NUM> may be present on a second WTRU <NUM> (e.g., on which EEC2 <NUM> is instantiated) and may perform the EAS discovery procedure as described herein; as a result, the EEC may obtain a list of EAS(s) <NUM> that meet the EEC criteria specified in the EAS discovery request.

The EEC2 <NUM> may have received an AVSID from the first WTRU <NUM>: for example, it may have received the AVSID from a request originating from an AC <NUM> using EEC2 (e.g., 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 a SMS; or, for example, it may have received the AVSID from external sources such as another WTRU <NUM> or server. In such a case, the EEC2 <NUM> may include the AVSID in the EAS discovery request, and the EES <NUM> may use the AVSID to identify the EAS <NUM> hosting the AVS and return the address of the EAS hosting the AVS to the EEC2.

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

At <NUM>, upon receiving a list of EAS <NUM> from EAS discovery, the EEC <NUM> may select one EAS. The EEC <NUM> may select the EAS <NUM> based on the AVSID that it may have received in <NUM>. If the EEC <NUM> does not know which AVSID to select, it may present a list of available AVSID to a user of the WTRU <NUM> for a manual selection.

At <NUM>, the AC <NUM> present on the second WTRU <NUM> connects and starts exchanging application traffic with the EAS <NUM> serving the AVSID.

<FIG> is a flow diagram of an example of a method for setting up server instances and a multi-user group identifier (ID) for a common application, such as a common application client <NUM>.

At <NUM>, a server, such as an edge-enabler server (EES) <NUM> or an edge-configuration server (ECS) <NUM>, receives, from a plurality of WTRUs <NUM>, information related to a common application such as a common application client <NUM>.

At <NUM>, the server sends a common multi-user group identifier (ID) to the plurality of WTRUs <NUM> in response to receiving the information.

At <NUM>, the server receives (for example, from an edge-enabler client (EEC) <NUM>, or other component, of one or more of the plurality of WTRUs <NUM>) a request that indicates the common multi-user group ID.

And at <NUM>, the server sends (for example, to an EEC <NUM>, or other component, of one or more of the plurality of WTRUs <NUM>) an indication of one or more server instances (for example, instances of one or more EASs <NUM>, EESs <NUM>, ECSs <NUM>, or other servers within the EDN <NUM>) associated with the common multi-user group ID.

<FIG> is a flow diagram of an example of a method for accessing one or more server instances associated with a common application (such as a common application client <NUM>) using an associated common multi-user group identifier (ID).

At <NUM>, a WTRU <NUM> sends, to a server, a message indicating a common multi-user group identifier. Examples of the server include an EES <NUM>, an EAS <NUM>, and an ECS <NUM>, and examples of the message include an EAS discovery request, a service provisional request, a request for identifying one or more EAS instances associated with a common multi-user group ID, and a request for provisioning of one or more EES instances associated with the common multi-user group ID.

At <NUM>, the WTRU <NUM> receives an indication of one or more server instances associated with the common multi-user group ID. For example, the one or more server instances may be within the EDN <NUM> and may be one or more instances of one or more of the EASs <NUM>, EESs <NUM>, or ECSs <NUM>.

And at <NUM>, the WTRU <NUM> connects to the one or more server instances.

<FIG> is flow diagram of an example of a method for configuring one or more edge-application-server (EAS) instances to run a session common to multiple application clients on one or more WTRUs and to associate the one or more EAS instances with a multi-user group identifier (ID).

At <NUM>, a server receives, from a WTRU <NUM>, a request that one or more EAS instances (e.g., instances of one or more of EASs <NUM>) be configured to run a session common to an application client <NUM> located on the WTRU and to at least one other application client <NUM> located on the WTRU <NUM> or on another WTRU <NUM>. The server may include one or more of an EAS <NUM>, an EES <NUM>, or an ECS <NUM> and be located within an EDN <NUM>.

And at <NUM>, the server associates the one or the one or more EAS instances with a multi-user group ID.

As described herein, any description relating to an example, embodiment, and/or figure merely illustrates an example technique, and is not intended to be limiting in its description; further, it is intended that elements of a example, embodiment, and/or figure, such one or more steps of a process, may be reordered, made optional, and/or combined with elements of other figures.

As described herein, a higher layer may refer to one or more layers in a protocol stack, or a specific sublayer within the protocol stack. The protocol stack may comprise of one or more layers in a WTRU or a network node (e.g., eNB, gNB, other functional entity, 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 with one or more of the other layers/sublayers, directly or indirectly. In some cases, these layers may be numbered, such as Layer <NUM>, Layer <NUM>, and Layer <NUM>. For example, Layer <NUM> may comprise of one or more of the following: Non Access Stratum (NAS), Internet Protocol (IP), and/or Radio Resource Control (RRC). For example, Layer <NUM> may comprise of one or more of the following: Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and/or Medium Access Control (MAC). For example, Layer <NUM> may comprise of physical (PHY) layer type operations. The greater the number of the layer, the higher it is relative to other layers (e.g., Layer <NUM> is higher than Layer <NUM>). In some cases, the aforementioned examples may be called layers/sublayers themselves irrespective of 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: a NAS layer, a RRC layer, a PDCP layer, a RLC layer, a MAC layer, and/or a PHY layer. Any reference herein to a higher layer in conjunction with a process, device, or system will refer to a layer that is higher than the layer of the process, device, or system. In some cases, reference to a higher layer herein may refer to a function or operation performed by one or more layers described herein. In some cases, reference to a high layer herein may refer to information that is sent or received by one or more layers described herein. In some cases, reference to a higher layer herein may refer to a configuration that is sent and/or received by one or more layers described herein.

Claim 1:
A method implemented by a wireless transmit receive unit, WTRU, characterized in that the method comprises:
sending (<NUM>, 802a, <NUM>), to a server, a message indicating a common multi-user group identifier, ID; receiving (<NUM>, 806a, <NUM>), 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.