Flow alignment in a communication system

Abstract

Disclosed is a method for execution by a server node (e.g. SEALDD server). The method involves sending, to a client node (e.g. SEALDD client), flow alignment assistance information. The flow alignment assistance information can be used by the client node for flow synchronization, for example caching and / or transmission to align multi-modal flows. In accordance with an embodiment of the disclosure, the flow alignment assistance information includes at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow. This flow alignment assistance information goes beyond conventional procedure, which uses flow alignment assistance information that is limited to a timestamp in an RTP header, RTCP-based protocols. Specifically, the flow alignment assistance information of this disclosure provides a mechanism to account for network or RAN congestion to synchronize flows.

Description

[0001] SYSTEM AND METHOD FOR

[0002] FLOW ALIGNMENT IN A COMMUNICATION SYSTEM

[0003] Related Applications

[0004] [1] This patent application claims priority from PCT provisional patent application no. PCT / CN2025 / 076575 filed on February 10, 2025, which is hereby incorporated by reference in its entirety.

[0005] Field of the Disclosure

[0006] [2] This disclosure relates to communication systems, and more particularly to flow alignment in a communication system.

[0007] Background

[0008] [3] Communication systems can enable exciting new technologies such as metaverse, AR (Augmented Reality), VR (Virtual Reality), and XR (extended Reality). Flow synchronization and multi-modal flows can be important topics for such new technologies.

[0009] [4] In immersive multi-modal VR applications, precise synchronization between various media components — such as audio, visual, and haptic data — can be important to maintain a seamless user experience. According to Section 6.43 of 3GPP (3rd Generation Partnership Project) TS (Technical Standard) 22.261 entitled “Service requirements for the 5G system” version 20.1.0 dated 2025-01-10 (hereinafter “3GPP TS 22.261”), this synchronization can be very important when an acceptable delay or synchronization threshold between two or more modalities is shorter than an application's overall latency KPI (Key Performance Indicator).

[0010] [5] For example, 3GPP TS 22.261 defines typical synchronization thresholds for immersive multi-modal VR applications in section 6.43, Table 6.43.1-1 as follows:

[0011] • Audio-Tactile Synchronization: audio delay tolerance of 50 ms; tactile delay tolerance of 25 ms; and

[0012] • Visual-Tactile Synchronization: visual delay tolerance of 15 ms; tactile delay tolerance of 50 ms.These stringent synchronization thresholds highlight the importance of minimizing or mitigating delay discrepancies across different media streams to ensure a cohesive and immersive VR experience. If synchronization thresholds are not met, certain media streams may be forced to wait for others, leading to noticeable desynchronization and negatively impacting the user's immersive experience.

[0013] [6] A conventional multi-modal flow synchronization procedure is defined in clause 9.12.2.2.2 of 3GPP TS 23.433 entitled “Service Enabler Architecture Layer for Verticals (SEAL); Data Delivery enabler for vertical applications” version 19.4.0 dated 2025-01-17 (hereinafter “3GPP TS 23.433”). This conventional procedure is SEALDD (SEAL Data Delivery) enabled, which can enable secure and efficient delivery of data for vertical applications, and thereby provide a mechanism to distribute application content and data to edge devices.

[0014] [7] While this conventional procedure can perform flow synchronization, such flow synchronization is rudimentary and can have poor results during network or RAN (Radio Access Network) congestion. Also, this conventional procedure cannot provide synchronization of flows based on custom application-oriented protocols or other standardized protocols like QUIC (Quick UDP Internet Connection), WebSockets, etc.

[0015] [8] Some embodiments disclosed herein set out to solve, address, or mitigate one or more of the foregoing deficiencies with the conventional procedure.

[0016] Summary of the Disclosure

[0017] [9] According to an aspect, there is provided a method for execution by a server node (e.g. SEALDD server). The method involves sending, to a client node (e.g. SEALDD client), flow alignment assistance information. The flow alignment assistance information can be used by the client node for flow synchronization, for example caching and / or transmission to align multi-modal flows.

[0018]

[0010] In accordance with an embodiment of the disclosure, the flow alignment assistance information includes at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow. This flow alignment assistance information goes beyond conventional procedure, which uses flow alignment assistance information that is limited to a timestamp in an RTP (Real-timeTransport Protocol) header, RTCP (Real-time Transport Control Protocol) based protocols. Specifically, the flow alignment assistance information of this disclosure provides a mechanism to account for network or RAN congestion to synchronize flows.

[0019]

[0011] Therefore, embodiments of the disclosure go beyond the conventional approach which is not suitable to account for dynamic behaviour of a network and / or XR device. There can be delays introduced by the network due to various factors like poor wireless conditions, user mobility, network overload etc., which can put the flows out of synchronization. Some embodiments of the disclosure can account for those delays. This can result is better performance overall.

[0020]

[0012] Some further potential benefits provided by one or more embodiments of the disclosure include:

[0021] • enabling the SEALDD server to adjust the flow transmission timing to synchronize the flows for XR sessions, and multi-modal flows, which can ultimately mean a seamless user experience for the application (e.g. XR);

[0022] • being protocol agnostic (since it is a transmission timing-based solution) and does not depend on any header-based timestamp information to adjust the flows, and it can work with encrypted flows or proprietary protocols for XR applications;

[0023] • being adaptive to the network congestion situations, as well as to the user traffic patterns, in order to maintain the flow synchronization.

[0024]

[0013] In some implementations, the method also involves receiving analytics and / or prediction information for RAN congestion, and determining the flow alignment assistance information based on the analytics and / or prediction information. In some implementations, the determining of the flow alignment assistance information is also based on a synchronization threshold and / or a multi-modal flow alignment policy. In some implementations, the method also involves requesting the analytics and / or prediction information ahead of time (e.g. upon XR session being established). Other implementations are possible.

[0025]

[0014] In some implementations, the method also involves, upon receiving upload packets in a multi-modal flow, sending the packets to another server (e.g. VAL server). In some implementations, the method also involves, upon a packet delay measurement being above the defined threshold, executing at least one correctiveaction step. In some implementations, the at least one corrective action step includes adjusting a delay for transmission. In some implementations, the at least one corrective action step includes buffering for transmission. In some implementations, the at least one corrective action step includes updating the flow alignment assistance information. Other implementations are possible.

[0026]

[0015] In some implementations, the flow alignment assistance information is sent via a transmission quality management request. In other implementations, the flow alignment assistance information is sent via an XR flow synchronization request. Other implementations are possible.

[0027]

[0016] According to another aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a server node (e.g. SEALDD server), configure the server node to implement a method as summarized above.

[0028]

[0017] According to another aspect, there is provided a server node (e.g. SEALDD server). The server node includes a network interface configured to communicate with other network nodes, and control circuitry coupled to the network interface. The control circuitry is configured to send, to a client node (e.g. SEALDD client), flow alignment assistance information. The flow alignment assistance information can be used by the client node for flow synchronization, for example caching and / or transmission to align multi-modal flows.

[0029]

[0018] In accordance with an embodiment of the disclosure, the flow alignment assistance information includes at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow. This flow alignment assistance information goes beyond conventional procedure as described above, and can provide for various benefits over the conventional procedure as also described above.

[0030]

[0019] In some implementations, the control circuitry is also configured to implement a method as summarized above.

[0031]

[0020] According to another aspect, there is provided a method for execution by client node (e.g. SEALDD client). The method involves receiving, from a server node(e.g. SEALDD server), flow alignment assistance information. The method also involves performing caching and / or transmission to align multi-modal flows based on the flow alignment assistance information.

[0032]

[0021] In accordance with an embodiment of the disclosure, the flow alignment assistance information includes at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow. This flow alignment assistance information goes beyond conventional procedure as described above, and can provide for various benefits over the conventional procedure as also described above.

[0033]

[0022] In some implementations, the flow alignment assistance information includes the transmission timing advance period, and the performing of the caching and / or transmission includes advancing an upload packet transmission by the transmission timing advance period.

[0034]

[0023] In some implementations, the flow alignment assistance information includes the transmission timing delay period, and the performing of the caching and / or transmission includes delaying an upload packet transmission by transmission timing delay period.

[0035]

[0024] In some implementations, the flow alignment assistance information includes the associated flow IDs in multi-modal flow for use in identifying flows.

[0036]

[0025] In some implementations, the method also involves receiving updated flow alignment assistance information, and adjusting the caching and / or transmission based on the updated flow alignment assistance information.

[0037]

[0026] In some implementations, the flow alignment assistance information is received via a transmission quality management request. In other implementations, the flow alignment assistance information is received via an XR flow synchronization request.

[0038]

[0027] According to another aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that,when executed by a processor of a client node (e.g. SEALDD client), configure the client node to implement a method as summarized above.

[0039]

[0028] According to another aspect, there is provided a client node (e.g. SEALDD client). The client node has a network interface configured to communicate with other network nodes, and control circuitry coupled to the network interface. The control circuitry is configured to receive, from a server node (e.g. SEALDD server), flow alignment assistance information. The control circuitry is also configured perform caching and / or transmission to align multi-modal flows based on the flow alignment assistance information.

[0040]

[0029] In accordance with an embodiment of the disclosure, the flow alignment assistance information includes at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow. This flow alignment assistance information goes beyond conventional procedure as described above, and can provide for various benefits over the conventional procedure as also described above.

[0041]

[0030] In some implementations, the control circuitry is also configured to implement a method as summarized above.

[0042]

[0031] Other aspects and features of the present disclosure will become apparent, to those ordinarily skilled in the art, upon review of the following description of the various embodiments of the disclosure.

[0043] Brief Description of the Drawings

[0044]

[0032] Embodiments will now be described with reference to the attached drawings in which:

[0045] Figure 1 is a block diagram of a communication system, in accordance with an embodiment of the disclosure;

[0046] Figure 2 is a sequence drawing of a method of aligning multi-modal flows; Figure 3 is a schematic of an example cellular communications system in which some embodiments of the present disclosure may be implemented;Figures 4A and 4B are block diagrams of a wireless communication system represented as a 5G network architecture in which some embodiments of the present disclosure may be implemented;

[0047] Figures 5 and 7 are block diagrams of a radio access node according to some embodiments of the present disclosure;

[0048] Figure 6 is a block diagram that illustrates a virtualized embodiment of a radio access node according to some embodiments of the present disclosure; and Figures 8 and 9 are block diagrams of a wireless communication device;

[0049] Detailed Description of Embodiments

[0050]

[0033] It should be understood at the outset that although illustrative implementations of one or more embodiments of the present disclosure are provided below, the disclosed systems and / or methods may be implemented using any number of techniques. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended embodiment along with their full scope of equivalents.

[0051] Introduction

[0052]

[0034] Referring first to Figure 1, shown is a block diagram of a communication system 100, in accordance with an embodiment of the disclosure. The communication system 100 has a client node 110 (e.g. SEALDD client) and a server node 120 (e.g. SEALDD server) operatively coupled to one another via one or more networks 102. In some implementations, these nodes 110 and 120 are SEALDD enabled, meaning they can enable secure and efficient delivery of data for vertical applications, thereby providing a mechanism to distribute application content and data between a VAL client 110a and a VAL server 120a. The one or more networks 102 can include a wireless system (not shown) over which the SEALDD client 110 and the SEALDD server 120 can communication. Example details of a wireless system and communication over the same are provided later with reference to Figures 3 to 9. The communication system 100 may have other components that are not shown for simplicity. For example, the communication system 100 may include components of acore network and components of a radio access network. Example details of a core network and a radio access network are provided later.

[0053]

[0035] The client node 110 has a network interface 115 configured to communicate with other nodes of the communication system 100, a CRM 119, and control circuitry 116 coupled to the network interface 115 and the CRM 119. In some implementations, the control circuitry 116 includes a processor 117 that executes software, which can stem from a memory 118. However, other implementations are possible and are within the scope of this disclosure. The client node 110 can have additional components, but these are not shown for simplicity. Although the client node 110 and the client 110a are shown separately, for SEALDD implementations it is common for both the SEALDD client 110 and the VAL client 110a to be implemented by the same client node 110 (e.g. a UE). However, other implementations are possible in which the SEALDD client 110 and the VAL client 110a are separate components as shown.

[0054]

[0036] The server node 120 has a network interface 125 configured to communicate with other nodes of the communication system 100, a CRM 129, and control circuitry 126 coupled to the network interface 125 and the CRM 129. In some implementations, the control circuitry 126 includes a processor 127 that executes software, which can stem from a memory 128. However, other implementations are possible and are within the scope of this disclosure. The server node 120 can have additional components, but these are not shown for simplicity. The server node 120 and the server 120a are shown separately, and for SEALDD implementations it is common for both the SEALDD server 120 and the VAL server 120a to be separate. However, other implementations are possible in which both the SEALDD server 120 and the VAL server 120a are implemented by the same server node 120.

[0055]

[0037] The control circuitry 116 of the client node 110 and the control circuitry 126 of the server node 120 operate to implement a method of aligning multimodal flows. The method involves the server node 120 sending, to the client node 110, flow alignment assistance information. The flow alignment assistance information can be used by the client node 110 for flow synchronization, for example caching and / or transmission to align multi-modal flows.

[0038] In accordance with an embodiment of the disclosure, the flow alignment assistance information includes at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow. This flow alignment assistance information goes beyond conventional procedure, which uses flow alignment assistance information that is limited to a timestamp in an RTP header, RTCP-based protocols. Specifically, the flow alignment assistance information of this disclosure provides a mechanism to account for network or RAN congestion to synchronize flows.

[0056]

[0039] Therefore, embodiments of the disclosure go beyond the conventional approach which is not suitable to account for dynamic behaviour of a network and / or XR device. There can be delays introduced by the network due to various factors like poor wireless conditions, user mobility, network overload etc., which can put the flows out of synchronization. Some embodiments of the disclosure can account for those delays. This can result is better performance overall.

[0057]

[0040] Some further potential benefits provided by one or more embodiments of the disclosure include:

[0058] • enabling the SEALDD server to adjust the flow transmission timing to synchronize the flows for XR sessions, and multi-modal flows, which can ultimately mean a seamless user experience for the application (e.g. XR);

[0059] • being protocol agnostic (since it is a transmission timing-based solution) and does not depend on any header-based timestamp information to adjust the flows, and it can work with encrypted flows or proprietary protocols for XR applications;

[0060] • being adaptive to the network congestion situations, as well as to the user traffic patterns, in order to maintain the flow synchronization.

[0061]

[0041] Further example operation by the client node 110 and the server node 120 will be described below with reference to Figure 2. Although the method of Figure 2 is described below with reference to the communication system 100 shown in Figure 1 , it is to be understood that the method of Figure 2 is applicable to other communication systems. In general, the method of Figure 2 is applicable to any appropriately configured communication system.

[0042] Referring now to Figure 2, shown is a sequence drawing of a procedure for multi-modal flow synchronization. Various signalling and actions are shown for the VAL client 110a, the SEALDD client 110, a 5GC, the SEALDD server 120, and the VAL server 120a. Thus, the example is provided for SEALDD. However, it is to be understood that the procedure is very specific for exemplary purposes only. And other embodiments are possible, including implementations without SEALDD.

[0062]

[0043] By way of overview, the SEALDD server 120 determ ines / updates the QoS (Quality of Service) information for multi-modal flow(s), and further interacts with 5G network. There are several pre-conditions:

[0063] • The VAL server 110a can discover and select the SEALDD server 120 by CAPIF (Common API Framework) functions.

[0064] • The SEALDD server 120 has been provisioned with a multi-modal XR policy including the synchronization threshold, for example as specified in clause 9.10.3.1 of 3GPP TS 23.433.

[0065] • The SEALDD client 110 has been provisioned with a multi-modal SEALDD policy, for example as specified in clause 9.10.2.3 of 3GPP TS 23.433.

[0066]

[0044] At step 201, an on-going multi-modal data transmission connection is established, for example according to the steps 1-8 of clause 9.12.2.1.2 of 3GPP TS 23.433.

[0067]

[0045] At step 202, upon the multi-modal flows alignment policy triggered, the SEALDD server 120 may help to provide the flows alignment assistance information to the SEALDD client 110. In accordance with an embodiment of the disclosure, the flow alignment assistance information includes at least one of UL / DL (Uplink / Downlink) transmission timing advance period, UL / DL transmission timing delay period and the associated flow IDs in the multi-modal flows. The flow alignment assistance information may also contain a timestamp in the RTP header, RTCP. In some implementations, the flow alignment assistance information is sent in a Transmission quality management request as specified for example in clause 9.9.3.1 of 3GPP TS 23.433.

[0068]

[0046] If the maximum acceptable duration for traffic flow alignment is not provided, then the SEALDD server 120 may determine the maximum acceptable duration for traffic flow alignment based on VAL service ID, flows transmission,transmission quality, and the synchronization threshold. The server may translate the traffic descriptor into multi-modal SEALDD flow ID.

[0069]

[0047] In some implementations, the SEALDD server 120 communicates with the wireless system (e.g. 5GS, 6GS, etc.) to get analytics and prediction for RAN congestion, for example as per clause 6.6, clause 6.7, clause 6.8 3GPP TS 23.288. Based on the RAN congestion analytics and prediction information, synchronization threshold and / or multi-modal flow alignment policy, the SEALDD server 120 adjusts the flow alignment assistance information like DL / UL transmission timing advance or delay period.

[0070]

[0048] In some implementations, flow alignment assistance information can be obtained by the SEALDD server 120 based on SEALDD policy.

[0071]

[0049] In some implementations, the SEALDD client 110 performs the caching and transmission to align multi-modal flows based on the flow alignment assistance information and maximum acceptable time duration.

[0072]

[0050] Whether and how to make use of existing CN functionality (e.g. PDU set related feature) can be defined.

[0073]

[0051] In some implementations, NTP timestamp and RTP timestamp in RTCP sender report (SR) can be used to identify the associated packets among muti-modal flow, and further be used to perform alignment in the SEALDD client 110.

[0074]

[0052] In some implementations, the option to rely on UE congestion analytics and RAN congestion analytics, as exposed by the 5GC via NWDAF, has a margin of error as with any predictions. In some implementations, to handle real-time / near realtime constraint of these prediction, these UE congestion analytics can be requested ahead of time from the 5GC / NWDAF, e.g., once the XR session is started by the UE.

[0075]

[0053] At step 203, upon the multi-modal flows alignment policy triggered, the SEALDD client 110 initiates the multi-modal flows alignment based on the policy. The flows to be aligned are identified by the VAL service ID, multi-modal SEALDD flow ID, and flow alignment assistance information.

[0054] In some implementations, when the flow alignment assistance information is provided, the SEALDD client 110 can identify the associated packets (e.g., those with the same RTP timestamp) in the multi-modal flows. In some implementations, after all associated packets in the multi-modal flows have arrived, the SEALDD client 110 sends the associated packets to the application client. In some implementations, if the maximum acceptable time duration is provided, once this maximum acceptable time is reached, the SEALDD client 110 will no longer wait for the associated packets in multimodal flows, even if they have not arrived yet.

[0076]

[0055] In some implementations, for the UL synchronization, the SEALDD client 110 sends the UL packets as per the flow alignment assistance information. In some implementations, the UL transmission timing advance period indicates SEALDD client 110 to advance the UL packet transmission by advance period. In some implementations, the UL transmission timing delay period correction mode indicates SEALDD client 110 to delay the transmission of the UL packet by UL delay period units. In some implementations, after all associated packets in the multi-modal flow have arrived at the SEALDD server 120, then the SEALDD server 120 sends the associated UL packets to the VAL server 110a.

[0077]

[0056] At step 204, the SEALDD server 120 performs data transmission quality measurement, for example as defined in clause 9.7.2.1 or clause 9.7.2.3 of 3GPP TS 23.433, in SEALDD-UU interface based on the mapping information for multiple flow association information between SEALDD-S interface and SEALDD-UU interface. Upon receiving the packets from multiple associated flows in SEALDD-S interface, the SEALDD server 120 performs the packet encapsulation with sending timestamp information in the corresponding SEALDD-UU interface, and can calculate the transmission delay measurement result of multiple associated flows after obtaining the receiving timestamp from the SEALDD client 110.

[0078]

[0057] At step 205, based on the data transmission quality measurement results obtained for multiple associated flow over SEALDD-UU interface in step 204, and the synchronization threshold for multi-modal application as described in pre-condition, the SEALDD server 120 can determine the service flow(s) (i.e. address / port for SEALDD-UU flow) that needs to be adjusted among the multiple associated flows in SEALDD-UU interface, and the corresponding QoS information (i.e. transmission delay).

[0058] In some implementations, the SEALDD-S evaluates whether the difference of the packet delay measurements for the flows that need to be in synchrony is above the synchronization threshold, and if it is so, the SEALDD server 120 takes the corresponding corrective actions, e.g. adjusting the delay of transmission and / or buffering the transmission. In some implementations the SEALDD server 120 can advance or delay the transmission of the DL packets according to the flow assistance information to maintain the synchronization of DL flows. In some implementations, the DL transmission timing advance period correction mode indicates SEALDD server 120 to advance the DL packet transmission by advance period. In some implementations, the DL transmission timing delay period correction mode indicates SEALDD server 120 to delay the transmission of the DL packet by DL delay period units.

[0079]

[0059] In some implementations, the SEALDD server 120 further updates the flow alignment assistance information like DL / UL transmission timing advance or delay period to fine-tune as per the data transmission quality measurement results. Thus, updated flow alignment assistance information is produced. In some implementations, the SEALDD server 120 sends the updated flow alignment assistance information to the client node.

[0080]

[0060] At step 206, the SEALDD server 120 sends the AF request to 5GC via N33 / N5 with the SEALDD traffic descriptor of the adjusted flow(s) (i.e. address / port for the adjusted SEALDD-UU flow) and the corresponding QoS information determined in step 205, for example by utilizing the AF session with the QoS procedure defined in clause 4.15.6.6 of 3GPP TS 23.502 [6], In some implementations, the SEALDD traffic descriptor of the adjusted flow(s) contains the address or port in SEALDD server side, and / or SEALDD client side.

[0081]

[0061] Note that this procedure can be applicable for both downlink and uplink synchronization of multi-modal flow. For downlink and / or uplink, the step 205 can be determined according to the measured downlink and / or uplink data transmission quality measurements in step 204. For uplink synchronization, the SEALDD server 120 performs the caching and transmission to align multi-modal flows based on the flow alignment assistance information before sending the associated packets to the VAL server 110a.

[0062] In some implementations, after requesting the transmission quality optimization on 5G network with the QoS for the adjusted flow(s), the multi-flow synchronization of multi-modal application can be satisfied.

[0082]

[0063] Whether and how the multi-modal flows alignment monitoring can be defined.

[0083]

[0064] In the procedure described above with reference to Figure 2, the SEALDD server 120 sends flow assistance information to the SEALDD client 110 by using a transmission quality management request, for example as defined in clause 9.9.3.1 of 3GPP TS 23.433, to send the flow assistance information to the SEALDD client 110. However, it is to be understood that there are other ways for the SEALDD server 120 to convey the flow assistance information to the SEALDD client 110. For example, in another implementation, the SEALDD server 120 can also send a separate XR flow synchronization request including flow alignment information like the UL / DL transmission timing advance period, the UL / DL transmission timing delay period, and the associated flow IDs directly to the SEALDD client 110. Other implementations are possible. More generally, the SEALDD server 120 can convey the flow assistance information to the SEALDD client 110 in any appropriate manner.

[0084]

[0065] Some embodiments enable the SEALDD server 120 or the SEALDD client 110 to send a packet in advance or early in time with X advance period, or delay transmission of packets with Y delay period according to the flow alignment correction modes, to maintain synchronization for UL / DL flows.

[0085]

[0066] The SEALDD server 120 also accounts for the delays introduced by the network to adjust the flow alignment assistance information like UL / DL transmission timing advance and / or delay period. The SEALDD server 120 fetches the UE congestion analytics and RAN congestion analytics and predictions from NWDAF services to derive the network-introduced delay and QoS, like bitrate, for the flows. While this mechanism applies to any type of applications handling multiple media flows, in this proposal we are using the XR applications as an example.

[0086]

[0067] The SEALDD server 120 can proactively subscribe to the congestion analytics as soon as the XR session is started by the UE to be able to support the real-time or near-real-time XR sessions. The analytics predictions help the SEALDD server 120 to anticipate and timely adapt, based on the received analytics predictions, to events that are highly likely to occur during the XR session, minimizing or eliminating any negative impact to the user experience.

[0087]

[0068] Each XR session or application is subjective to its synchronization threshold, available via policy or configured in the SEALDD server 120 and client. Considering the network delay, predictive analytics, packet delay measurements and synchronization threshold the SEALDD server 120 calculates the timing information for the flow alignment assistance information like UL / DL transmission timing advance and / or delay period. Further, for tight synchronization, the SEALDD server 120 takes the corresponding corrective actions, e.g. adjusting the delay for transmission, or QoS for transmission and / or applying a suitable buffering for the transmission. In some implementations, one or more corrective actions are invoked via the wireless system (e.g. 5GS, 6GS, etc.).

[0088]

[0069] The SEALDD server 120 has also subscribed for the transmission quality measurement reports to further fine-tune the flow alignment assistance information like UL / DL transmission timing advance and / or delay period.

[0089]

[0070] Some embodiments introduce RAN congestion and predictions based timing adjustments to support the synchronization of the flows. Otherwise, a SEALDD server and client could not preform flow alignment, and this may lead to drop of packets due to RAN congestion and non-synchronization of flows.

[0090]

[0071] The proposed solution describes flow alignment assistance information, including UL / DL transmission timing advance period, UL / DL transmission timing delay period and the associated flow IDs in the multi-modal flows. This goes beyond previous approaches in which flow alignment assistance information is limited to a timestamp in an RTP header, RTCP-based protocols.

[0091]

[0072] The solution can be implemented in SW deployed in the cloud or not.

[0092]

[0073] Conventional flow synchronization is based on an RTP timestamp synchronization mechanism. In the existing procedure, the packets wait until all the flows arrive and discard all the packets arriving after the acceptable delay orsynchronization threshold. It performs synchronization based on the matching same timestamp. Generally, it may work fine but since XR devices communicate over RAN, RAN may induce delays due to dynamic wireless channel like poor channel, user mobility, etc. and put the flows out of synchronization.

[0093]

[0074] Timestamp matching-based synchronization may not reflect the delays because of the same timestamp in packets. If the delay is greater than the synchronization threshold, then the timestamp matching is not useful. It is also because the current procedure does not account for the RAN congestion or predict the RAN congestion to maintain synchronization. If the SEALDD server has information about the congestion, then it can do something like the adjustment of flows to maintain synchronization accordingly to counter the delays of RAN congestion. Also, the procedure mentions adjusting the QoS to do the synchronization and this will not work because the RAN is already congested and it will not be able to guarantee the QoS.

[0094]

[0075] The procedure configures defined QoS to synchronize the flows (via AF session with QoS procedure) and this may not work because of higher latency involved (extra signaling) to manage the QoS as compared to the synchronization threshold to maintain user experience. There could be some initial glitch or synchronization delay due to separate signaling latency until the defined QoS is configured or AF session QoS procedure is completed.

[0095]

[0076] Therefore, the proposed solution provides timing adjustments like sending packets in advance or delaying the packets relative to each other based on RAN congestion delay and predictions to support the existing synchronization in the procedure. It can help to bring tight synchronization by balancing the RAN congestion delays and delivering the packets within the synchronization threshold. It helps to reduce the wait time for the SEALDD layer (client or server) to receive all the packets. This can also improve the user experience.

[0096]

[0077] According to another embodiment of the disclosure, there is provided a non-transitory CRM having recorded thereon statements and instructions that, when executed by the processor 117 of the network node 110, implement a method as described herein. The non-transitory computer readable medium can be thememory 118 and / or the CRM 119 of the network node 110 shown in Figure 1 , or some other non-transitory CRM.

[0097]

[0078] According to another embodiment of the disclosure, there is provided a non-transitory CRM having recorded thereon statements and instructions that, when executed by the processor 127 of the network node 120, implement a method as described herein. The non-transitory computer readable medium can be the memory 128 and / or the CRM 129 of the network node 120 shown in Figure 1 , or some other non-transitory CRM.

[0098]

[0079] Examples of a non-transitory CRM include memory, an SSD (Solid State Drive), a hard disk drive, a CD (Compact Disc), a DVD (Digital Video Disc), a BD (Blu-ray Disc), a memory stick, etc. Other non-transitory CRMs are also possible.

[0099]

[0080] The illustrated examples described herein focus on software implementations. However, other implementations are possible and are within the scope of this disclosure. Other implementations can include additional or alternative hardware components, such as any appropriately configured FPGA (Field-Programmable Gate Array), ASIC (Application-Specific Integrated Circuit), and / or microcontroller, for example. Thus, the control circuitry 116 of the network node 110 and the control circuitry 126 of the network node 120 can instead be implemented with any suitable combination of hardware, software and / or firmware.

[0100]

[0081] Further example details of a wireless system and communication over the same are provided in the following section with reference to Figures 3 to 9. It is to be understood that the following section is very specific and is provided merely for exemplary purposes, such that other implementations are possible and within the scope of the disclosure.

[0101]

[0102]

[0082] Figure 3 illustrates one example of a cellular communications system 500 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 500 is a 5GS (5G system) including a NG-RAN (Next Generation RAN) and a 5GC (5G Core), although a 6GS (6G system) with corresponding components is also possible. In this example, theRAN includes base stations 502-1 and 502-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 504-1 and 504-2. The base stations 502-1 and 502-2 are generally referred to herein collectively as base stations 502 and individually as base station 502. Likewise, the (macro) cells 504-1 and 504-2 are generally referred to herein collectively as (macro) cells 504 and individually as (macro) cell 504. The RAN may also include a number of low power nodes 506-1 through 506-4 controlling corresponding small cells 508-1 through 508-4. The low power nodes 506-1 through 506-4 can be small base stations (such as pico or femto base stations) or RRHs (Remote Radio Heads), or the like. Notably, while not illustrated, one or more of the small cells 508-1 through 508-4 may alternatively be provided by the base stations 502. The low power nodes 506-1 through 506-4 are generally referred to herein collectively as low power nodes 506 and individually as low power node 506. Likewise, the small cells 508-1 through 508-4 are generally referred to herein collectively as small cells 508 and individually as small cell 508. The cellular communications system 500 also includes a core network 510, which in the 5G System is referred to as the 5GC (5G Core). The base stations 502 (and optionally the low power nodes 506) are connected to the core network 510.

[0103]

[0083] The base stations 502 and the low power nodes 506 provide service to wireless communication devices 512-1 through 512-5 in the corresponding cells 504 and 508. The wireless communication devices 512-1 through 512-5 are generally referred to herein collectively as wireless communication devices 512 and individually as wireless communication device 512. In the following description, the wireless communication devices 512 are oftentimes UEs, but the present disclosure is not limited thereto.

[0104]

[0084] Referring now to Figure 4A, shown is a block diagram of a wireless communication system represented as a 5G network architecture composed of core NFs (Network Functions), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 4A can be viewed as one particular implementation of the system 500 of Figure 3.

[0105]

[0085] Seen from the access side the 5G network architecture shown in Figure 4A includes a plurality of UEs 613 connected to either a RAN 607 or an (AccessNetwork) as well as an AMF 600. Typically, the R(AN) 607 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 4A include a NSSF 602, an ALISF 604, a UDM 606, the AMF 600, a SMF 608, a PCF 610, and an AF (Application Function) 612.

[0106]

[0086] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 613 and AMF 600. The reference points for connecting between the AN 607 and AMF 600 and between the AN 607 and UPF 614 are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF 600 and SMF 608, which implies that the SMF 608 is at least partly controlled by the AMF 600. N4 is used by the SMF 608 and UPF 614 so that the UPF 614 can be set using the control signal generated by the SMF 608, and the UPF 614 can report its state to the SMF 608. N9 is the reference point for the connection between different UPFs 614, and N14 is the reference point connecting between different AMFs 600, respectively. N15 and N7 are defined since the PCF 610 applies policy to the AMF 600 and SMF 608, respectively. N12 is utilized for the AMF 600 to perform authentication of the UE 613. N8 and N10 are defined because the subscription data of the UE 613 is utilized for the AMF 600 and SMF 608.

[0107]

[0087] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 4A, the UPF 614 is in the UP and all other NFs, i.e., the AMF 600, SMF 608, PCF 610, AF 612, NSSF 602, AUSF 604, and UDM 606, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the RTT (Round Trip Time) between UEs and data network for some applications involving low latency.

[0108]

[0088] The core 5G network architecture is composed of modularized functions. For example, the AMF 600 and SMF 608 are independent functions in the CP. Separated AMF 600 and SMF 608 allow independent evolution and scaling. Other CP functions like the PCF 610 and AUSF 604 can be separated as shown in Figure 4A. Modularized function design enables the 5GC network to support various services flexibly.

[0089] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0109]

[0090] Referring now to Figure 4B, shown is a block diagram of a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 4A. However, the NFs described above with reference to Figure 4B correspond to the NFs shown in Figure 4A. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 4B, the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 600 and Nsmf for the service based interface of the SMF 608, etc. The NEF 603 and the NRF 601 in Figure 4B are not shown in Figure 4A discussed above. However, it should be clarified that all NFs depicted in Figure 4A can interact with the NEF 603 and the NRF 601 of Figure 4B as necessary, though not explicitly indicated in Figure 4A.

[0110]

[0091] Some properties of the NFs shown in Figures 4A and 4B may be described in the following manner. The AMF 600 provides UE-based authentication, authorization, mobility management, etc. A UE 613 even using multiple access technologies is basically connected to a single AMF 600 because the AMF 600 is independent of the access technologies. The SMF 608 is responsible for session management and allocates IP (Internet Protocol) addresses to UEs. It also selects and controls the UPF 614 for data transfer. If a UE 613 has multiple sessions, different SMFs 608 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 612 provides information on the packet flow to the PCF 610 responsible for policy control in order to support QoS. Based on the information, the PCF 610 determines policies about mobility and session management to make the AMF 600 and SMF 608 operate properly. The AUSF 604 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 606 stores subscription data of theUE 613. The DN (Data Network), not part of the 5GC network, provides Internet access or operator services and similar.

[0111]

[0092] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0112]

[0093] Figure 5 is a schematic block diagram of a radio access node 700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The radio access node 700 may be, for example, a base station 502 or 506 or a network node that implements all or part of the functionality of the base station 502 or gNB described herein. As illustrated, the radio access node 700 includes a control system 702 that includes one or more processors 704 (e.g., CPUs (Central Processing Units), ASICs (Application Specific Integrated Circuits), FPGAs (Field Programmable Gate Arrays), and / or the like), memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. In addition, the radio access node 700 may include one or more radio units 710 that each includes one or more transmitters 712 and one or more receivers 714 coupled to one or more antennas 716. The radio units 710 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 710 is external to the control system 702 and connected to the control system 702 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 710 and potentially the antenna(s) 716 are integrated together with the control system 702. The one or more processors 704 operate to provide one or more functions of a radio access node 700 as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 706 and executed by the one or more processors 704.

[0113]

[0094] Figure 6 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 700 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.

[0095] As used herein, a “virtualized” radio access node is an implementation of the radio access node 700 in which at least a portion of the functionality of the radio access node 700 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node 700 may include the control system 702 and / or the one or more radio units 710, as described above. The control system 702 may be connected to the radio unit(s) 710 via, for example, an optical cable or the like. The radio access node 700 includes one or more processing nodes 800 coupled to or included as part of a network(s) 802. If present, the control system 702 or the radio unit(s) 710 are connected to the processing node(s) 800 via the network 802. Each processing node 800 includes one or more processors 804 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 806, and a network interface 808.

[0114]

[0096] In this example, functions 810 of the radio access node 700 described herein are implemented at the one or more processing nodes 800 or distributed across the one or more processing nodes 800 and the control system 702 and / or the radio unit(s) 810 in any desired manner. In some particular embodiments, some or all of the functions 810 of the radio access node 700 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 800. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 800 and the control system 702 is used in order to carry out at least some of the desired functions 810. Notably, in some embodiments, the control system 702 may not be included, in which case the radio unit(s) 810 communicates directly with the processing node(s) 800 via an appropriate network interface(s).

[0115]

[0097] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node 700 or a node (e.g., a processing node 800) implementing one or more of the functions 810 of the radio access node 700 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radiosignal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0116]

[0098] Figure 7 is a schematic block diagram of the radio access node 700 according to some other embodiments of the present disclosure. The radio access node 700 includes one or more modules 800, each of which is implemented in software. The module(s) 800 provide the functionality of the radio access node 700 described herein. This discussion is equally applicable to the processing node 800 of Figure 6 where the modules 800 may be implemented at one of the processing nodes 800 or distributed across multiple processing nodes 800 and / or distributed across the processing node(s) 800 and the control system 702.

[0117]

[0099] Figure 8 is a schematic block diagram of a wireless communication device 900 according to some embodiments of the present disclosure. As illustrated, the wireless communication device 900 includes one or more processors 902 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 904, and one or more transceivers 906 each including one or more transmitters 908 and one or more receivers 910 coupled to one or more antennas 912. The transceiver(s) 906 includes radio-front end circuitry connected to the antenna(s) 912 that is configured to condition signals communicated between the antenna(s) 912 and the processor(s) 902, as will be appreciated by on of ordinary skill in the art. The processors 902 are also referred to herein as processing circuitry. The transceivers 906 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 900 described above may be fully or partially implemented in software that is, e.g., stored in the memory 904 and executed by the processor(s) 902. Note that the wireless communication device 900 may include additional components not illustrated in Figure s such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the wireless communication device 900 and / or allowing output of information from the wireless communication device 900), a power supply (e.g., a battery and associated power circuitry), etc.

[0118]

[0100] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carryout the functionality of the wireless communication device 900 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0119]

[0101] Figure 9 is a schematic block diagram of the wireless communication device 900 according to some other embodiments of the present disclosure. The wireless communication device 900 includes one or more modules 1000, each of which is implemented in software. The module(s) 1000 provide the functionality of the wireless communication device 900 described herein.

[0120]

[0102] Each station 1106A, 1106B, 1106C is connectable to the core network 1104 over a wired or wireless connection 1110. A first UE 1112 located in coverage area 1108C is configured to wirelessly connect to, or be paged by, the corresponding base station 1106C. A second UE 1114 in coverage area 1108A is wirelessly connectable to the corresponding base station 1106A. While a plurality of UEs 1112, 1114 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1106.

[0121]

[0103] The telecommunication network 1100 is itself connected to a host computer 1116, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer 1116 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 1118 and 1120 between the telecommunication network 1100 and the host computer 1116 may extend directly from the core network 1104 to the host computer 1116 or may go via an optional intermediate network 1122. The intermediate network 1122 may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network 1122, if any, may be a backbone network or the Internet; in particular, the intermediate network 1122 may comprise two or more sub-networks (not shown).

[0104] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include DSPs (Digital Signal Processor), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as ROM (Read Only Memory), RAM (Random Access Memory), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0122]

[0105] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0123]

[0106] Numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the disclosure may be practised otherwise than as specifically described herein.

Claims

Claims:

1. A method for execution by a server node, comprising:sending, to a client node, flow alignment assistance information including at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow.

2. The method of claim 1 , wherein the flow alignment assistance information includes the transmission timing advance period.

3. The method of claim 1 or claim 2, wherein the flow alignment assistance information includes the transmission timing delay period.

4. The method of any one of claims 1 to 3, wherein the flow alignment assistance information includes the associated flow IDs in multi-modal flow.

5. The method of any one of claims 1 to 4, further comprising:receiving analytics and / or prediction information for RAN (Radio Access Network) congestion; anddetermining the flow alignment assistance information based on the analytics and / or prediction information.

6. The method of claim 5, wherein the determining of the flow alignment assistance information is also based on a synchronization threshold and / or a multimodal flow alignment policy.

7. The method of claim 5, further comprising:requesting the analytics and / or prediction information ahead of time.

8. The method of any one of claims 1 to 7, further comprising:upon receiving upload packets in a multi-modal flow, sending the packets to another server.

9. The method of any one of claims 1 to 8, further comprising:upon a packet delay measurement being above the defined threshold, executing at least one corrective action step.

10. The method of claim 9, wherein the at least one corrective action step comprises adjusting a delay for transmission.

11. The method of claim 9 or claim 10, wherein the at least one corrective action step comprises buffering for transmission.

12. The method of claim 9 or claim 10, wherein the at least one corrective action step comprises updating the flow alignment assistance information.

13. The method of any one of claims 1 to 12, wherein the flow alignment assistance information is sent via a transmission quality management request.

14. The method of any one of claims 1 to 12, wherein the flow alignment assistance information is sent via an XR (extended Reality) flow synchronization request.

15. The method of any one of claims 1 to 14, wherein the server node comprises a SEALDD (Service Enabler Architecture Layer Data Delivery) server, and the client node comprises a SEALDD client.

16. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a server node, configure the server node to implement a method according to any one of claims 1 to 15.

17. A server node, comprising:a network interface configured to communicate with other network nodes;control circuitry coupled to the network interface and configured to:send, to a client node, flow alignment assistance information including at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow.

18. The server node of claim 17, wherein the control circuitry is further configured to implement a method according to any one of claims 2 to 15.

19. A method for execution by client node, comprising:receiving, from a server node, flow alignment assistance information including at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow; andperforming caching and / or transmission to align multi-modal flows based on the flow alignment assistance information.

20. The method of claim 19, wherein the flow alignment assistance information includes the transmission timing advance period, and the performing of the caching and / or transmission comprises advancing an upload packet transmission by the transmission timing advance period.

21. The method of claim 19 or claim 20, wherein the flow alignment assistance information includes the transmission timing delay period, and the performing of the caching and / or transmission comprises delaying an upload packet transmission by transmission timing delay period.

22. The method of any one of claims 19 to 21, wherein the flow alignment assistance information includes the associated flow IDs in multi-modal flow for use in identifying flows.

23. The method of any one of claims 19 to 22, further comprising:receiving updated flow alignment assistance information; and adjusting the caching and / or transmission based on the updated flow alignment assistance information.

24. The method of any one of claims 19 to 23, wherein the flow alignment assistance information is received via a transmission quality management request.

25. The method of any one of claims 19 to 23, wherein the flow alignment assistance information is received via an XR (extended Reality) flow synchronization request.

26. The method of any one of claims 19 to 25, wherein the server node comprises a SEALDD (Service Enabler Architecture Layer Data Delivery) server, and the client node comprises a SEALDD client.

27. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a client node, configure the client node to implement a method according to any one of claims 19 to 26.

28. A client node, comprising:a network interface configured to communicate with other network nodes;control circuitry coupled to the network interface and configured to:receive, from a server node, flow alignment assistance information including at least one of a transmission timing advance period, a transmission timing delay period, and associated flow IDs in multi-modal flow; andperform caching and / or transmission to align multi-modal flows based on the flow alignment assistance information.

29. The client node of claim 28, wherein the control circuitry is further configured to implement a method according to any one of claims 20 to 26.

Images