Service layer mechanisms to support multi-modal flow management

Abstract

Methods and systems for service layer mechanisms to support multi-modal flow management are disclosed. Individual service enabler flows may be synchronized to support applications that use multiple communication flows in tandem. A multi-modal flow management service may provide monitoring and synchronization capabilities for the individual service enabler flows. The multi-modal flow management service may measure the synchronized individual service enabler flows to determine if deviations from a synchronization threshold occur. The multi-modal flow management service may buffer or delay one or more of the individual service enabler flows to maintain the synchronization of the individual service enabler flows within the synchronization threshold.

Description

SERVICE LAYER MECHANISMS TO SUPPORT MULTI-MODAL FLOWMANAGEMENTCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Application Number 63 / 519,096, filed on August 11, 2023.BACKGROUND

[0002] 3 GPP SA6 has yet to define SEALDD functionality to support the management of multi-modal flows between VAL clients and VAL servers to support use cases, for example the multi-modal flows shown in Figure 1 and Figure 2. Without multi-modal flow management capability, additional complexity and burden is placed on VAL clients and VAL servers to manage multi-modal communications flows themselves in an over-the-top manner. For example, functionality to support the synchronization of multiple VAL traffic flows exchanged between different VAL clients and VAL servers must currently be supported within VAL clients and VAL servers (i.e., in an over-the-top manner). This may include functionality to buffer and synchronize VAL traffic exchanged over different VAL traffic flows such that the VAL traffic arriving over one VAL traffic flow is synchronized with VAL traffic arriving over another VAL traffic flow. This may be challenging for real world deployments since applications may be deployed in a distributed manner requiring VAL clients to be hosted on different UEs. Over-the- top coordination between the VAL clients may be complex and challenging. Likewise, real- world deployments may also comprise multiple VAL servers which service different VAL traffic flows. Over-the-top coordination of VAL traffic between these VAL traffic flows by the different VAL servers may also be complex and challenging.SUMMARY

[0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to beused to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

[0004] The present disclosure proposes multi-modal SEALDD flow management functionality to assist VAL clients and VAL servers from having to manage multi-modal communication flow themselves in an over-the-top manner. Within the SEALDD layer, the following multi-modal SEALDD client and server flow management functionality is defined:

[0005] SEALDD clients and servers equipped with multi-modal SEALDD flow management functionality capable of:

[0006] 1) Receiving a multi-modal flow management request from a VAL client, VAL server, another SEALDD client or SEALDD server, or another entity in the system (e.g., Edge Enabler Server), wherein the request comprises multi-modal flow context comprising information elements such as but not limited to:

[0007] A) multi-modal flow identifier, multi-modal flow control, multi-modal flow status indicator, multi-modal flow KPIs, multi-modal flow members, multi-modal flow member association policies, multi-modal flow data burst policies, multi-modal flow measurement policies, multi-modal flow measurement data, multi-modal flow synchronization policies, multimodal flow access control policies, multi-modal flow subscriptions.

[0008] 2) Based on multi-modal flow context, performing multi-modal SEALDD flow management operations such as:

[0009] A) Establishing, updating, or tearing down a multi-modal SEALDD flow capable of transmitting and receiving VAL traffic from multiple VAL traffic flows in a coordinated manner.

[0010] B) Establishing / associating one or more individual SEALDD flows QoS flows and / or VAL flows with the multi-modal SEALDD flow for the purposes of sending and receiving multi-modal VAL traffic over the multi-modal SEALDD flow, wherein the establishing may involve: i) Sending multi-modal SEALDD flow management requests to other SEALDD clients or SEALDD servers; ii) Sending AF session QoS requests to a 3 GPP network to configure multi-modal QoS flow parameters.

[0011] C) Receiving data bursts from multiple VAL flows associated with the multimodal SEALDD flow and determining which data bursts to group together within a multi-modal data burst based on multi-modal data burst policies.

[0012] D) Determining which SEALDD flow(s) and QoS flow(s) to use to transmit multi-modal data bursts based multi-modal flow context (e.g., multi-modal flow KPIs, multimodal flow data burst policies), wherein this determination may involve: Grouping messages across individual VAL or SEALDD flows of a multi-modal SEALDD flow into one or more PDU sets and sending these messages over one or more QoS Flows associated with the PDU sets.

[0013] E) Collecting measurements pertaining to individual VAL traffic flows and / or multi-modal traffic flows such as end-to-end or round-trip latency, jitter, bandwidth or error rate, wherein collecting of measurements may include: i) Performing multi-modal measurements while processing multi-modal VAL traffic via multi-modal flow; ii) Subscribing to receive multimodal QoS flow measurements from a 3 GPP network and using this information as one component of end-to-end or round-trip measurements; or iii) Receiving measurements from VAL clients or VAL servers and using this information as one component of end-to-end or round-trip measurements.

[0014] F) Synchronizing multi-modal flow traffic based on multi-modal flow measurements and multi-modal flow synchronization policies, wherein synchronization operations may involve: i) Synchronizing the transmission times of multi-modal VAL messages and VAL bursts which are transmitted over the individual VAL and / or SEALDD flows of a multi-modal SEALDD flow; or ii) Buffering SEALDD messages across individual VAL SEALDD flows of a multi-modal SEALDD flow in a coordinated manner such that the SEALDD messages from these flows are forwarded to VAL clients and VAL servers in a synchronized fashion.

[0015] G) Sending multi-modal SEALDD flow measurements and notifications to VAL servers and clients.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The following detailed description is better understood when read in conjunction with the appended drawings. For the purposes of illustration, examples are shown in the drawings; however, the subject matter is not limited to specific elements and instrumentalities disclosed. In the drawings:

[0017] Figure 1 shows an example system.

[0018] Figure 2 shows an example system.

[0019] Figure 3 shows an example system.

[0020] Figure 4 shows an example system.

[0021] Figure 5 shows an example system.

[0022] Figure 6 shows an example system.

[0023] Figure 7 shows an example system.

[0024] Figure 8 shows an example system.

[0025] Figure 9 shows an example method.

[0026] Figure 10 shows an example system.

[0027] Figure 11 shows an example system.

[0028] Figure 12 shows an example method.

[0029] Figure 13 shows an example method.

[0030] Figure 14 shows an example method.

[0031] Figure 15 shows an example system.

[0032] Figure 16 shows an example system.

[0033] Figure 17 shows an example system.

[0034] Figure 18 shows an example system.

[0035] Figure 19 shows an example system.

[0036] Figure 20 shows an example system.

[0037] Figure 21 shows an example method.

[0038] Figure 22 shows an example system.

[0039] Figure 23A shows an example communications system.

[0040] Figure 23B shows an example apparatus configured for wireless communications.

[0041] Figure 23C shows an example system.

[0042] Figure 23D shows an example system.

[0043] Figure 23E shows an example system.

[0044] Figure 23F shows an example system.

[0045] Figure 23G shows an example system.DETAILED DESCRIPTION

[0046] Methods and apparatuses are described herein for supporting multi-modal flow management.

[0047] The following abbreviations and definitions may be used herein:

[0048] Multi-Modal Use Cases

[0049] Single User Multi-Modal Use Case

[0050] It is expected that a growing number of advanced use cases such as AR, XR and Metaverse will require multi-modal inputs originating from more than one source application or apparatus and / or outputs targeting more than one destination application or apparatus. An example is shown in Figure 1 in which a user application has multiple traffic flows related to one another such as traffic from a headset / goggles, audio, haptics, smell, and video. For these types of use cases, separate but coordinated traffic flows may be required to support many (clients, apparatuses, etc.) to many (application servers) topologies. Note that in some cases multiple traffic flows may terminate, on the user side, on the same apparatus or on different apparatuses, which may also be produced by different manufacturers.

[0051] In addition, synchronization of these traffic flows is required to provide the user with a lifelike user experience such that no inconsistencies occur between the user’s senses and the content they are consuming across these different modalities. For example, Table 1 provides some typical synchronization thresholds for immersive multi-modality XR applications.

[0052] Table 1 - Typical Synchronization Thresholds for Immersive Multi -modality XR Applications

[0053] Multi-User Multi-Modal Use Case

[0054] Building even further upon Figure 1 is a multi-user multi-modal use case shown in Figure 2. In this case, not only must multi-modal traffic flows be managed for a single user and their multiple applications and apparatuses, but end-to-end multi-modal traffic flows between users must also be managed. This adds additional challenges and complexities since multi-modal communication flows spanning across multiple network hops must be managed such that all the modalities and their respective communication flows must be synchronized across these multiple network hops to enable effective communication between multiple users and their multiple apparatuses. Note that in some cases the multi-modal traffic may terminate, on the side of each of the users, on the same apparatus or on different apparatuses, which may also be produced by different manufacturers.

[0055] SEAL Data Delivery Enabler (SEALDD)

[0056] Figure 3 shows the architecture for the Service Enabler Architecture Layer Data Delivery (SEALDD) enabler defined by the 3 GPP SA6 working group. SEALDD supports a set of services (SEALDD clients and SEALDD servers) and corresponding reference point APIs to assist with end-to-end distribution, storage, and delivery of application content / data between Vertical Application Layer (VAL) clients and servers. The SEALDD client and SEALDD server supports capabilities such as managing the establishment and tear down of individual SEALDD flows between SEALDD clients and SEALDD servers. These SEALDD flows provide high quality and reliable end-to-end network connectivity between VAL clients and VAL servers. The SEALDD flows also support the capability to measure end-to-end transmission quality between VAL clients and VAL servers and trigger actions if / when needed to maintain required quality of service. For example, switching a SEALDD flow between a SEALDD client and one SEALDD server to another SEALDD server for improved transmission quality.

[0057] SEALDD clients and servers interact with one another over the SEALDD-UU reference point. SEALDD clients provide SEALDD services to VAL clients over the SEALDD- C reference point. SEALDD servers provide services to VAL servers over the SEALDD-S reference point. The SEALDD server(s) may communicate with the underlying 3 GPP network systems using the respective 3GPP reference points specified by the 3GPP network system such as N33, N5 and N6.

[0058] As shown in Figure 4, the SEALDD architecture currently supports managing single / independent SEALDD flows between a SEALDD client and SEALDD server. Via a SEALDD flow, the SEALDD client and server manage the flow of data between a VAL client and a VAL server in an end-to-end fashion.

[0059] Multi-modal SEALDD Flow Management Architecture

[0060] To establish and manage a multi-modal SEALDD flows, multi-modal SEALDD flow management functionality is proposed within SEALDD clients and servers as shown in Figure 5 and Figure 6. This proposed multi-modal SEALDD flow management functionality enables bursts of VAL traffic spanning across multiple VAL flows to be exchanged between multiple VAL clients and VAL servers in a coordinated manner. This functionality enables end- to-end and / or round-trip measurements and synchronization of bursts of VAL traffic spanning across multiple VAL flows. For example, synchronized latency, throughput, and reliability of bursts of VAL traffic spanning across multiple VAL flows.

[0061] For each multi-modal flow of VAL messages exchanged between one or more VAL clients and VAL servers, a multi-modal SEALDD flow may be established. A multi-modal SEALDD flow may be comprised of one or more individual SEALDD flows used to exchange multi-modal VAL traffic between one or more SEALDD clients and SEALDD servers in a coordinated manner. For example, Figure 5 shows a multi-modal use case involving a single UE hosting two VAL clients communicating with two VAL servers. A multi-modal SEALDD flow is used to coordinate the exchange of multi-modal traffic between these VAL clients and VAL servers. This multi-modal SEALDD flow may comprise one individual SEALDD flow or multiple individual SEALDD flows if required.

[0062] Systems and methods are proposed herein for service layer mechanisms to support multi-modal flow management. For example, the system described in Figure 5 maycomprise a first apparatus comprising a processor, a memory, and communication circuitry, the first apparatus being connected to a network via its communication circuitry, the first apparatus further comprising computer-executable instructions stored in the memory of the first apparatus which, when executed by the processor of the first apparatus, cause the first apparatus to perform operations. One operation may comprise receiving, from a second apparatus, a multi-modal flow management request, wherein the request comprises one or more multi-modal flow policies for establishing one or more multi-modal service enabler layer flows each comprising one or more individual service enabler flows. Another operation may comprise determining, based on the one or more multi-modal flow policies provided in the request, at least a first individual service enabler flow and a second individual service enabler flow. Another operation may comprise establishing a multi-modal service enabler flow associated with the first individual service enabler flow and the second individual service enabler flow. Yet another operation may comprise assigning a multi-modal service enabler flow identifier to the established multi-modal service enabler flow.

[0063] The system described in Figure 5 may further cause the first apparatus to perform an operation comprising receiving at least one first message associated with the first individual service enabler flow and at least one second message associated with the second individual service enabler flow. Another operation may comprise synchronizing, based on the one or more multi-modal flow policies provided in the request, the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow.

[0064] The system described in Figure 5 may further cause the first apparatus to perform an operation comprising performing, based on the one or more multi-modal flow policies provided in the request, one or more measurements of the at least one first message associated with the first individual service enabler flow or the at least one second message associated with the second individual service enabler flow.

[0065] The measurements performed by the system described in Figure 5 may further comprise latency measurements.

[0066] The measurements performed by the system described in Figure 5 may further comprise jitter measurements.

[0067] The measurements performed by the system described in Figure 5 may further comprise throughput measurements.

[0068] The system described in Figure 5 may further cause the first apparatus to perform an operation comprising determining, based on the one or more performed measurements, an offset between the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow. Another operation may comprise synchronizing, based on the offset, the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow.

[0069] The synchronizing of the at least one first message and the at least one second message described in Figure 5 may further comprise at least one of buffering or delaying, based on the offset, the at least one message associated with the first individual service enabler flow or the at least one message associated with the second individual service enabler flow.

[0070] For example, Figure 5 may describe a method for receiving a multi-modal flow management request, wherein the request comprises one or more multi-modal flow policies for establishing one or more multi-modal service enabler layer flows each comprising one or more individual service enabler flows. The method may further comprise determining, based on the one or more multi-modal flow policies provided in the request, at least a first individual service enabler flow and a second individual service enabler flow. The method may further comprise establishing a multi-modal service enabler flow associated with the first individual service enabler flow and the second individual service enabler flow. The method may further comprise assigning a multi-modal service enabler flow identifier to the established multi-modal service enabler flow.

[0071] The method described in Figure 5 may further describe receiving at least one first message associated with the first individual service enabler flow and at least one second message associated with the second individual service enabler flow. The method may further comprise synchronizing, based on the one or more multi-modal flow policies provided in the request, the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow.

[0072] The method described in Figure 5 may further describe performing, based on the one or more multi-modal flow policies provided in the request, one or more measurements of the at least one first message associated with the first individual service enabler flow or the at least one second message associated with the second individual service enabler flow.

[0073] The measurements performed in the method described in Figure 5 may further comprise latency measurements.

[0074] The measurements performed in the method described in Figure 5 may further comprise jitter measurements.

[0075] The measurements performed in the method described in Figure 5 may further comprise throughput measurements.

[0076] The method described in Figure 5 may further comprise determining, based on the one or more performed measurements, an offset between the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow. The method may further comprise synchronizing, based on the offset, the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow.

[0077] The synchronizing of the at least one first message and the at least one second message described by the method in Figure 5 may further comprise at least one of buffering or delaying, based on the offset, the at least one message associated with the first individual service enabler flow or the at least one message associated with the second individual service enabler flow.

[0078] Figure 6 shows a multi-modal use case involving multiple UEs hosting multiple VAL clients communicating with multiple VAL servers. A multi-modal SEALDD flow is used to coordinate the exchange of multi-modal traffic between these VAL clients and VAL servers. In this example, the multi-modal SEALDD flow requires multiple individual SEALDD flows to provide connectivity between the different SEALDD clients on the UEs and the SEALDD server.

[0079] Multi-modal SEALDD flows may be used exclusively between SEALDD clients and SEALDD servers to manage the exchange of multi-modal VAL traffic between themselves.Alternatively, multi-modal SEALDD flows may be further exposed to VAL clients and VAL servers as shown as shown in Figure 7 and Figure 8. This exposure may include enhancements to the SEALDD-C reference point between SEALDD clients and VAL clients and / or the SEALDD- S reference point between SEALDD servers and VAL servers to expose multi-model SEALDD flow functionality to VAL clients and VAL servers, respectively. For example, VAL clients and VAL servers may initiate requests to SEALDD clients and SEALDD servers, respectively, to perform multi-modal SEALDD flow operations (e.g., the establishment of a multi-modal SEALDD flow).

[0080] Although the examples defined throughout this invention refer to a SEALDD client and server, one skilled in the art will recognize that other examples may be possible. The proposed mechanisms may be used to enable other types of services with multi-modal flow management support. For example, an XR or Metaverse service supporting client and server functionality may be equipped with the multi-modal flow management functionality proposed by this invention. For such cases, the proposed multi-modal SEALDD client functionality may instead be supported by a XR or Metaverse client. Likewise, the proposed multi-modal SEALDD server functionality may instead be supported by a XR or Metaverse server. Alternatively, the proposed multi-modal SEALDD client or server functionality may be split between an XR or Metaverse client or server and a SEALDD client or server. In this case, a XR or Metaverse client or server may interwork with a SEALDD client or server to realize the proposed multi-modal functionality.

[0081] Multi-modal SEALDD Flow Context

[0082] SEALED clients and servers may be configured with certain types of multi-modal SEALDD flow context. For example, multi-modal SEALDD flow context may exist within one or more policies that are configured onto a SEALDD client or server, and which are used by the SEALDD client or server to manage multi-modal SEALDD flows. SEALDD clients and servers may also collect and maintain certain types of multi-modal SEALDD flow context such as multimodal flow measurement data.

[0083] Multi-modal SEALDD flow context may be comprised of one or more information elements such as but not limited to those defined in Table 2. These information elements may pertain to a multi-modal SEALDD flow and / or the individual VAL or SEALDDflows associated with a multi-modal SEALDD flow. This context may comprise information stored and maintained by one or more SEALDD clients and / or SEALDD servers. The multimodal SEALDD flow context may be stored and maintained on a single entity in the system (e.g., on a SEALDD server) or distributed across multiple entities in the system (e.g., on a SEALDD client and SEALDD server). If multi-modal SEALDD flow context is stored and maintained in a distributed manner, methods such as the ones proposed in this invention may be used to maintain synchronization between the multiple instances of the multi-modal SEALDD flow context. In addition, if multi-modal SEALDD flow context is stored and maintained in a distributed manner, some entities may only require storing a subset of the context (e.g., a SEALDD client may only require storing a subset of the context while the SEALDD server may store the complete set of context). Note, the information shown in Table 2 may be grouped together into one or more policies. A SEALDD client or SEALDD server may be configured with these one or more policies and in turn use these one or more policies to manage multimodal SEALDD flows. A SEALDD client or SEALDD server may be configured with the one or more policies based on procedures proposed in this invention and / or by other means.

[0084] Table 2 - Multi-Modal SEALDD Flow Context Information Elements

[0085] VAL Client / Server Initiated Multi-modal SEALDD Flow Requests

[0086] VAL clients or VAL servers may initiate multi-modal SEALDD flow management requests to SEALDD clients or SEALDD servers. These operations may be initiated based on the occurrence of trigger conditions such as the launching of an XRapplication or one or more VAL clients or VAL servers detecting the need to synchronize multiple VAL flows with one another to meet the communication requirements of multi-modal applications.

[0087] Although the procedure defined in Figure 9 refers to a VAL client or VAL server initiating these requests, one skilled in the art will recognize that other entities may also issue these requests. For example, an analytics server (AD AES) or an Edge Enabler Server (EES) may initiate a multi-modal SEALDD flow request to a SEALDD client or SEALDD server.

[0088] As shown in Figure 9, VAL clients and servers may send a multi-modal SEALDD flow request to a SEALDD client or server. A multi-modal SEALDD flow may be established when a VAL client or server wants to use multi-modal SEALDD services. Upon the creation of a multi-modal SEALDD flow, multi-modal SEALDD flow context as shown in Table 2 may be created and stored within SEALDD clients and / or servers to manage the flow. If a multi-modal SEALDD flow has already been created, the existing flow may be updated (e.g., to enable or disable flow) by adding, modifying, or deleting the multi-modal SEALDD flow context.

[0089] Step 1 : A VAL client or server may issue a multi-modal SEALDD flow management request to a SEALDD client or server. The request may include but is not limited to one or more of the information elements defined in Table 3.

[0090] Table 3 - Multi-Modal SEALDD Flow Management Request Information Elements

[0091] Step 2: Upon receiving the multi-modal SEALDD flow management request, the targeted SEALDD client or server may process the request by first checking whether the VAL client or server originating the request has permissions to perform the multi-modal SEALDD flow operation specified in the request. The SEALDD client or server may check the VAL client or server ID specified in the request matches an ID specified in the access control privileges of the SEALDD client or server. The check may also include verifying the type of requested multimodal SEALDD flow operation is permitted as well as the operation is allowed to be performed at the current time and / or from the current location that the VAL client or server resides. If allowed, the SEALDD client or server may process the operation. During the processing, the SEALDD client or server may create, retrieve / discover, update or delete multi-modal SEALDD flow context depending on the type of operation being performed.

[0092] If the request is to create or update a multi-modal SEALDD flow, the SEALDD client or server may perform one or more of the following operations based on multi-modal SEALDD flow context information sent within the request. In addition, the SEALDD client or server may also perform one or more operations described in one or more of the other procedures defined in this invention.

[0093] 1) Identify one or more multi-modal SEALDD flows associated with the request. If a new multi-modal SEALDD flow is being created and a flow is not specified in the request, a new multi-modal SEALDD flow may be generated, and a new multi-modal SEALDD flow IDmay be assigned by the SEALDD client or server. This new multi-modal SEALDD flow ID may be stored within the flow context and used to manage the multi-modal SEALDD flow.

[0094] 2) Determine one or more individual VAL or SEALDD flows associated with the multi-modal SEALDD flow using information specified in the request or stored within existing multi-modal SEALDD context. For example, a multi-modal flow ID or and application identifier associated with a multi-modal SEALDD flow ID may be used to make this determination.

[0095] 3) Determine applicable SEALDD clients or servers of the source or destination flow endpoints. This determination may involve using information specified in the request and / or querying information stored locally on the SEALDD client or server, information stored on remote SEALDD client(s) or server(s), or information stored on another node in the network. The presence of a multi-modal flow ID within the request may trigger a SEALDD client or server to perform an operation to discover a common SEALDD server to process the multimodal SEALDD flow. After determining a common SEALDD server, the SEALDD client or server may determine to forward the request to update the multi-modal flow to this common SEALDD server to process.

[0096] 4) Determine QoS flow requirements for this multi-modal SEALDD flow and configure the 3 GPP network accordingly.

[0097] 5) If the multi-modal SEALDD flow ID is configured in the received request, determine if any remote multi-modal SEALDD flow context(s) exist for this flow ID. This determination may involve querying information stored locally on the SEALDD client or server, information stored on remote SEALDD client(s) or server(s), or information stored on another node in the network.

[0098] 6) Determine whether to enable the multi-modal SEALDD flow. This determination may be based on information specified in the request. Alternatively, the flow may be enabled upon creation of the flow by the SEALDD client or server.

[0099] 7) The flow may be enabled, and the flow status may be updated to reflect whether the flow is enabled.

[0100] 8) Based on any multi-modal SEALDD flow measurement policies specified within the request and / or based on local policies of the SEALDD client or server, collect and store multi-modal SEALDD flow measurements.

[0101] 9) Based on multi-modal SEALDD flow synchronization policies within the request and / or based on local policies of the SEALDD client or server, start to synchronize incoming messages received via one or more individual VAL or SEALDD flows associated with the multi-modal SEALDD flow such that messages across the individual flows are synchronized in an end-to-end manner with respect to one another.

[0102] 10) Based on access control policies within the request and / or any local access control policies of the SEALDD client or server, configure the access control policies for the created multi-modal SEALDD flow.

[0103] 11) Based on subscription information within the request and / or any local subscription policies of the SEALDD client or server, create and configure subscriptions to the multi-modal SEALDD flow.

[0104] If the request is to retrieve or discover context for multi-modal SEALDD flows, the SEALDD client or server may check whether the request includes filter criteria. If present, the SEALDD client or server compares the specified filter criteria against the multi-modal SEALDD flow context that the SEALDD client or server hosts to determine whether any flow context matches the filter criteria.

[0105] If the request is to subscribe to receive notifications regarding multi-modal SEALDD flows, the SEALDD client or server may create the subscription based on the multimodal SEALDD flow notification criteria specified in the subscription request. Thereafter the SEALDD client or server may begin to monitor the multi-modal SEALDD flow and detect if / when the criteria defined in the multi-modal SEALDD flow notification criteria have been met. If / when the criteria have been met, the SEALDD client or server may send a notification to the VAL client or server. The notification may include one or more elements of the multi-modal SEALDD flow context.

[0106] If the request is a multi-modal SEALDD flow tear down request, the SEALDD client or server may perform one or more of the following operations based on multi-modal SEALDD flow context information sent within the request:

[0107] 1) Delay processing of the tear down request until the SEALDD client or server finishes any outstanding VAL message transmission or reception processing via the multi-modal SEALDD flow.

[0108] 2) Trigger the tear-down of any underlying transports (redundant or non- redundant) associated with the multi-modal SEALDD flow (and any corresponding QoS flows)

[0109] 3) Stop collecting measurements associated with the multi-modal SEALDD flow

[0110] 4) Notify VAL clients and servers who are subscribers of the multi-modal SEALDD flow, that the flow is being torn down

[0111] 5) Notify remote SEALDD clients and servers having context for the multi-modal SEALDD flow, that the flow is being torn down

[0112] 6) Reject any subsequent requests attempting to transmit or receive VAL messages via the multi-modal SEALDD flow

[0113] 7) Delete any stored measurements associated with the multi-modal SEALDD flow

[0114] 8) Delete any cached VAL response messages associated with the multi-modal SEALDD flow

[0115] 9) Delete any stored (buffered) messages associated with the multi-modal SEALDD flow

[0116] 10) Delete any access control policies associated with the multi-modal SEALDD flow

[0117] 11) Delete any subscriptions associated with the multi-modal SEALDD flow and stop sending notifications to subscribers

[0118] Step 3: Generate and return a multi-modal SEALDD flow response to the VAL client or VAL server that originated the request. Where the response may include but is not limited to one or more of the information elements defined in Table 4.

[0119] Table 4 - Multi-Modal SEALDD Flow Management Response Information Elements

[0120] Note, if filter criteria is included in the request, and one or more multi-modal SEALDD flow contexts are found to match the filter criteria, representations of the flow context(s) may be returned in a response to the VAL client or server that originated the request. Otherwise, an error indication may be returned in the response.

[0121] SEALDD Client / Server Multi-modal SEALDD Flow Operations

[0122] SEALDD clients or SEALDD servers may perform one or more types of multimodal SEALDD flow management operations. Some examples of operations, may include but are not limited to one or more of the following:

[0123] 1) Interfacing to a 3GPP core network to configure multi-modal AF session QoS config settings for QoS flows used by a multi-modal SEALDD flow

[0124] 2) Managing bursts of VAL messages communicated end-to-end and / or roundtrip between VAL client(s) and VAL server(s) via a multi-modal SEALDD flow

[0125] 3) Measuring multi-modal centric KPIs for VAL traffic communicated end-to-end and / or round-trip between VAL client(s) and VAL server(s) over a multi-modal SEALDD flow

[0126] 4) Synchronizing VAL traffic communicated end-to-end and / or round-trip between VAL client(s) and VAL server(s) over a multi-modal SEALDD flow

[0127] 5) Sending multi-modal SEALDD flow measurements I event notifications to VAL servers / clients

[0128] These operations may be triggered and performed by SEALDD clients or SEALDD servers when receiving the aforementioned multi-modal flow requests initiated by VAL clients or VAL servers. SEALDD clients or SEALDD servers may also perform these operations in response to requests received from other types of entities. For example, SEALDD clients or SEALDD servers may receive requests to perform multi-modal flow management operations from other entities. For example, edge enabler services (e.g., EES, EEC, ECS), analytics services (e.g., AD AES, NWDAF), Personal loT Network (PIN) services (e.g., PIN Server, PEGC, PEMC), or network exposure functions (e.g., NEF). SEALDD clients or SEALDD servers may also perform multi-modal flow management operations in an autonomousor semi-autonomous manner. For example, a SEALDD client or SEALDD server may perform multi-modal SEALDD flow management operations based on a provisioned multi-modal SEALDD flow management policies such as those defined in Table 2. The policies may include conditions / rules used by a SEALDD client or server to trigger if / when to perform one or more types of multi-modal SEALDD flow management operations.

[0129] Multi-modal Flow Management Requests between SEALDD Clients and Servers

[0130] When establishing a multi-modal SEALDD flow for use cases involving a single UE as shown in Figure 10, a SEALDD client or SEALDD server may establish and / or associate one or more individual SEALDD flows, QoS flows and / or VAL flows with the multi-modal SEALDD flow such that they may be used to send and receive multi-modal VAL traffic over the multi-modal SEALDD flow.

[0131] Likewise, for use cases involving more than one UE as shown in Figure 11, each UE may have its own SEALDD client. In these scenarios, multiple SEALDD clients may coordinate with a common SEALDD server to establish and manage the multi-modal SEALDD flow. Alternatively, each SEALDD client may create a multi-modal flow locally and request the common SEALDD server to combine the two multi-modal flows into one. The SEALDD clients and SEALDD server may associate one or more individual SEALDD flows, QoS flows and / or VAL flows with the multi-modal SEALDD flow for the purposes of sending and receiving multimodal VAL traffic over the multi-modal SEALDD flow.

[0132] To establish and manage a multi-modal SEALDD flow, SEALDD clients and SEALDD servers may exchange multi-modal SEALDD flow management requests and responses with one another as shown in Figure 12.

[0133] Step 1: A SEALDD client or SEALDD server may issue a multi-modal SEALDD flow management request to another SEALDD client or SEALDD server. The request may include but is not limited to one or more of the information elements defined in Table 3.

[0134] Step 2: Upon receiving the multi-modal SEALDD flow management request, the targeted SEALDD client or server may process the request by performing one or more of the operations described in Step 2 of the procedure for Figure 9, with the exception that rather than a VAL client or VAL server initiating the request, a SEALDD client or SEALDD server initiatesthe request. In addition, SEALDD clients or SEALDD servers may also perform one or more of the following operations as part of the handling of this request:

[0135] 1) Inform another SEALDD client or SEALDD server of a multi-modal SEALDD flow that has been established, updated, or torn down.

[0136] 2) Synchronize multi-modal SEALDD flow context across SEALDD clients and SEALDD servers managing the same multi-modal SEALDD flow.

[0137] 3) Perform a multi-modal QoS flow operation (e.g., AF session with QoS request) to a 3 GPP network.

[0138] Step 3: A SEALDD client or SEALDD server may generate and return a multimodal SEALDD flow response to the SEALDD client or SEALDD server that originated the request. The response may include but is not limited to one or more of the information elements defined in Table 4.

[0139] Multi-modal Flow Management between SEALDD Server and 3GPP Core Network

[0140] Multi-Modal AF Session with QoS Request Management by SEALDD Server

[0141] When managing a multi-modal SEALDD flow, SEALDD server may interface with the 3GPP network using the procedure shown in Figure 13 to configure multi-modal QoS flows for one or more PDU sessions. For example, a SEALDD server may do this when receiving a request from a SEALDD client or VAL server to establish a multi-modal SEALDD flow.

[0142] Step 1: A SEALDD server may send one or more multi-modal AF Session with QoS requests to a 3 GPP network for each multi-modal SEALDD flow the SEALDD server manages. Using multi-modal SEALDD context such as the information elements defined in Table 2 (e g., multi-modal flow data burst policies), a SEALDD server may determine multimodal QoS flow parameter values for the AF Session with QoS requests the SEALDD server sends to the 3GPP network. The parameters may include one or more of the following:

[0143] 1) a common identifier (e.g., multi-modal SEALDD Flow ID) used across AF Session with QoS requests, indicating QoS flows belonging to the same multi-modal SEALDD flow,

[0144] 2) a periodicity of multi-modal SEALDD data bursts expected to be sent over this QoS flow and / or PDU set,

[0145] 3) an expected usage time or volume of traffic expected to be sent over this QoS flow and / or PDU set,

[0146] 4) a requested delay / latency for sending multi-modal SEALDD bursts over this QoS flow and / or PDU set,

[0147] 5) a requested priority for sending multi-modal SEALDD bursts over this QoS flow and / or PDU set,

[0148] 6) a requested burst size for sending multi-modal SEALDD bursts over this QoS flow and / or PDU set,

[0149] 7) a requested packet error rate for sending multi-modal SEALDD bursts over this QoS flow and / or PDU set.

[0150] The SEALDD server may need to manage and align the parameters across multiple AF session with QoS requests for the different UEs participating in a multi-modal flow. This may be required to ensure the multi-modal traffic aligns with the specified multi-modal SEALDD flow synchronization requirements.

[0151] Step 2: Upon receiving the one or more multi-modal AF Session with QoS requests, the 3GPP network may process the requests and configure the one or more multi-modal QoS flows and / or PDU set with the parameter values specified by the SEALDD server.

[0152] Step 3: A SEALDD server may receive one or more multi-modal AF Session with QoS responses from a 3 GPP network for each multi-modal SEALDD flow the SEALDD server manages. Within the response, the SEALDD server may receive an indication of whether the AF Session with QoS was successfully configured.

[0153] Multi-Modal QoS Flow Monitoring by SEALDD Server

[0154] A SEALDD server may interface to the 3GPP network to issue multi-modal QoS flow monitoring requests, and in turn receive multi-modal QoS flow notifications from the 3GPP network. A SEALDD server may issue a QoS flow monitoring request using the AF Session with QoS API and including a callback URI which the 3 GPP network may use to send QoS flow notifications to the SEALDD server. A SEALDD server may use information provided in these notifications to help manage multi-modal SEALDD flows. For example, the 3GPP network mayprovide deltas in data rates between different QoS flows associated with the different UEs participating in a multi-modal SEALDD flow. The SEALDD server may take this information into account when calculating end-to-end and round-trip measurements for the multi-modal SEALDD flow.

[0155] Step 1: A SEALDD server may send one or more AF Session with QoS API requests to monitor multi-modal QoS flows and / or PDU set in the 3 GPP network which are associated with a SEALDD multi-modal flow. Within the request, the SEALDD server may include QoS monitoring requirements for one or more QoS flows and / or PDU sets associated with the multi-modal SEALDD flow.

[0156] The requests may include one or more of the following parameters:

[0157] 1) a common identifier (e.g., multi-modal SEALDD Flow ID) used across QoS flows and / or PDU sets belonging to the same multi-modal SEALDD flow,

[0158] 2) one more conditions / criteria of interest related to QoS flows and / or PDU sets such as a latency, bandwidth, burst size, jitter, or error rate threshold,

[0159] 3) SEALDD server callback URI which the 3GPP network may use to send QoS flow notifications to the SEALDD server.

[0160] Step 2: Upon receiving the one or more requests, the 3GPP network may process the requests and begin monitoring the applicable QoS flows and / or PDU sets based on specified information from the request.

[0161] Step 3: The SEALDD server may receive one or more responses from the 3GPP network indicating that the 3GPP network received and processed the monitoring requests. Each response may include a status indicator of whether the request was successfully processed along with a monitoring subscription identifier.

[0162] Step 4: The 3GPP network may monitor and detect if / when the QoS flow monitoring criteria specified in a monitoring request are detected.

[0163] Step 5: The SEALDD server may receive QoS flow monitoring notifications from the 3GPP network. A QoS flow monitoring notification may comprise on or more of the following parameters:

[0164] 1) a QoS flow monitoring subscription identifier,

[0165] 2) a measurement pertaining to an individual QoS flow and / or PDU set or multiple QoS flows and / or PDU sets associated with the same multi-modal SEALDD flow (e.g., delta measurements between QoS flows),

[0166] 3) an event such as a congestion event related to a QoS flow and / or PDU set.

[0167] Step 6: Upon receiving a QoS flow monitoring notifications, a SEALDD server may extract the information and perform one or more multi-modal SEALDD flow management operations such as the following:

[0168] 1) Incorporate measurement information provided in the notification into multimodal SEALDD flow end-to-end or round-trip measurements which the SEALDD server calculates. For example, a notification may note an uplink or downlink delay of a data flow between a UE and the N6 termination point of a UPF. A SEALDD server may use this information as a component of the end-to-end or round-trip latency the SEALDD server computes between VAL clients and VAL servers. A SEALDD server may also use this information to determine what percentage of the overall end-to-end or round-trip latency budget is consumed by the measured by the UE and the N6 communication leg.

[0169] 2) Perform one or more synchronization operations based on information provided in the notification. For example, the SEALDD server may detect that the different QoS flows and / or PDU sets that are being used for the multi-modal SEALDD flow have different communication deltas (e.g., latency, bandwidth, jitter, error rates). Using this information the SEALDD server may perform synchronization operations to align VAL traffic communicated over these different QoS flows and / or PDU sets. A SEALDD server may also update and / or switch the QoS flows or PDU sets the SEALDD server is using for the multi-modal SEALDD flow to transfer VAL traffic. For example, the SEALDD server may issue one or more AF Session with QoS requests (as described in Figure 13) to update parameters in existing QoS flows and / or PDU sets or to allocate and use new QoS flows and PDU sets.

[0170] Multi-Modal SEALDD Flow Measurements

[0171] A SEALDD client or server may collect measurements pertaining to a multimodal SEALDD flow. The collection of these measurements may be controlled by multi-modal SEALDD flow measurement policies such as the ones defined in Table 2. A SEALDD client or server may perform these measurements during the processing of traffic via the multi-modalSEALDD flow. The SEALDD client and server may capture measurements such as latency, jitter, throughput and error rate. The measurements may be collected for individual messages or bursts of messages. These measurements may be collected for individual VAL or SEALDD flows which are members of a multi-modal SEALDD flow. For example, deltas in end-to-end or round-trip KPIs (e.g. latency, jitter, throughput, or reliability) may be measured for messages exchanged between the different individual VAL clients and VAL servers. These measurements may be used to determine variations and offsets across the different individual flows. Measurements may also be collected across the entire multi-modal SEALDD flow. For example, measurements may be taken for multi-modal SEALDD bursts which include messages that span across the individual VAL or SEALDD flows which are members of the multi-modal SEALDD flow. These measurements may be collected between messages within the same multi-modal SEALDD burst, or measurements may be collected between consecutive multi-modal SEALDD data bursts.

[0172] Multi-modal SEALDD flow measurement data may be stored locally by a SEALDD client or server. Alternatively, the measurement data may be stored elsewhere by a SEALDD client or server such as a data repository service in the system. Multi-modal SEALDD flow measurement data may be used to perform multi-modal SEALDD flow management operations such as synchronizing end-to-end and / or round-trip transmission and reception times of multi-modal messages that are exchanged via VAL client(s) and VAL server(s) via the multimodal SEALDD flow. Multi-modal SEALDD flow measurement data may also be shared with VAL client and VAL servers. For example, a VAL client or server may subscribe to receive notifications from a SEALDD client or server based on multi-modal SEALDD flow measurements. Notifications may be conditionally sent to VAL clients or servers based on if / when notification criteria contingent up measurement thresholds of interest to VAL clients or servers have been exceeded.

[0173] Measurements may be performed entirely by SEALDD clients and / or SEALDD servers (e.g., via the use of multi-modal SEALDD measurement policies). Alternatively, SEALDD clients or servers may interface to other entities in the system which perform measurements which are shared with SEALDD clients or servers. For example, SEALDD clients or servers may receive measurements from entities in the 3 GPP network as described for theprocedure shown in Figure 14. SEALDD clients or servers may also receive measurements collected from VAL clients or VAL servers. For example, a VAL client or VAL server may provide end-to-end and / or round-trip measurement information for VAL messages they send and / or receive. A SEALDD client or server may incorporate and use these measurements from other entities in the system to manage multi-modal SEALDD flows as well as achieve more accurate and precise multi-modal measurements and levels of synchronization.

[0174] Multi-Modal SEALDD Flow Synchronization

[0175] Based on the aforementioned multi-modal flow measurements, a SEALDD client or server may detect if / when multi-modal SEALDD flow synchronization is required and perform synchronization actions such in order to prevent synchronization thresholds from being exceeded. Synchronization thresholds and actions may be defined within multi-modal SEALDD flow synchronization policies such as those defined in Table 2.

[0176] If a multi-modal SEALDD flow synchronization threshold is in jeopardy of being exceeded, the SEALDD client or SEALDD server may perform one or more actions to synchronize multi-modal traffic. For example, a SEALDD client or server may selectively delay and / or buffer multi-modal VAL or SEALDD traffic that is being transmitted or received such that offsets are more closely aligned. This delaying and / or buffering of traffic may be done on an individual VAL or SEALDD message basis, on an individual VAL data burst basis, on an individual VAL or SEALDD flow basis, on a multi-modal SEALDD data burst basis, or on an overall multi-modal SEALDD flow basis. As a result, end-to-end and / or round-trip multi-modal traffic may be synchronized by a SEALDD client or SEALDD server.

[0177] Another type of synchronization action that a SEALDD client or SEALDD server may perform to address multi-modal SEALDD flow synchronization issues is to reconfigure settings in the 3 GPP network. When detecting a multi-modal SEALDD flow synchronization issue, a SEALDD client or server may configure / reconfigure one or more multi-modal QoS flows and / or PDU sets that are used by the multi-modal SEALDD flow. A SEALED server may perform these operations using the AF Session with QoS procedure defined in Figure 13.

[0178] Multi-Modal SEALDD Flow Burst Management (Single UE Scenario)

[0179] Once a multi-modal SEALDD flow has been established, the multi-modal SEALDD flow may be used to exchange multi-modal traffic between VAL clients and VALservers in a coordinated and synchronized manner. Figure 15 shows a multi-modal example involving a single UE. Multiple VAL clients are hosted on this UE. Each VAL client generates a mobile originated flow of messages which target a VAL server in the network. Within each flow, bursts of VAL messages occur based on VAL activity. Based on the multi-modal requirements, the data bursts occurring in each of the flows must be synchronized with one another and arrive at the VAL servers in the network at the same time. To satisfy this multi-modal requirement, a SEALDD client is also hosted on the UE. The VAL clients interface to this SEALDD client and send their VAL messages to the SEALDD client.

[0180] Upon receiving the VAL data bursts from each VAL client, the SEALDD client hosted on the UE may use multi-modal SEALDD flow context to determine VAL flows that are associated with one another as well as associated with a multi-modal SEALDD flow. The SEALDD client may also use multi-modal SEALDD flow context to determine multi-modal data burst requirements. This may include the SEALDD client determining which messages within each of the VAL flows require bursting with one another, as well as which messages across the different VAL flows require bursting with one another. Based on this information, the SEALDD client may form multi-modal SEALDD data bursts comprising VAL messages from each VAL flow. The SEALDD client may associate the VAL messages to SEALDD flow, QoS flow(s) and / or PDU sets in order to send the multi-modal SEALDD data bursts to a SEALDD server. For example, as shown in Figure 16, a SEALDD client may select a SEALDD flow associated with a single QoS flow to send multi-modal SEALDD data bursts within a single PDU set. Use of a single PDU set to transmit the multi-modal SEALDD data burst to the SEALDD server increases the chances of all the VAL messages in the multi-modal SEALDD data burst arriving in a manner which meets the multi-modal requirements of the VAL client and VAL server.

[0181] Note, when receiving the VAL messages from each of the VAL clients, the SEALDD client may perform one or more aforementioned multi-modal SEALDD measurement and synchronization operations. For example, the SEALDD client may buffer and align incoming messages the SEALDD client receives from the different VAL clients before sending the messages to the SEALDD server.

[0182] Upon receiving multi-modal SEALDD data bursts from a SEALDD client, the SEALDD server may use multi-modal SEALDD flow context to determine the multi-modal databurst and synchronization requirements. This may include the SEALDD server determining if the VAL messages the SEALDD server receives within the multi-modal SEALDD data bursts meet the end-to-end and / or round-trip data burst and synchronization requirements. This determination may be made by the SEALDD server performing aforementioned multi-modal SEALDD flow measurements such as the inter-arrival time of messages within each of the multimodal data bursts as well as the inter-arrival time between multi-modal data bursts. Based on these measurements, the SEALDD server may determine whether multi-modal synchronization operations need to be performed before forwarding the messages / bursts to VAL server(s). The SEALDD server may perform aforementioned multi-modal SEALDD flow synchronization operations such as buffering VAL messages associated with a given multi-modal data burst when they arrive at the SEALDD server, and synchronizing the messages before they are forwarded to one or more VAL servers. Where synchronizing the VAL messages may involve modifying the inter-message delay between each message in a multi-modal burst such that the inter-message delay is a specific duration and is consistent between each message. Likewise, a SEALDD server may perform similar synchronization operations between multi-modal data bursts to ensure that the duration of time between the last message of one data burst and the first message of the next data burst are consistent across a sequence of multi-modal data bursts. In doing so, the SEALDD server ensures that individual VAL messages as well as the bursts in which they are associated with are sent to VAL server(s) in a synchronized fashion as shown in Figure 17. For example, times such as ti, t?, ts, t4, ts may be synchronized by the SEALDD server as the SEALDD server processes multi-modal VAL traffic.

[0183] Although the procedures defined in Figure 15, Figure 16, and Figure 17 refer to a mobile originated use case involving VAL clients sending multi-modal VAL traffic to VAL servers over a multi-modal SEALDD flow, one skilled in the art will recognize similar procedures may be defined and used to support the sending of mobile terminated multi-modal VAL traffic from VAL servers to VAL clients over a multi-modal SEALDD flow.

[0184] Multi-Modal SEALDD Flow Burst Management (Multiple UE Scenario)

[0185] As shown in Figure 18, some multi-modal use cases may involve more than just one UE. For these use cases, multi-modal VAL clients are hosted on different UEs. These VAL clients require sending and / or receiving flows of VAL messages to / from potentially differentVAL servers in the network. In addition, the separate VAL flows spanning across different UEs may require synchronization between them in order to meet multi-modal use case requirements.

[0186] As shown in Figure 19, each UE may host its own SEALDD client. These SEALDD clients may interface to a common SEALDD server which may provide multi-mode SEALDD flow coordination for the different SEALDD clients. For example, the common SEALDD server may provide each SEALDD client with multi-modal SEALDD flow context as well as help the SEALDD clients keep their local copies of multi-modal SEALDD flow context synchronized and up to date with both the SEALDD server as well as other SEALDD clients participating in the same multi-modal SEALDD flows.

[0187] Upon receiving the VAL data bursts from each VAL client hosted on the same UE, the SEALDD client hosted on the same UE may use multi-modal synchronized SEALDD flow context to determine VAL flows that are associated with one another as well as associated with a multi-modal SEALDD flow. Each SEALDD client may also use multi-modal SEALDD flow context to determine multi-modal data burst requirements. This may include each SEALDD client determining which messages within each of the VAL flows require bursting with one another, as well as which messages across the different VAL flows require bursting with one another. Based on this information, each SEALDD client may form multi-modal SEALDD data bursts comprising VAL messages from each VAL flow. The SEALDD client may determine which SEALDD flow and QoS flow(s) to use in order to send the multi-modal SEALDD data bursts to a SEALDD server. For example, as shown in Figure 19, SEALDD client 1 may select a SEALDD flow and QoS flow associated with the multi-modal SEALDD flow and also associated with UE 1. Whereas SEALDD client 2 may select a different SEALDD flow and QoS flow associated with the multi-modal SEALDD flow and also associated with UE 2.

[0188] Note, when receiving the VAL messages from each of the VAL clients, each SEALDD client may perform one or more aforementioned multi-modal SEALDD measurement and synchronization operations. For example, each SEALDD client may buffer and align incoming messages received from each SEALDD client’s local VAL client(s) before sending the messages to the SEALDD server.

[0189] Upon receiving multi-modal SEALDD data bursts comprising VAL messages from both SEALDD client 1 and SEALDD client 2, the SEALDD server may use multi-modalSEALDD flow context to determine the multi-modal data burst and synchronization requirements. This may include the SEALDD server determining if the VAL messages the SEALDD server receives within the multi-modal SEALDD data bursts meet the end-to-end data burst and synchronization requirements. This determination may be made by the SEALDD server performing aforementioned multi-modal SEALDD flow measurements such as the interarrival time of messages within each of the multi-modal data bursts as well as the inter-arrival time between multi-modal data bursts. Based on these measurements, the SEALDD server may determine whether multi-modal synchronization operations should be performed before forwarding the VAL messages the SEALDD server receives from the multiple UEs to the targeted VAL server(s). If needed, the SEALDD server may perform aforementioned multimodal SEALDD flow synchronization operations such as buffering VAL messages associated with a given multi-modal data burst when they arrive at the SEALDD server (regardless of whether they are received from SEALDD client 1 or SEALDD client 2) and synchronizing the messages before they are forwarded to one or more VAL servers. Synchronizing the VAL messages may involve modifying the inter-message delay between each message in a multimodal burst such that the inter-message delay is a specific duration and is consistent between each message. Likewise, a SEALDD server may perform similar synchronization operations between multi-modal data bursts to ensure that the duration of time between the last message of one data burst and the first message of the next data burst are consistent across a sequence of multi-modal data bursts. In doing so, the SEALDD server ensures that bursts of VAL messages sent to VAL server(s) are synchronized with one another as shown in Figure 20. For example, times such as ti, t2, ts, t4, ts, t6 may be synchronized by the SEALDD server as the SEALDD server processes multi-modal VAL traffic.

[0190] Although the procedures defined in Figure 18, Figure 19, and Figure 20 refer to a mobile originated use case involving VAL clients on multiple UEs sending multi-modal VAL traffic to VAL servers over a multi-modal SEALDD flow, one skilled in the art will recognize similar procedures may be defined and used to support the sending of mobile terminated multimodal VAL traffic from VAL servers to VAL clients on multiple UEs over a multi-modal SEALDD flow.

[0191] Multi-Modal SEALDD Flow Notifications

[0192] As shown in Figure 21, VAL clients or VAL servers may receive a notification from a SEALDD client or SEALDD server regarding a multi-modal SEALDD flow.

[0193] Step 1 : If / when A SEALDD client or SEALDD server detects that the notification criteria defined within a multi-modal SEALDD flow subscription has been met, the SEALDD client or SEALDD server generates a SEALDD notification that may include but is not limited to one or more of the information elements defined in Table 5.

[0194] Table 5 - Multi-Modal SEALDD Flow Notification Request Information Elements

[0195] Step 2: Upon receiving the multi-modal SEALDD flow notification request, the VAL client or server may perform one or more operations such as but not limited to the following:

[0196] 1) Extract and process multi-modal SEALDD flow context information included within the notification to detect a multi-modal SEALDD flow being created, modified, enabled, disabled, or tom down

[0197] 2) Extract and process SEALDD events included within the notification to detect events such as but bit limited to the following:

[0198] A) The status a multi-modal SEALDD flow has changed (e.g., transitioned from enabled to disabled)

[0199] B) Multi-modal requirements could not be met for one or more VAL messages communicated over multi-modal SEALDD flow

[0200] C) Multi-modal requirements could not be met for one or more VAL messages communicated over multi-modal SEALDD flow

[0201] D) SEALDD client or server requests end-to-end or round-trip measurements from VAL client or VAL server regarding multi-modal flow traffic

[0202] E) The current or scheduled availability of one or more multi-modal SEALDD flow endpoints has changed (e.g., VAL client or server has disconnected or reconnected to the network)

[0203] 2) Perform one or more actions in response to a multi-modal SEALDD flow notification such as but not limited to the following:

[0204] A) Update multi-modal SEALDD flow context I policies to modify how SEALDD clients or SEALDD servers manage the flow

[0205] B) Provide end-to-end or round-trip measurements regarding multi-modal flow traffic to SEALDD client or SEALDD server

[0206] C) Throttle and / or schedule the transmission of muti-modal VAL traffic.

[0207] Step 3: The VAL client or server may generate and return a multi-modal SEALDD flow notification response to the SEALDD client or server that originated the notification request. Where the notification response may include but is not limited to one or more of the information elements defined in Table 6.

[0208] Table 6 - Multi-Modal SEALDD Flow Context Notification Response Information Elements

[0209] RESTful Multi-Modal SEALDD Flow Context Example

[0210] In one example, SEALDD clients and servers may implement multi-modal SEALDD flow context as RESTful resources. The resources may have unique addresses (e.g. URIs, URNs, etc.) and may also have one or more attributes that describe resource data and / or metadata. These flow context resources may be created, retrieved, discovered, updated, or deleted by VAL clients and servers, other entities such as EESs, ECSs, as well as other SEALDD clients and servers. The SEALDD clients and servers may support APIs for these resource that are based on RESTful protocols such as HTTP and CoAP. In addition, subscriptions may also be made to flow contexts resources to receive notifications if / when any modifications are made to the resources.

[0211] Pub / Sub Multi-Modal SEALDD Flow Context Example

[0212] In another example, SEALDD clients and servers may implement multi-modal SEALDD flow context as topics within the topic space of a message broker (e.g., MQTT broker, AMQP broker, etc.). A SEALDD client and / or server may function as the message broker. Alternatively, the message broker may be hosted external to the SEALDD client and / or server by another node or function in the network which the SEALDD client and / or server communicates with to create, update, retrieve, delete, and subscribe to multi-modal SEALDD flow context topics.

[0213] The topics may have unique addresses (e.g. topic names, etc.) and also one or more attributes that describe topic data and / or metadata. These flow context topics may be published to or subscribed to by VAL clients and servers as well as other SEALDD clients and servers.

[0214] Graphical User Interface. Figure 22 shows an example GUI in which a user may configure a multi-modal SEALDD flow.

[0215] Figure 23 A illustrates one example of a communications system 100 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the example communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103 / 104 / 105 / 103b / l 04b / l 05b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and V2X server (or ProSe function and server) 113, though it will be appreciated that the disclosed examples contemplate any quantity of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is depicted in Figures 23A-23E as a hand-held wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wirelesssensor, consumer electronics, a wearable apparatus such as a smart watch or smart clothing, a medical or eHealth apparatus, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane, and the like.

[0216] The communications system 100 may also include a base station 114a and a base station 114b. Base stations 114a may be any type of apparatus configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. Base stations 114b may be any type of apparatus configured to wiredly and / or wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmission and Reception Points) 119a, 119b, and / or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or V2X server (or ProSe function and server) 113. RRHs 118a, 118b may be any type of apparatus configured to wirelessly interface with at least one of the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. TRPs 119a, 119b may be any type of apparatus configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. RSUs 120a and 120b may be any type of apparatus configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any quantity of interconnected base stations and / or network elements.

[0217] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114b may be part of the RAN 103b / l 04b / l 05b, which may also include other base stations and / or network elements(not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an example, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In an example, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0218] The base stations 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0219] The base stations 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b, over a wired or air interface 115b / l 16b / l 17b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b / l 16b / l 17b may be established using any suitable radio access technology (RAT).

[0220] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b, may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c / l 16c / l 17c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c / l 16c / l 17c may be established using any suitable radio access technology (RAT).

[0221] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with one another over an air interface 115d / l 16d / l 17d (not shown in the figures), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR),ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115d / l 16d / l 17d may be established using any suitable radio access technology (RAT).

[0222] More specifically, as noted above, the communications 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, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b,TRPs 119a, 119b and RSUs 120a, 120b, in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, 102f, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 or 115c / l 16c / l 17c respectively using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High- Speed Uplink Packet Access (HSUPA).

[0223] In an example, the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b, in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 or 115c / l 16c / l 17c respectively using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. The LTE and LTE-A technology includes LTE D2D and V2X technologies and interface (such as Sidelink communications, etc.) The 3 GPP NR technology includes NR V2X technologies and interface (such as Sidelink communications, etc.)

[0224] In an example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b, in the RAN 103b / l 04b / l 05b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0225] The base station 114c in Figure 23A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In an example, the base station 114c and the WTRUs 102e, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an example, the base station 114c and the WTRUs 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another example, the base station 114c and the WTRUs 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As illustrated in Figure 23 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0226] The RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b may be in communication with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0227] Although not illustrated in Figure 23 A, it will be appreciated that the RAN 103 / 104 / 105 and / or RAN 103b / l 04b / l 05b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / l 04b / l 05b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or RAN 103b / l 04b / l 05b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0228] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computernetworks and apparatuses that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / l 04b / l 05b or a different RAT.

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

[0230] Figure 23B is a block diagram of an example apparatus or apparatus configured for wireless communications in accordance with the examples illustrated herein, such as for example, a WTRU 102. As illustrated in Figure 23B, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an example. Also, examples contemplate that the base stations 114a and 114b, and / or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in Figure 23B and described herein.

[0231] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While Figure 23B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0232] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115 / 116 / 117. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an example, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another example, the transmit / receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0233] In addition, although the transmit / receive element 122 is depicted in Figure 23B as a single element, the WTRU 102 may include any quantity of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an example, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0234] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

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

[0236] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable apparatus for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.

[0237] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115 / 116 / 117 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an example.

[0238] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration apparatus, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0239] The WTRU 102 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable apparatus such as a smart watch or smart clothing, a medical or eHealth apparatus, a robot, industrial equipment, a drone, a vehicle such as a car,truck, train, or airplane. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.

[0240] Figure 23C is a system diagram of the RAN 103 and the core network 106 according to an example. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As illustrated in Figure 23C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any quantity of Node-Bs and RNCs while remaining consistent with an example.

[0241] As illustrated in Figure 23C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.

[0242] The core network 106 illustrated in Figure 23 C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0243] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications apparatuses.

[0244] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled apparatuses.

[0245] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0246] Figure 23D is a system diagram of the RAN 104 and the core network 107 according to an example. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0247] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any quantity of eNode-Bs while remaining consistent with an example. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an example, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0248] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, and the like. As illustrated in Figure 23D, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0249] The core network 107 illustrated in Figure 23D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107,it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0250] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0251] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0252] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled apparatuses.

[0253] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications apparatuses. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0254] Figure 23E is a system diagram of the RAN 105 and the core network 109 according to an example. The RAN 105 may be an access service network (ASN) that employsIEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0255] As illustrated in Figure 23E, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any quantity of base stations and ASN gateways while remaining consistent with an example. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an example, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0256] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0257] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0258] As illustrated in Figure 23E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0259] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled apparatuses. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications apparatuses. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0260] Although not illustrated in Figure 23E, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0261] The core network entities described herein and illustrated in Figures 23 A, 23C, 23D, and 23E are identified by the names given to those entities in certain existing 3 GPPspecifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3 GPP, including future 3 GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in Figures 23 A, 23B, 23C, 23D, and 23E are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.

[0262] Figure 23F is a block diagram of an exemplary computing system 90 in which one or more apparatuses of the communications networks illustrated in Figures 23 A, 23C, 23D and 23E may be embodied, such as certain nodes or functional entities in the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 110, or Other Networks 112. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communications network. Coprocessor 81 is an optional processor, distinct from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein.

[0263] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system’s main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and foroperating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0264] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally comprise stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware apparatuses. Access to RAM 82 and / or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process’s virtual address space unless memory sharing between the processes has been set up.

[0265] In addition, computing system 90 may comprise peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0266] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT-based video display, an LCDbased flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0267] Further, computing system 90 may comprise communication circuitry, such as for example a network adapter 97, that may be used to connect computing system 90 to an external communications network, such as the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 110, or Other Networks 112 of Figures 23 A, 23B, 23C, 23D, and 23E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91, may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[0268] Figure 23G illustrates one example of a communications system 111 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the example communications system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and a RSUs A and B, though it will be appreciated that the disclosed examples contemplate any quantity of WTRUs, base stations, networks, and / or network elements. One or several or all WTRUs A, B, C, D, E may be out of range of the network (for example, in the figure out of the cell coverage boundary shown as the dash line). WTRUs A, B, C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate over Uu interface or Sidelink (PC5) interface.

[0269] It is understood that any or all of the apparatuses, systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by a processor, such as processors 118 or 91, cause the processor to perform and / or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor of an apparatus or computing system configured for wireless and / or wired network communications. Computer readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, but such computer readable storage media do not include signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage apparatuses, or any other tangible or physical medium which may be used to store the desired information and which may be accessed by a computing system.

Claims

CLAIMSWhat is claimed is:

1. A first apparatus comprising a processor, a memory, and communication circuitry, the first apparatus being connected to a network via its communication circuitry, the first apparatus further comprising computer-executable instructions stored in the memory of the first apparatus which, when executed by the processor of the first apparatus, cause the first apparatus to perform operations comprising: receiving, from a second apparatus, a multi-modal flow management request, wherein the request comprises one or more multi-modal flow policies for establishing one or more multimodal service enabler layer flows each comprising one or more individual service enabler flows; determining, based on the one or more multi-modal flow policies provided in the request, at least a first individual service enabler flow and a second individual service enabler flow; establishing a multi-modal service enabler flow associated with the first individual service enabler flow and the second individual service enabler flow; and assigning a multi-modal service enabler flow identifier to the established multi-modal service enabler flow.

2. The first apparatus of claim 1, wherein the computer-executable instructions stored in the memory of the first apparatus, when executed by the processor of the first apparatus, further cause the first apparatus to perform operations comprising: receiving at least one first message associated with the first individual service enabler flow and at least one second message associated with the second individual service enabler flow; and synchronizing, based on the one or more multi-modal flow policies provided in the request, the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow.

3. The first apparatus of claim 1, wherein the computer-executable instructions stored in the memory of the first apparatus, when executed by the processor of the first apparatus, further cause the first apparatus to perform operations comprising:performing, based on the one or more multi-modal flow policies provided in the request, one or more measurements of the at least one first message associated with the first individual service enabler flow or the at least one second message associated with the second individual service enabler flow.

4. The first apparatus of claim 3, wherein the one or more performed measurements comprise latency measurements.

5. The first apparatus of claim 3, wherein the one or more performed measurements comprise jitter measurements.

6. The first apparatus of claim 3, wherein the one or more performed measurements comprise throughput measurements.

7. The first apparatus of claim 3, wherein the computer-executable instructions stored in the memory of the first apparatus, when executed by the processor of the first apparatus, further cause the first apparatus to perform operations comprising: determining, based on the one or more performed measurements, an offset between the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow; and synchronizing, based on the offset, the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow.

8. The first apparatus of claim 7, wherein the synchronizing of the at least one first message and the at least one second message comprises at least one of buffering or delaying, based on the offset, the at least one message associated with the first individual service enabler flow or the at least one message associated with the second individual service enabler flow.

9. A method comprising:receiving a multi-modal flow management request, wherein the request comprises one or more multi-modal flow policies for establishing one or more multi-modal service enabler layer flows each comprising one or more individual service enabler flows; determining, based on the one or more multi-modal flow policies provided in the request, at least a first individual service enabler flow and a second individual service enabler flow; establishing a multi-modal service enabler flow associated with the first individual service enabler flow and the second individual service enabler flow; and assigning a multi-modal service enabler flow identifier to the established multi-modal service enabler flow.

10. The method of claim 9, further comprising: receiving at least one first message associated with the first individual service enabler flow and at least one second message associated with the second individual service enabler flow; and synchronizing, based on the one or more multi-modal flow policies provided in the request, the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow.

11. The method of claim 9, further comprising performing, based on the one or more multimodal flow policies provided in the request, one or more measurements of the at least one first message associated with the first individual service enabler flow or the at least one second message associated with the second individual service enabler flow.

12. The method of claim 11 , wherein the one or more performed measurements comprise latency measurements.

13. The method of claim 11 , wherein the one or more performed measurements comprise jitter measurements.

14. The method of claim 11 , wherein the one or more performed measurements comprise throughput measurements.

15. The method of claim 11, further comprising: determining, based on the one or more performed measurements, an offset between the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow; and synchronizing, based on the offset, the at least one first message associated with the first individual service enabler flow and the at least one second message associated with the second individual service enabler flow.

16. The method of claim 15, wherein the synchronizing of the at least one first message and the at least one second message comprises at least one of buffering or delaying, based on the offset, the at least one message associated with the first individual service enabler flow or the at least one message associated with the second individual service enabler flow.

Images