Devices and methods of communication

Abstract

Embodiments of the present disclosure relate to devices and methods of communication. In one aspect, a terminal device determines that transmission of synchronous data under a split bearer is configured. If the synchronous data is to be transmitted, the terminal device determines an entity from a plurality of entities for the split bearer, and transmit the synchronous data to a network device via the entity. In this way, data that requires synchronization may be submitted to the same RLC entity when split transmission happens and thus synchronous transmission of multi-modal data may be guaranteed.

Description

DEVICES AND METHODS OF COMMUNICATIONTECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to methods, devices and computer storage media of communication for multi-modality flows.BACKGROUND

[0002] Devices for an immersive multi-modal virtual reality (VR) application may include multiple types of devices such as VR glass type device, gloves and other potential devices that support haptic and / or kinaesthetic modal. These devices which are user equipment (UE) that are connected to an immersive multi-modal VR application server via the fifth generation (5G) network without any UE relays. The immersive multi-modal VR application for single or multiple UEs requires coordination or synchronization of multiple data streams that are closely related. Thus, potential enhancements to support multi-modality flows may be considered.SUMMARY

[0003] In general, embodiments of the present disclosure provide methods, devices and computer storage media of communication for multi-modality flows.

[0004] In a first aspect, there is provided a terminal device. The terminal device comprises a processor configured to cause the terminal device to: determine that a first packet in a first data stream and a second packet in a second data stream are to be synchronized; and perform synchronization of the first packet and the second packet based on at least one of the following: a mapping between data streams and quality of service (QoS) flows, a mapping between packets and QoS flows, a mapping between packets and protocol data unit (PDU) sets, a mapping between packets and logical channels (LCHs) , a mapping between packets and importance values, or a mapping between packets and sub-LCHs.

[0005] In a second aspect, there is provided a network device. The network device comprises a processor configured to cause the network device to: determine a configuration indicating at least one of the following: an indication indicating whether a multi-modal service for packet synchronization is enabled, a group of packets or data streams or terminal  devices to be synchronized, the group of packets or data streams or terminal devices being associated with at least one of an LCH, a data radio bearer (DRB) or a QoS flow, a list of sub-LCHs belonging to the LCH or the DRB that are transmitted synchronously, or an importance value associated with the LCH or a sub-LCH in the list of sub-LCHs; and transmit the configuration to a terminal device.

[0006] In a third aspect, there is provided a method of communication. The method comprises: determining, at a terminal device, that a first packet in a first data stream and a second packet in a second data stream are to be synchronized; and performing synchronization of the first packet and the second packet based on at least one of the following: a mapping between data streams and QoS flows, a mapping between packets and QoS flows, a mapping between packets and PDU sets, a mapping between packets and LCHs, a mapping between packets and importance values, or a mapping between packets and sub-LCHs.

[0007] In a fourth aspect, there is provided a method of communication. The method comprises: determining, at a network device, a configuration indicating at least one of the following: an indication indicating whether a multi-modal service for packet synchronization is enabled, a group of packets or data streams or terminal devices to be synchronized, the group of packets or data streams or terminal devices being associated with at least one of an LCH, a DRB or a QoS flow, a list of sub-LCHs belonging to the LCH or the DRB that are transmitted synchronously, or an importance value associated with the LCH or a sub-LCH in the list of sub-LCHs; and transmitting the configuration to a terminal device.

[0008] In a fifth aspect, there is provided a terminal device. The terminal device comprises a processor configured to cause the terminal device to: determine that transmission of synchronous data under a split bearer is configured; in accordance with a determination that the synchronous data is to be transmitted, determine an entity from a plurality of entities for the split bearer; and transmit, to a network device, the synchronous data via the entity.

[0009] In a sixth aspect, there is provided a terminal device. The terminal device comprises a processor configured to cause the terminal device to: determine that LCHs are configured for a radio bearer; and in accordance with a determination that data is to be transmitted, map the data to carriers of the LCHs based on importance values or QoS flows associated with the data.

[0010] In a seventh aspect, there is provided a terminal device. The terminal device  comprises a processor configured to cause the terminal device to: determine that carriers are configured for the terminal device; and in accordance with a determination that synchronous data is to be transmitted, transmit, to a network device, the synchronous data via one of the carriers.

[0011] In an eighth aspect, there is provided a method of communication. The method comprises: determining, at a terminal device, that transmission of synchronous data under a split bearer is configured; in accordance with a determination that the synchronous data is to be transmitted, determine an entity from a plurality of entities for the split bearer; and transmitting, to a network device, the synchronous data via the entity.

[0012] In a ninth aspect, there is provided a method of communication. The method comprises: determining, at a terminal device, that LCHs are configured for a radio bearer; and in accordance with a determination that data is to be transmitted, mapping the data to carriers of the LCHs based on importance values or QoS flows associated with the data.

[0013] In a tenth aspect, there is provided a method of communication. The method comprises: determining, at a terminal device, that carriers are configured for the terminal device; and in accordance with a determination that synchronous data is to be transmitted, transmitting, to a network device, the synchronous data via one of the carriers.

[0014] In an eleventh aspect, there is provided a computer readable medium having instructions stored thereon. The instructions, when executed on at least one processor, cause the at least one processor to perform the method according to the third or fourth aspect or any of the eighth to tenth aspects of the present disclosure.

[0015] Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Through the more detailed description of some embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein:

[0017] FIG. 1 illustrates an example communication network in which some embodiments of the present disclosure can be implemented;

[0018] FIG. 2 illustrates a schematic diagram illustrating a process of synchronizing packets  of data streams according to embodiments of the present disclosure;

[0019] FIG. 3 illustrates a schematic diagram illustrating an example medium access control (MAC) control element (CE) for a buffer status report (BSR) according to embodiments of the present disclosure;

[0020] FIG. 4A illustrates a schematic diagram illustrating an example packet synchronization according to embodiments of the present disclosure;

[0021] FIG. 4B illustrates a schematic diagram illustrating another example packet synchronization according to embodiments of the present disclosure;

[0022] FIG. 4C illustrates a schematic diagram illustrating another example packet synchronization according to embodiments of the present disclosure;

[0023] FIG. 4D illustrates a schematic diagram illustrating another example packet synchronization according to embodiments of the present disclosure;

[0024] FIG. 4E illustrates a schematic diagram illustrating another example packet synchronization according to embodiments of the present disclosure;

[0025] FIG. 4F illustrates a schematic diagram illustrating another example packet synchronization according to embodiments of the present disclosure;

[0026] FIG. 5 illustrates a schematic diagram illustrating a process of transmitting data according to embodiments of the present disclosure;

[0027] FIG. 6 illustrates a schematic diagram illustrating an example transmission under a split bearer according to embodiments of the present disclosure;

[0028] FIG. 7 illustrates a schematic diagram illustrating another process of transmitting data according to embodiments of the present disclosure;

[0029] FIG. 8A illustrates a schematic diagram illustrating an example transmission via an LCH on a specific carrier according to embodiments of the present disclosure;

[0030] FIG. 8B illustrates a schematic diagram illustrating another example transmission via an LCH on a specific carrier according to embodiments of the present disclosure;

[0031] FIG. 9 illustrates a schematic diagram illustrating still another process of transmitting data according to embodiments of the present disclosure;

[0032] FIG. 10A illustrates a schematic diagram illustrating an example transmission via a licensed or unlicensed carrier according to embodiments of the present disclosure;

[0033] FIG. 10B illustrates a schematic diagram illustrating an example transmission via the third generation partnership project (3GPP) or non-3GPP network according to embodiments of the present disclosure;

[0034] FIG. 11 illustrates an example method of communication implemented at a terminal device in accordance with some embodiments of the present disclosure;

[0035] FIG. 12 illustrates an example method of communication implemented at a network device in accordance with some embodiments of the present disclosure;

[0036] FIG. 13 illustrates another example method of communication implemented at a terminal device in accordance with some embodiments of the present disclosure;

[0037] FIG. 14 illustrates another example method of communication implemented at a terminal device in accordance with some embodiments of the present disclosure;

[0038] FIG. 15 illustrates another example method of communication implemented at a terminal device in accordance with some embodiments of the present disclosure; and

[0039] FIG. 16 is a simplified block diagram of a device that is suitable for implementing embodiments of the present disclosure.

[0040] Throughout the drawings, the same or similar reference numerals represent the same or similar element.DETAILED DESCRIPTION

[0041] Principle of the present disclosure will now be described with reference to some embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitations as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

[0042] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0043] As used herein, the term ‘terminal device’ refers to any device having wireless or wired communication capabilities. Examples of the terminal device include, but not limited to, user equipment (UE) , personal computers, desktops, mobile phones, cellular phones,  smart phones, personal digital assistants (PDAs) , portable computers, tablets, wearable devices, internet of things (IoT) devices, Ultra-reliable and Low Latency Communications (URLLC) devices, Internet of Everything (IoE) devices, machine type communication (MTC) devices, device on vehicle for V2X communication where X means pedestrian, vehicle, or infrastructure / network, devices for Integrated Access and Backhaul (IAB) , Space borne vehicles or Air borne vehicles in Non-terrestrial networks (NTN) including Satellites and High Altitude Platforms (HAPs) encompassing Unmanned Aircraft Systems (UAS) , eXtended Reality (XR) devices including different types of realities such as Augmented Reality (AR) , Mixed Reality (MR) and Virtual Reality (VR) , the unmanned aerial vehicle (UAV) commonly known as a drone which is an aircraft without any human pilot, devices on high speed train (HST) , or image capture devices such as digital cameras, sensors, gaming devices, music storage and playback appliances, or Internet appliances enabling wireless or wired Internet access and browsing and the like. The ‘terminal device’ can further has ‘multicast / broadcast’ feature, to support public safety and mission critical, V2X applications, transparent IPv4 / IPv6 multicast delivery, IPTV, smart TV, radio services, software delivery over wireless, group communications and IoT applications. It may also incorporate one or multiple Subscriber Identity Module (SIM) as known as Multi-SIM. The term “terminal device” can be used interchangeably with a UE, a mobile station, a subscriber station, a mobile terminal, a user terminal or a wireless device.

[0044] As used herein, the term “network device” refers to a device which is capable of providing or hosting a cell or coverage where terminal devices can communicate. Examples of a network device include, but not limited to, a Node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a next generation NodeB (gNB) , a transmission reception point (TRP) , a remote radio unit (RRU) , a radio head (RH) , a remote radio head (RRH) , an IAB node, a low power node such as a femto node, a pico node, a reconfigurable intelligent surface (RIS) , and the like.

[0045] The terminal device or the network device may have Artificial intelligence (AI) or Machine learning capability. It generally includes a model which has been trained from numerous collected data for a specific function, and can be used to predict some information.

[0046] The terminal or the network device may work on several frequency ranges, e.g. FR1 (410 MHz to 7125 MHz) , FR2 (24.25GHz to 71GHz) , frequency band larger than 100GHz as well as Tera Hertz (THz) . It can further work on licensed / unlicensed / shared spectrum. The terminal device may have more than one connection with the network devices under  Multi-Radio Dual Connectivity (MR-DC) application scenario. The terminal device or the network device can work on full duplex, flexible duplex and cross division duplex modes.

[0047] The embodiments of the present disclosure may be performed in test equipment, e.g. signal generator, signal analyzer, spectrum analyzer, network analyzer, test terminal device, test network device, channel emulator.

[0048] In one embodiment, the terminal device may be connected with a first network device and a second network device. One of the first network device and the second network device may be a master node and the other one may be a secondary node. The first network device and the second network device may use different radio access technologies (RATs) . In one embodiment, the first network device may be a first RAT device and the second network device may be a second RAT device. In one embodiment, the first RAT device is eNB and the second RAT device is gNB. Information related with different RATs may be transmitted to the terminal device from at least one of the first network device or the second network device. In one embodiment, first information may be transmitted to the terminal device from the first network device and second information may be transmitted to the terminal device from the second network device directly or via the first network device. In one embodiment, information related with configuration for the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information related with reconfiguration for the terminal device configured by the second network device may be transmitted to the terminal device from the second network device directly or via the first network device.

[0049] As used herein, the singular forms ‘a’ , ‘an’ and ‘the’ are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term ‘includes’ and its variants are to be read as open terms that mean ‘includes, but is not limited to. ’ The term ‘based on’ is to be read as ‘at least in part based on. ’ The term ‘one embodiment’ and ‘an embodiment’ are to be read as ‘at least one embodiment. ’ The term ‘another embodiment’ is to be read as ‘at least one other embodiment. ’ The terms ‘first, ’ ‘second, ’ and the like may refer to different or same objects. Other definitions, explicit and implicit, may be included below.

[0050] In some examples, values, procedures, or apparatus are referred to as ‘best, ’ ‘lowest, ’ ‘highest, ’ ‘minimum, ’ ‘maximum, ’ or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many used functional alternatives can be made,  and such selections need not be better, smaller, higher, or otherwise preferable to other selections.

[0051] Multi-modal data is defined to describe input data from different kinds of devices / sensors or output data to different kinds of destinations (e.g. one or more UEs) required for the same task or application. Multi-modal data consists of more than one single-modal data, and there is strong dependency among each single-modal data. Single-modal data can be seen as one type of data.

[0052] For a typical tactile and multi-modal communication service or application, there may be different modalities affecting user experience, e.g.: video / audio media; information perceived by sensors about the environment, e.g. brightness, temperature, humidity, etc.; haptic data that can be feelings when touching a surface (e.g., pressure, texture, vibration, temperature) , or kinaesthetic senses (e.g. gravity, pull forces, sense of position awareness) .

[0053] In the context of the present disclosure, the term “multi-modality service” may refer to coordination or synchronization of multi-modality flows or multi-modal data flows / streams. The term “multi-modal data flows group” may contain multi-modal data flows of an application targeting to different UEs.

[0054] Embodiments of the present disclosure provide solutions of communication so as to support multi-modality flows or a multi-modality service. In one aspect, upon determination that a first packet in a first data stream and a second packet in a second data stream are to be synchronized, a terminal device performs synchronization of the first packet and the second packet based on at least one of the following: a mapping between data streams and QoS flows, a mapping between packets and QoS flows, a mapping between packets and PDU sets, a mapping between packets and LCHs, a mapping between packets and importance values, or a mapping between packets and sub-LCHs. In this way, coordination or synchronization of multi-modal data may be achieved.

[0055] In another aspect, a terminal device determines that transmission of synchronous data under a split bearer is configured. If the synchronous data is to be transmitted, the terminal device determines an entity from a plurality of entities for the split bearer, and transmit the synchronous data to a network device via the entity. In this way, data that requires synchronization may be submitted to the same radio link control (RLC) entity when split transmission happens and thus synchronous transmission of multi-modal data may be guaranteed.

[0056] In still another aspect, a terminal device determines that LCHs are configured for a radio bearer. If data is to be transmitted, the terminal device maps the data to carriers of the LCHs based on importance values or QoS flows associated with the data. In this way, packets with different importance values or QoS flows may be submitted to different RLC entities on different carriers. By mapping packets to a specific carrier, a reliable transmission may be guaranteed, and latency for more important data may be reduced.

[0057] In yet still another aspect, a terminal device determines that carriers are configured for the terminal device. If synchronous data is to be transmitted, the terminal device transmits the synchronous data to a network device via one of the carriers. In this way, data that requires synchronization or important data may be submitted to the same connection, and thus a delay caused by different connections may be avoided. In addition, more important packets may be transmitted on a connection which provides higher reliability or shorter latency.

[0058] Principles and implementations of the present disclosure will be described in detail below with reference to the figures.

[0059] EXAMPLE OF COMMUNICATION NETWORK

[0060] FIG. 1 illustrates a schematic diagram of an example communication network 100 in which some embodiments of the present disclosure can be implemented. As shown in FIG. 1, the communication network 100 may include terminal devices 110 and 111 and a network device 120. In this example, the terminal devices 110 and 111 may be served by the network device 120.

[0061] As shown in FIG. 1, each of the terminal devices 110 and 111 may communicate with the network device 120 via a channel such as a wireless communication channel. The communications in the communication network 100 may conform to any suitable standards including, but not limited to, Global System for Mobile Communications (GSM) , Long Term Evolution (LTE) , LTE-Evolution, LTE-Advanced (LTE-A) , New Radio (NR) , Wideband Code Division Multiple Access (WCDMA) , Code Division Multiple Access (CDMA) , GSM EDGE Radio Access Network (GERAN) , Machine Type Communication (MTC) and the like. The embodiments of the present disclosure may be performed according to any generation communication protocols either currently known or to be developed in the future. Examples of the communication protocols include, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth  generation (4G) , 4.5G, the fifth generation (5G) communication protocols, 5.5G, 5G-Advanced networks, or the sixth generation (6G) networks.

[0062] As shown in FIG. 1, the communication network 100 may further include an application server 130. The terminal devices 110 and 111 may communicate with the application server 130 via the network device 120. It is to be understood that the communication network 100 may also include one or more core network (CN) elements (not shown) to support the communication between the network device 120 and the application server 130.

[0063] In the example of FIG. 1, the terminal device 110 and the terminal device 111 are respectively shown as a glass and gloves. It is to be understood that FIG. 1 is merely an example, and the terminal devices 110 and 111 may be any other suitable devices.

[0064] It is also to be understood that the numbers or types of terminal devices, network devices or application servers in FIG. 1 are given for the purpose of illustration without suggesting any limitations to the present disclosure. The communication network 100 may include any suitable number or type of network devices and / or terminal devices and / or application servers adapted for implementing implementations of the present disclosure.

[0065] In some scenarios, the terminal device 110 and the terminal device 111 may be terminal devices involving the same multi-modal application, and the application server 130 may provide the multi-modal application. The terminal device 110 may transmit a first data stream to the application server 130 via the network device 120, and the terminal device 111 may transmit a second data stream to the application server 130 via the network device 120. Thus, the first data stream and the second data stream may be closed related.

[0066] In some embodiments, each of the first data stream and the second data steam may include single-modal data, and the first data stream and the second data steam may collectively form multi-modal data. In some embodiments, the first data stream and / or the second data steam may include multi-modal data. It is to be understood that the multi-modal application may involve more terminal devices and more data streams. The multi-modal application may require coordination or synchronization of the data streams or packets in the data streams.

[0067] Current control plane (CP)  / user plane (UP) protocol does not support a coordinated handling for multiple data streams / QoS flows, which may not guarantee synchronization or dependency between data streams / QoS flows. This may lead bad UE experience for a multi- modality service. Further, the current CP / UP protocol does not support synchronized transmission of multiple UEs. This may lead bad UE experience for multi-modal data targeting to different UEs.

[0068] Further, for a split bearer, if total amount of data volume pending for transmission is equal or larger than a configured threshold (i.e., ul-DataSplitThreshold) , the data may be submitted to primary entity or split secondary RLC entity based on UE’s implementation. Hence, UE may submit synchronous data of QoS flows to different RLC entities when split transmission happens. Since the RLC entities belongs to different cell groups (CGs) or nodes and scheduling is independent for CGs, a synchronous transmission for different data or data flows may not be guaranteed.

[0069] Furthermore, if the third generation partnership project (3GPP) connection (or licensed band carrier) and new radio-unlicensed (NR-U)  / non-3GPP connection are configured for UE, synchronous transmission or latency for different data flows may not be guaranteed if data is transmitted on NR-U / non-3GPP connection.

[0070] In view of the above, embodiments of the present disclosure provide solutions of communication so as to overcome the above and other potential issues. These solutions will be described in detail with reference to FIGs. 2 to 10B. For convenience, the following description is given by taking two data streams as an example of multiple data streams.

[0071] In the context of the present disclosure, the term “synchronous data” refers to data to be synchronized, including packets or data streams or QoS flows or PDU sets or importance values to be synchronized. The term “importance value” may be interchangeably used with “importance” .

[0072] EXAMPLE IMPLEMENTATION OF SYNCHRONIZATION OF PACKETS

[0073] Embodiments of the present disclosure provide a solution of communication for coordinating or synchronizing multiple data streams or multiple packets in the multiple data streams. The solution will be described in detail with reference to FIGs. 2 to 4F. For convenience, the following description is given by taking two data streams as an example of multiple data streams and taking two packets as an example of multiple packets.

[0074] FIG. 2 illustrates a schematic diagram illustrating a process 200 of synchronizing packets of data streams according to embodiments of the present disclosure. For the purpose of discussion, the process 200 will be described with reference to FIG. 1. The process 200 may involve the terminal device 110 and the network device 120 as illustrated  in FIG. 1. Of course, the process 200 may also be applied to the terminal device 111 and the network device 120. It is to be understood that the steps and the order of the steps in FIG. 2 are merely for illustration, and not for limitation. For example, the order of the steps may be changed. Some of the steps may be omitted or any other suitable additional steps may be added.

[0075] As shown in FIG. 2, the terminal device 110 may transmit 210, to the network device 120, capability of the terminal device 110, e.g., via a radio resource control (RRC) signaling such as a UECapabilityInformation message. In some embodiments, the capability of the terminal device 110 may indicate whether the terminal device 110 supports a multi-modal service or multi-modality for synchronization. In some embodiments, the capability of the terminal device 110 may indicate whether the terminal device 110 supports a coordination among QoS flows, terminal devices, DRBs, LCHs or importance values. In some embodiments, the capability of the terminal device 110 may indicate whether the terminal device 110 supports a synchronized transmission among QoS flows, terminal devices, DRBs, LCHs or importance values. In some embodiments, the capability of the terminal device 110 may indicate whether the terminal device 110 supports a list of sub-LCHs. In some embodiments, the capability of the terminal device 110 may indicate the maximum number of sub-LCHs supported by the terminal device 110. In some embodiments, sub-LCHs belonging to the same LCH or DRB may be transmitted synchronously. It is to be understood that any combination of the above information may also be feasible.

[0076] Continuing to refer to FIG. 2, the terminal device 110 may transmit 220 information for multi-modal data streams to the network device 120. In some embodiments, the terminal device 110 may transmit the information to a CN element (not shown) . In some embodiments, for uplink, the terminal device 110 may report the information to the network device 120 or the CN element.

[0077] In some embodiments, the terminal device 110 may report the information via time sensitive communication assistance information (TSCAI) . In some embodiments, the terminal device 110 may report the information via a non-access stratum (NAS) signaling. In some embodiments, the terminal device 110 may report the information via an RRC signaling. In some embodiments, the terminal device 110 may report the information via a MAC CE. In some embodiments, the terminal device 110 may report the information in a packet header.

[0078] In some embodiments, the information may indicate terminal devices to be synchronized. In other words, the information may indicate which terminal devices should be coordinated scheduled or transmitted synchronously (i.e., dependency information between terminal devices) .

[0079] In some embodiments, the information may indicate QoS flows to be synchronized. In other words, the information may indicate which QoS flows should be coordinated scheduled or transmitted synchronously (i.e., dependency information between QoS flows) .

[0080] In some embodiments, the information may indicate DRBs to be synchronized. In other words, the information may indicate which DRBs should be coordinated scheduled or transmitted synchronously (i.e., dependency information between DRBs) .

[0081] In some embodiments, the information may indicate importance values of packets (e.g., service data units (SDUs) , PDUs or PDU sets) to be synchronized. In other words, the information may indicate which importance values should be coordinated scheduled or transmitted synchronously (i.e., dependency information between importance values) .

[0082] In some embodiments, the information may indicate information (also referred to as group information herein) of a group of packets or data streams to be synchronized, e.g., a group ID or any other suitable information. In other words, the terminal device 110 may report, to the network device 120, group information to which the terminal device 110 belongs. For example, if two terminal devices report the same group ID to the network device 120, the network device 120 may consider these two terminal devices belong to the same group. Then the network device 120 may coordinately schedule these two UEs. For example, packets that need to be transmitted simultaneously shall be coordinated scheduled, e.g., scheduled simultaneously.

[0083] In some embodiments, the group information may be predefined in the terminal device 110. In some embodiments, the group information may be indicated by a higher layer, e.g., an application layer of the terminal device 110. In some embodiments, the group information may be assigned or configured by the network device 120, e.g., via an RRC signaling. In some embodiments, the group information may be assigned or configured by a CN element (not shown) , e.g., via a NAS signaling.

[0084] In some embodiments, the information may indicate LCHs or logical channel groups (LCGs) to be synchronized. In other words, the information may indicate which LCHs or LCGs should be coordinated scheduled or transmitted synchronously (i.e., dependency  information between LCHs or LCGs) .

[0085] Based on the information reported by a terminal device, the network may properly schedule terminal devices simultaneously, or configure the terminal device to multiplex the data flows / packets that should be transmitted synchronously in the same MAC PDU (e.g., during a logical channel priority (LCP) procedure) .

[0086] In some embodiments, the terminal device 110 may transmit a BSR comprising a buffer size of LCHs or LCGs to be synchronized. In some embodiments, the terminal device 110 may transmit a BSR comprising identities of LCHs or LCGs to be synchronized. In some embodiments, the terminal device 110 may transmit a BSR comprising both the buffer size and identities of the LCHs or LCGs to be synchronized. In some embodiments, the terminal device 110 may transmit the BSR if the buffer size of the LCHs or LCGs to be synchronized is above (i.e., larger than or equal to) a threshold size. In some embodiments, the threshold size may be 0.

[0087] In some embodiments, the BSR may be reported via a MAC CE. FIG. 3 illustrates a schematic diagram illustrating an example MAC CE 300 for a BSR according to embodiments of the present disclosure. As shown in FIG. 3, the MAC CE 300 may include a field 310 indicating information (e.g., LCH / LCG ID) of an LCH or LCG to be synchronized and a field 320 indicating a buffer size of synchronous data on the LCH or LCG. It is to be understood that any other suitable forms are also feasible.

[0088] Accordingly, the network device 120 may receive the BSR reported from terminal devices. Continuing to refer to FIG. 2, the network device 120 may determine 230 whether a synchronous transmission among the terminal devices is required. If the synchronous transmission is required, the network device 120 may transmit 240, to each of the terminal devices (e.g., the terminal device 110) , an indication of a UL grant for transmitting synchronous data on the LCHs or LCGs. In some embodiments, the network device 120 may transmit the indication via downlink control information (DCI) . In some embodiments, the network device 120 may transmit the indication via a MAC CE. Based on the indication, the terminal device 110 may transmit the synchronous data on the LCHs or LCGs via the UL grant.

[0089] In some embodiments, the network device 120 may transmit 240’, to the terminal device 110, an indication that the LCHs or LCGs are multiplexed with a high priority. In some embodiments, the network device 120 may transmit the indication via downlink control  information (DCI) . In some embodiments, the network device 120 may transmit the indication via a MAC CE. Based on the indication, the terminal device 110 may multiplex synchronous data on the LCHs or LCGs with the high priority during an LCP procedure. In some embodiments, the network device 120 may configure the terminal device 110 with one or more priority values for an LCH that are used when the indication is received.

[0090] In this way, for multi-modal data flows / streams targeting to different terminal devices, each terminal device may report a buffer status of data of LCHs / LCGs which should be synchronized. Based on the buffer status received, a network device may schedule terminal devices synchronously and indicate terminal devices to transmit the data with a higher priority. Thereby, synchronization between different terminal devices may be guaranteed.

[0091] Continuing to refer to FIG. 2, the terminal device 110 may transmit 250, to the network device 120, information of quality of experience (QoE) measurement. In some embodiments, the information of QoE measurement may comprise a synchronization loss rate for QoS flows. In some embodiments, the information of QoE measurement may comprise a synchronization delay among QoS flows. In some embodiments, the information of QoE measurement may comprise a jitter among QoS flows. It is to be understood that any combination of the above information may also be feasible. With the information of QoE measurement, the network may optimize a configuration for multi-modal service.

[0092] Continuing to refer to FIG. 2, the network device 120 may transmit 260, to the terminal device 110, a configuration for multi-modal service, e.g., via an RRC signaling. Alternatively, a CN element (not shown) may transmit, to the terminal device 110, the configuration for multi-modal service, e.g., via a non-access stratum signaling.

[0093] In some embodiments, the configuration may comprise a group of packets or data streams or terminal devices to be synchronized. This group may also be called as a multi-modal data group or a synchronization group herein. The term “multi-modal data group” or “synchronization group” may contain data flows or QoS flows of one or more sessions (or an application) targeting to the same terminal device or different terminal devices. Data flows or QoS flows or DRBs or LCHs or importance values belonging to the same group may be scheduled in a coordinated manner or be transmitted synchronously. In some embodiments, a group identity (ID) may be used to uniquely identify a group to which a  terminal device or a data flow or a QoS flow or a DRB or an LCH or an importance value belongs.

[0094] In some embodiments, a CN element (not shown) may indicate, to the network device 120 or to the terminal device 110, at least one of the following: a group ID (e.g., multi-modal data group ID) ; which terminal devices belong to the group indicated by the group ID; which QoS flows belong to the group indicated by the group ID; or which importance values belong to the group indicated by the group ID.

[0095] In some embodiments, the network device 120 may indicate, to the terminal device 110, at least one of the following: a group ID (e.g., multi-modal data group ID) ; which terminal devices belong to the group indicated by the group ID; which QoS flows belong to the group indicated by the group ID; which DRBs belong to the group indicated by the group ID; which LCHs belong to the group indicated by the group ID; or which importance values belong to the group indicated by the group ID.

[0096] In some embodiments, the configuration may comprise an indication indicating whether the multi-modal service for the synchronization is enabled. In some embodiments, the configuration may comprise a list of sub-LCHs belonging to the LCH or the DRB that are transmitted synchronously. In some embodiments, the configuration may comprise an importance value associated with the LCH or a sub-LCH in the list of sub-LCHs.

[0097] In some embodiments, the group of packets or data streams or terminal devices may be associated with an LCH. For illustration, an example LCH configuration may be described as below.

[0098] In this example, IE “groupId” indicates a group ID, IE “subLogicalChannelToAddModList” indicates a list of sub-LCHs, and IE “importance” indicates an importance value associated with the LCH or a sub-LCH in the list of sub-LCHs.

[0099] In some embodiments, the group of packets or data streams or terminal devices may be associated with a DRB. For illustration, an example DRB configuration may be described as below. In this example, IE “groupId” indicates a group ID.

[0100] In some embodiments, the group of packets or data streams or terminal devices may be associated with a QoS flow. In some embodiments, the group of packets or data streams or terminal devices may be associated with an importance value (e.g., PDU set importance (PSI) ) .

[0101] For illustration, an example service data adaptation protocol (SDAP) configuration may be described as below.

[0102] In this example, IE “groupId” indicates a group ID, IE “QoS-FlowToAdd” indicates a list of QoS flow IDs belonging to the group indicated by the group ID, and IE “ImportancesToAdd” indicates a list of importance values belonging to the group indicated by the group ID.

[0103] It is to be understood that the group of packets or data streams or terminal devices may be associated with any other suitable information.

[0104] Continuing to refer to FIG. 2, the terminal device 110 may determine 270 whether a first packet in a first data stream and a second packet in a second data stream are to be synchronized. In some embodiments, the first data stream and the second data stream may be downlink (DL) data. In some embodiments, the first data stream and the second data stream may be uplink (UL) data.

[0105] In some embodiments, if the first packet and the second packet are associated with an ID of a group to be synchronized (i.e., a multi-modal data group ID) , the terminal device 110 may determine that the first packet and the second packet are to be synchronized. In other words, data from upper layers belonging to the same multi-modal data group may be considered as data to be synchronized. Otherwise, the data may not be considered as data to be synchronized.

[0106] In some embodiments, if the first packet and the second packet fall within a time window, the terminal device 110 may determine that the first packet and the second packet are to be synchronized. In other words, data from upper layers which falls within the time window may be considered as data to be synchronized. Otherwise, the data may not be considered as data to be synchronized.

[0107] In some embodiments, the network device 120 may configure the time window to the terminal device 110. For example, the network device 120 may configure at least one of a periodicity, an offset or a duration of the time window. It is to be understood that the time window may also be configured in any other suitable ways. In some alternative embodiments, the time window may be predefined.

[0108] In some embodiments, if a difference between a timestamp associated with the first packet and a timestamp associated with the second packet is below (i.e., smaller than or equal to) a threshold difference, the terminal device 110 may determine that the first packet and the second packet are to be synchronized. In some embodiments, the threshold difference may be configured by the network device 120. In some embodiments, the threshold difference may be predefined.

[0109] In other words, a timestamp may be carried with a packet (e.g., in a header of the packet) . Based on the timestamp, the terminal device 110 may determine whether two packets should be synchronized. For example, if the time difference between the two packets falls within a configured range, these two packets may be considered as data to be synchronized. Otherwise, these two packets may not be considered as data to be  synchronized.

[0110] Continuing to refer to FIG. 2, upon determination that the first packet and the second packet are to be synchronized, the terminal device may perform 280 a synchronization of the first packet and the second packet. In some embodiments, the synchronization may be based on at least one of the following: a mapping between data streams and QoS flows, a mapping between packets and QoS flows, a mapping between packets and PDU sets, a mapping between packets and LCHs, a mapping between packets and importance values, or a mapping between packets and sub-LCHs. Some example embodiments will be described in connection with Embodiments 1 to 6 below.

[0111] Embodiment 1

[0112] In this embodiment, data streams may be mapped to the same DRB.

[0113] In some embodiments, the terminal device 110 may map the first data stream and the second data stream to a QoS flow, and map the first packet to a first PDU or PDU set with a first importance value and the second packet to a second PDU or PDU set with a second importance value. Then the terminal device 110 may map the first PDU or PDU set to an LCH or a sub-LCH associated with the first importance value and the second PDU or PDU set to an LCH or a sub-LCH associated with the second importance value. FIG. 4A illustrates a schematic diagram 400 illustrating an example packet synchronization according to embodiments of the present disclosure. In the example of FIG. 4A, for a DRB or LCH, one or more sub-LCHs may be configured, and / or mapping between importance values and LCHs / sub-LCHs may be configured. It is assumed that a data stream 1 and a data stream 2 are to be synchronized.

[0114] As shown in FIG. 4A, the terminal device 110 may map the data stream 1 and the data stream 2 to the same QoS flow. The QoS flow is mapped to a DRB. For a DRB, packets (e.g., PDU sets) with different importance values may be mapped to different LCHs or sub-LCHs. As shown in FIG. 4A, the terminal device 110 may map packets from the data stream 1 to a PDU set 411 with importance 1, and map packets from the data stream 2 to a PDU set 412 with importance 2. Then the terminal device 110 may map the PDU set 411 to LCH 1 or sub-LCH 1 associated with importance 1, and map the PDU set 412 to LCH 2 or sub-LCH 2 associated with importance 2. Alternatively, for a DRB, packets (e.g., PDU sets) with different importance values may be mapped to the same LCH.

[0115] In this way, packets from different streams may be put in the same PDU set, and  thus a synchronous transmission may be guaranteed.

[0116] Embodiment 2

[0117] In this embodiment, synchronous packets may be mapped to the same PDU set with the same importance value.

[0118] In some embodiments, the terminal device 110 may map the first packet and the second packet to the same PDU set associated with an importance value, and map the PDU set to an LCH or a sub-LCH associated with the importance value. In some embodiments, if a PDU set contains packets / PDUs belonging to different data flows / streams, this PDU set may be associated with a specific PSI which is different from a PSI of PDU Sets that carry only packets of a single stream.

[0119] FIG. 4B illustrates a schematic diagram 400B illustrating another example packet synchronization according to embodiments of the present disclosure. In this example, all PDUs within the same PDU set are assigned with the same importance value (e.g. PSI) . It is to be assumed that a packet 421 in a data stream 1 and a packet 422 in a data stream 2 are to be synchronized. As shown in FIG. 4B, the terminal device 110 may map the data stream 1 and the data stream 2 to the same Qos flow. The terminal device 110 may map the packet 421 and the packet 422 to a PDU set 420 with PSI 1, and map a packet 423 and a packet 424 to a PDU with PSI 2 and a PDU with PSI 3 respectively.

[0120] As shown in FIG. 4B, the QoS flow is mapped to a DRB. For a DRB, packets (e.g., PDU sets) with different importance values may be mapped to different LCHs or sub-LCHs. As shown in FIG. 4B, the terminal device 110 may map the PDU set 420 to LCH 1 or sub-LCH 1 associated with PSI 1, map the packet 423 to LCH 2 or sub-LCH 2 associated with PSI 2, and map the packet 424 to LCH 3 or sub-LCH 3 associated with PSI 3. Alternatively, for a DRB, PDU or PDU sets with different PSIs may be mapped to the same LCH.

[0121] In this way, packets from different streams may be put in the same PDU set, and thus a synchronous transmission may be guaranteed. Further, packets (e.g., PDU Sets) with different importance values may be handled differently by mapping to different LCHs / sub-LCHs, and thus QoS requirements of different data streams may be guaranteed.

[0122] Embodiment 3

[0123] In this embodiment, synchronous packets may be mapped to the same PDU set with different importance values.

[0124] In some embodiments, the terminal device 110 may map the first packet and the second packet to a PDU set, and the first packet is associated with a first importance value and the second packet is associated with a second importance value. Then the terminal device 110 may map the first packet in the PDU set to an LCH or a sub-LCH associated with the first importance value, and map the second packet in the PDU set to an LCH or a sub-LCH associated with the second importance value.

[0125] FIG. 4C illustrates a schematic diagram 400C illustrating another example packet synchronization according to embodiments of the present disclosure. In this example, packets belonging to different data flows / streams but need to be synchronized are mapped to the same PDU Set. Packets within the same PDU Set may be associated with different importance values (e.g., packets from different data streams may be associated with different importance in the same PDU Set) . It is to be assumed that a packet 431 in a data stream 1 and a packet 432 in a data stream 2 are to be synchronized.

[0126] As shown in FIG. 4C, the terminal device 110 may map the data stream 1 and the data stream 2 to the same Qos flow. The terminal device 110 may map the packet 431 and the packet 432 to the same PDU set 430, and the packet 431 is associated with PSI 1 and the packet 432 is associated with PSI 2. The QoS flow is mapped to a DRB. For a DRB, packets (e.g., PDU sets) with different importance values may be mapped to different LCHs or sub-LCHs. As shown in FIG. 4C, the terminal device 110 may map the packet 431 to LCH 1 or sub-LCH 1 associated with PSI 1, map the packet 432 to LCH 2 or sub-LCH 2 associated with PSI 2. Alternatively, for a DRB, PDU or PDU sets with different PSIs may be mapped to the same LCH.

[0127] In this way, packets from different streams may be put in the same PDU set, and thus a synchronous transmission may be guaranteed. Further, for a PDU Set, PDUs with different importance values can be handled differently.

[0128] Embodiment 4

[0129] In this embodiment, synchronous packets may be mapped to a specific QoS flow.

[0130] In some embodiments, the terminal device 110 may map the first packet and the second packet to a QoS flow carrying only packets with synchronization requirement, and map the QoS flow to an LCH or a sub-LCH associated with the QoS flow.

[0131] FIG. 4D illustrates a schematic diagram 400D illustrating another example packet synchronization according to embodiments of the present disclosure. In this example,  packets belonging to different data flows / streams but need to be synchronized may be mapped to the same QoS flow, and packets which require synchronization may be mapped to a specific QoS flow that is different from the QoS flows that carry only packets without synchronization requirement (e.g., belonging to a single stream) . It is to be assumed that a packet 441 in a data stream 1 and a packet 442 in a data stream 2 are to be synchronized.

[0132] As shown in FIG. 4D, the terminal device 110 may map the packets 441 and 442 to the same PDU set 440 in a QoS flow 1. The terminal device 110 may map a packet 443 in the data steam 1 to a QoS flow 2 and map a packet 444 in the data stream 2 to a QoS flow 3. The QoS flows 1, 2 and 3 may be mapped to the same DRB or different DRBs. For a DRB, packets (e.g., PDU sets) belonging to different QoS flows may be mapped to different LCHs or sub-LCHs. As shown in FIG. 4D, the terminal device 110 may map the PDU set 440 to LCH 1 or sub-LCH 1, and may map the packets 443 and 444 to LCH 2 or sub-LCH 2. Alternatively, for a DRB, packets belonging to different QoS flows may be mapped to the same LCH.

[0133] In this way, packets that need to be synchronized may be put into a specific PDU set or QoS flow, and thus a synchronous transmission may be guaranteed. Further, different QoS flows may be handled differently, which may make sure that the QoS requirement is met.

[0134] Embodiment 5

[0135] In this embodiment, synchronization may be performed during an LCP procedure.

[0136] In some embodiments, the terminal device 110 may map the first data stream and the second data stream to a first QoS flow and a second QoS flow respectively, and map the first QoS flow and the second QoS flow to a first DRB and a second DRB respectively. Then the terminal device 110 may map the first DRB and the second DRB to a first LCH and a second LCH respectively, and multiplex the first LCH and the second LCH together or with a same priority during an LCP procedure.

[0137] In some embodiments, an LCP enhancement for synchronous LCHs may be carried out. In some embodiments, multiple QoS flows are mapped to different DRBs. For DRBs or QoS flows that need to be coordinated or synchronized, a dependency between LCHs / DRBs, e.g., which LCHs / DRBs should be transmitted synchronously, may be configured by the network device 120, e.g., via an RRC signalling. In some embodiments, if two LCHs should be coordinated or synchronized, the two LCHs may be configured with  the same priority, and may be treated equally when performing an LCP procedure. In some embodiments, if two LCHs belong to the same multi-modal data group, the two LCHs may be transmitted synchronously when performing an LCP procedure.

[0138] In some embodiments, if the first LCH and the second LCH are to be transmitted synchronously, the terminal device 110 may multiplex the first LCH and the second LCH together or with a same priority. In some embodiments, if the first LCH and the second LCH are associated with an ID of a group to be synchronized (i.e., a multi-modal data group ID) , the terminal device 110 may multiplex the first LCH and the second LCH together or with a same priority.

[0139] For illustration, an example LCP procedure may be described as below.

[0140] The MAC entity shall, when a new transmission is performed:

[0141] 1> allocate resources to the logical channels as follows:

[0142] 2> logical channels selected for the UL grant with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a logical channel is set to infinity, the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel before meeting the PBR of the lower priority logical channel (s) .

[0143] Note: If 2 or more logical channels are configured to be transmitted synchronously or belong to the same group, they shall be selected with equal priority.

[0144] 2> decrement Bj by the total size of MAC SDUs served to logical channel j or above;

[0145] 2> if any resources remain, all the logical channels or selected are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel / sub-logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.

[0146] In this example, Bj denotes a counter that is maintained for each LCH j. A value of Bj may be negative.

[0147] FIG. 4E illustrates a schematic diagram 400E illustrating another example packet synchronization according to embodiments of the present disclosure. It is to be assumed that a data stream 1 and a data stream 2 are to be synchronized. As shown in FIG. 4E, the terminal device 110 may map the data stream 1 and the data stream 2 to different QoS flows 1 and 2 and then to different DRBs 1 and 2. Importance values cross QoS flows may be defined, e.g., QoS flows may share the same importance value group. During a LCP  procedure, packets (service data units (SDUs)  / PDUs / PDU sets) , LCHs, QoS flows or DRBs that need to be synchronized may be multiplexed together. For example, the corresponding LCHs may be configured with the same priority.

[0148] In some embodiments, the network device 120 may configure a dependency between different DRBs / LCHs and terminal devices, e.g., which DRBs / LCHs may be coordinated scheduled or multiplexed together when performing an LCP procedure. In some embodiments, a dependency between different packets (e.g., SDU, PDU or PDU set) , e.g., which packets may be transmitted / multiplexed synchronously, may be indicated by higher layer. In some embodiments, the dependency between different packets may be indicated from CN. In some embodiments, the dependency between different packets may be carried in packet headers (e.g., a general packet radio service (GPRS) tunneling protocol for a user plane (GTPU) header or a service data adaptation protocol (SDAP)  / packet data convergence protocol (PDCP)  / RLC / MAC header) .

[0149] In this way, based on dependency information between LCHs / sub-LCHs / packets, LCHs / sub-LCHs / packets that should be coordinated scheduling or transmitted synchronously may be multiplexed in the same MAC PDU during an LCP procedure. Thus, coordination or synchronization of multi-modal data may be achieved by LCP enhancement.

[0150] Embodiment 6

[0151] In this embodiment, PDCP / SDAP may be responsible for mapping synchronous packets from different QoS flows to the same PDU Set.

[0152] In some embodiments, the terminal device 110 may map the first data stream and the second data stream to a first QoS flow and a second QoS flow respectively, and map the first QoS flow and the second QoS flow to a DRB. The first packet and the second packet are mapped to a PDU set by a PDCP or SDAP entity. Then the terminal device 110 may map the first QoS flow and the second QoS flow to a first LCH / sub-LCH associated with the first QoS flow and a second LCH / sub-LCH associated with the second QoS flow, and multiplex the first LCH / sub-LCH and the second LCH / sub-LCH together or with a same priority during an LCP procedure. In this way, coordination or synchronization of multi-modal data may also be achieved.

[0153] FIG. 4F illustrates a schematic diagram 400F illustrating another example packet synchronization according to embodiments of the present disclosure. It is to be assumed that a packet 451 in a data stream 1 and a packet 452 in a data stream 2 are to be synchronized.  As shown in FIG. 4F, the terminal device 110 may map the data stream 1 and the data stream 2 to different QoS flows 1 and 2 and then to the same DRB. A PDCP or SDAP entity of the terminal device 110 may map the packets 451 and 452 to the same PDU set 450. In some embodiments, the network device 120 may indicate, to the terminal device 110, e.g., via an RRC signaling, whether to enable mapping packets of different QoS flows into the same PDU set or unit. In some embodiments, the network device 120 may indicate, to the terminal device 110, which QoS flows should be merged. In some embodiments, the network device 120 may indicate, to the terminal device 110, that a dependency between different packets may be carried in a GTPU header (e.g., an associated PDU set sequence number) .

[0154] For a DRB, packets (e.g., SDUs, PDUs or PDU Sets) associated with different QoS flows may be mapped to the same or different LCHs or sub-LCHs. During an LCP procedure, packets (SDUs / PDUs / PDU Sets) or LCHs / sub-LCHs belonging to the same DRB may be multiplexed together (e.g., with the same priority) . In some embodiments, the network device 120 may configure the terminal device 110 with the information that whether LCHs / sub-LCHs belonging to the same DRB / group should be multiplexed together.

[0155] In some embodiments, an LCP enhancement for synchronous LCHs or sub-LCHs may be carried out. In some embodiments, if the first LCH / sub-LCH and the second LCH / sub-LCH are to be transmitted synchronously, the terminal device 110 may multiplex the first LCH / sub-LCH and the second LCH / sub-LCH together or with a same priority. In some embodiments, if the first LCH / sub-LCH and the second LCH / sub-LCH are associated with an ID of a group to be synchronized (i.e., a multi-modal data group ID) , the terminal device 110 may multiplex the first LCH / sub-LCH and the second LCH / sub-LCH together or with a same priority.

[0156] For illustration, another example LCP procedure may be described as below.

[0157] The MAC entity shall, when a new transmission is performed:

[0158] 1> allocate resources to the logical channels or or sub-logical channels as follows:

[0159] 2> logical channels or sub-logical channels selected for the UL grant with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a logical channel or sub-logical channel is set to infinity, the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel or sub-logical channel before meeting the PBR of the lower priority logical channel (s) or sub-logical channel (s) ;

[0160] Note: If 2 or more logical channels or sub-logical channels are configured to be  transmitted synchronously, or belongs to the same group, they shall be selected (or configured) with equal priority.

[0161] 2> decrement Bj by the total size of MAC SDUs served to logical channel or sub-logical channel j or above;

[0162] 2> if any resources remain, all the logical channels or or sub-logical channels selected are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel / sub-logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.

[0163] In this example, Bj denotes a counter that is maintained for each LCH or sub-LCH j. The value of Bj may be negative.

[0164] In some embodiments, for a DRB, packets with different importance (e.g., PDU Sets with different PSIs) may be mapped to different LCHs or sub-LCHs. In some embodiments, the network device 120 may configure, e.g., via an RRC signaling, a list of sub-LCHs for a LCH or DRBs. Each sub-LCHs may be configured with its own priority, prioritised bit rate, or bucket size duration. Alternatively, sub-LCHs belonging to the same LCH may share the same priority (e.g., the priority of LCH) or Bj of LCH. In some embodiments, the network device 120 may configure, e.g., via an RRC signaling, a dependency between LCHs / sub-LCHs, e.g., which LCHs / sub-LCHs should be transmitted synchronously, or sub-LCHs belonging to the same LCH shall be transmitted synchronously.

[0165] So far, a solution of synchronizing packets of data streams is described. With the solution, coordination or synchronization of multi-modal data may be achieved.

[0166] EXAMPLE IMPLEMENTATION OF DATA TRANSMISSION

[0167] Embodiments of the present disclosure also provide solutions of communication for transmitting data. These solutions mainly involve selection of a carrier for transmitting the data. Detailed description will be given below with reference to FIGs. 5 to 10B.

[0168] 1. CARRIER SELECTION BASED ON SPLIT BEARER

[0169] FIG. 5 illustrates a schematic diagram illustrating a process 500 of transmitting data according to embodiments of the present disclosure. For the purpose of discussion, the process 500 will be described with reference to FIG. 1. The process 500 may involve the terminal device 110 and the network device 120 as illustrated in FIG. 1. Of course, the  process 500 may also be applied to the terminal device 111 and the network device 120. It is to be understood that the steps and the order of the steps in FIG. 5 are merely for illustration, and not for limitation. For example, the order of the steps may be changed. Some of the steps may be omitted or any other suitable additional steps may be added.

[0170] As shown in FIG. 5, the terminal device 110 may determine 510 that transmission of synchronous data under a split bearer is configured. In other words, transmission of synchronous data may be allowed under a split bearer. The split bearer may involve a plurality of entities comprising a primary RLC entity and a secondary RLC entity.

[0171] If there are synchronous data to be transmitted, the terminal device 110 may determine 520 an entity from the plurality of entities for the split bearer. In some embodiments, the determined entity may be the primary RLC entity. In some embodiments, the determined entity may be the secondary RLC entity.

[0172] In some embodiments, the network device 120 may indicate 521 the entity to the terminal device 110. In some embodiments, the terminal device 110 may determine 522 the entity by itself.

[0173] With reference to FIG. 5, upon determination of the entity, the terminal device 110 may transmit 530 the synchronous data to the network device 120 via the determined entity. FIG. 6 illustrates a schematic diagram 600 illustrating an example transmission under a split bearer according to embodiments of the present disclosure. As shown in FIG. 6, for packets or QoS flows or importance values to be synchronized, one of an RLC primary path and an RL secondary path may be determined for transmission of the packets or QoS flows or importance values. In the example of FIG. 6, the RLC primary path is selected for the transmission of the packets or QoS flows or importance values.

[0174] For illustration, some example embodiments will be described in connection with Embodiments 7 to 9 below.

[0175] Embodiment 7

[0176] In this embodiment, the synchronous data is associated with a plurality of QoS flows. In some embodiments, the network device 120 may transmit, to the terminal device 110, a configuration indicating the entity associated with the plurality of QoS flows. In this case, the terminal device 110 may determine the entity based on the configuration. Then, the terminal device 110 may submit, to the entity, PDUs belonging to the plurality of QoS flows upon a split transmission based on the split bearer.

[0177] For illustration, an example configuration may be described as below.

[0178] In this example, information element (IE) “QoS-FlowsToAdd” indicates list of QoS flows to be synchronized / coordinated. All the PDUs of the QoS flows in the list of QoS flows belonging to the same group shall be submitted to the same RLC entity (or the logical channel identified by IE “logicalChannelToMap” ) when a split transmission happens. IE “logicalChannelToMap” indicates an identity of logical channel (i.e., RLC bearer) to which  QoS flows listed in the IE “QoS-FlowsToAdd” shall be mapped. Alternatively, the IE “logicalChannelToMap” (e.g., a BOOLEAN value) may indicate whether a primary path is used to transmit the data of QoS flows. If the IE “logicalChannelToMap” does not exist, the logical channel to be mapped is determined by UE itself.

[0179] In some embodiments, if two or more QoS flows are configured to be coordinated or transmitted synchronously, a transmitting PDCP entity of the terminal device 110 may submit all the PDUs belonging to these QoS flows to the same RLC entity when a split transmission happens, e.g., by mapping the QoS flows to the same LCH.

[0180] For illustration, an example procedure may be described as below.

[0181] When submitting a PDCP PDU to lower layer, the transmitting PDCP entity shall:

[0182] ...

[0183] - else, if the transmitting PDCP entity is associated with at least two RLC entities:

[0184] - if the PDCP duplication is activated for the RB:

[0185] - ...

[0186] - else (i.e. the PDCP duplication is deactivated for the RB or the RB is a DAPS bearer) :

[0187] - if the split secondary RLC entity is configured; and

[0188] - if the total amount of PDCP data volume and RLC data volume pending for initial transmission in the primary RLC entity and the split secondary RLC entity is equal to or larger than ul-DataSplitThreshold:

[0189] - if more than one QoS flows are configured to be coordinated or transmitted synchronously,

[0190] - submit the PDCP PDU or PDU Set belonging to these QoS flows to the same RLC entity (either the primary RLC entity or the split secondary RLC entity, or the RLC entity specified by the network, e.g., logicalChannelToMap) ;

[0191] - else

[0192] - submit the PDCP PDU to either the primary RLC entity or the split secondary RLC entity;

[0193] - else, if the transmitting PDCP entity is associated with the DAPS bearer:

[0194] - ...

[0195] - else:

[0196] - submit the PDCP PDU to the primary RLC entity.

[0197] In this procedure, if the transmitting PDCP entity is associated with two or more RLC entities and coordinated / synchronous transmission of different QoS flows are configured, PDCP Data PDU belonging to these QoS flows should be submitted to the same RLC entity. If the RLC entity to be submitted is not configured by the network, it can be chosen by UE when split transmission happens.

[0198] Based on dependency information of multi-modal data / flows provided by the network or an upper layer, a terminal device may make synchronous QoS flows be submitted to the same RLC entity (or LCH) when a split transmission happens.

[0199] Embodiment 8

[0200] In this embodiment, the synchronous data is associated with a PDU set. In some embodiments, the network device 120 may transmit, to the terminal device 110, a configuration indicating the entity associated with the PDU set. In this case, the terminal device 110 may determine the entity based on the configuration. Then, the terminal device 110 may submit, to the entity, PDUs in the PDU set upon a split transmission based on the split bearer.

[0201] For illustration, an example configuration may be described as below.

[0202] In this example, IE “pduSetSynchronization” indicates whether all the PDUs of a PDU Set should be submitted to the same RLC entity when a split transmission happens (i.e., whether synchronous transmission of a PDU Set is enabled) . This IE may be configured per QoS flow (e.g., under QoS flow configuration) , which indicates all the PDUs of a PDU Set belonging to the corresponding QoS flow shall be submitted to the same RLC entity.

[0203] In some embodiments, if packets which require synchronization are mapped to the same PDU set, a transmitting PDCP entity of the terminal device 110 may submit all the PDUs of a PDU set to the same RLC entity when a split transmission happens.

[0204] For illustration, an example procedure may be described as below.

[0205] When submitting a PDCP PDU to lower layer, the transmitting PDCP entity shall:

[0206] ...

[0207] - else, if the transmitting PDCP entity is associated with at least two RLC entities:

[0208] - if the PDCP duplication is activated for the RB:

[0209] - ...

[0210] - else (i.e. the PDCP duplication is deactivated for the RB or the RB is a DAPS bearer) :

[0211] - if the split secondary RLC entity is configured; and

[0212] - if the total amount of PDCP data volume and RLC data volume pending for initial transmission in the primary RLC entity and the split secondary RLC entity is equal to or larger than ul-DataSplitThreshold:

[0213] - if mapping all PDCP PDUs of a PDU Set to the same RLC entity or synchronous transmission of PDU Set is configured,

[0214] - submit all PDCP PDUs belonging to the same PDU Set to the same RLC entity (either the primary RLC entity or the split secondary RLC entity,  or the RLC entity specified by the network, e.g., logicalChannelToMap) ;

[0215] - else

[0216] - submit the PDCP PDU to either the primary RLC entity or the split secondary RLC entity;

[0217] - else, if the transmitting PDCP entity is associated with the DAPS bearer:

[0218] - ...

[0219] - else:

[0220] - submit the PDCP PDU to the primary RLC entity.

[0221] In this procedure, if the transmitting PDCP entity is associated with two or more RLC entities and coordinated / synchronous transmission of PDU Set is configured, PDCP Data PDUs belonging to the same PDU Set should be submitted to the same RLC entity. If the RLC entity to be submitted is not configured by the network, it can be chosen by UE when split transmission happens.

[0222] Based on dependency information of multi-modal data / flows provided by the network or an upper layer, a terminal device may make synchronous packets belonging to a PDU set be submitted to the same RLC entity (or LCH) when a split transmission happens.

[0223] Embodiment 9

[0224] In this embodiment, the synchronous data is associated with a plurality of importance values. In some embodiments, the network device 120 may transmit, to the terminal device 110, a configuration indicating the entity associated with the plurality of importance values. In this case, the terminal device 110 may determine the entity based on the configuration. Then, the terminal device 110 may submit, to the entity, PDUs associated with the plurality of importance values upon a split transmission based on the split bearer.

[0225] For illustration, an example configuration may be described as below.

[0226] In this example, IE “importanceToAdd” indicates list of importance (e.g., PSI) to be synchronized / coordinated. All the PDUs associated with the importance in the list should be submitted to the same RLC entity (or the logical channel identified by logicalChannelToMap) when split transmission happens. IE “logicalChannelToMap” indicates an identity of logical channel (i.e., RLC bearer) to which the synchronous importance (s) shall be mapped. Alternatively, the IE “logicalChannelToMap” (e.g., a BOOLEAN value) may indicate whether a primary path is used to transmit synchronous importance (s) . If the IE “logicalChannelToMap” does not exist, the logical channel to be mapped is determined by UE itself.

[0227] In some embodiments, if two or more importance (e.g., PSI) are configured to be coordinated or transmitted synchronously, a transmitting PDCP entity of the terminal device 110 may submit all the PDUs associated with these importance values to the same RLC entity  when a split transmission happens.

[0228] For illustration, an example procedure may be described as below.

[0229] When submitting a PDCP PDU to lower layer, the transmitting PDCP entity shall:

[0230] ...

[0231] - else, if the transmitting PDCP entity is associated with at least two RLC entities:

[0232] - if the PDCP duplication is activated for the RB:

[0233] - ...

[0234] - else (i.e. the PDCP duplication is deactivated for the RB or the RB is a DAPS bearer) :

[0235] - if the split secondary RLC entity is configured; and

[0236] - if the total amount of PDCP data volume and RLC data volume pending for initial transmission in the primary RLC entity and the split secondary RLC entity is equal to or larger than ul-DataSplitThreshold:

[0237] - if more than one importance values (e.g., PSI) are configured to be coordinated or transmitted synchronously,

[0238] - submit the PDCP PDU belonging to these importance values to the same RLC entity (either the primary RLC entity or the split secondary RLC entity, or the RLC entity specified by the network, e.g., logicalChannelToMap) ;

[0239] - else

[0240] - submit the PDCP PDU to either the primary RLC entity or the split secondary RLC entity;

[0241] - else, if the transmitting PDCP entity is associated with the DAPS bearer:

[0242] - ...

[0243] - else:

[0244] - submit the PDCP PDU to the primary RLC entity.

[0245] In this procedure, if the transmitting PDCP entity is associated with two or more RLC entities and coordinated / synchronous transmission of different importance values are configured, PDCP Data PDU associated with those importance values should be submitted to the same RLC entity.

[0246] Based on dependency information of multi-modal data / flows provided by the network or an upper layer, a terminal device may make synchronous packets with importance values be submitted to the same RLC entity (or LCH) when a split transmission happens.

[0247] In some embodiments where an entity in a plurality of entities for a split bearer is determined for transmission of synchronous multi-modal data, the terminal device 110 may determine a first data volume on the plurality of entities, and determine a second data volume on the determined entity. Then the terminal device may determine a data volume on a set of entities unselected for transmission of the synchronous data by the first data volume minus the second data volume.

[0248] For illustration, an example procedure may be described as below.

[0249] If the transmitting PDCP entity is associated with at least two RLC entities, when indicating the PDCP data volume to a MAC entity for BSR triggering and Buffer Size calculation, the transmitting PDCP entity shall:

[0250] - if the PDCP duplication is activated for the RB:

[0251] ...

[0252] - else (i.e. the PDCP duplication is deactivated for the RB or the RB is a DAPS bearer) :

[0253] - if the split secondary RLC entity is configured; and

[0254] - if the total amount of PDCP data volume and RLC data volume pending for initial transmission in the primary RLC entity and the split secondary RLC entity is equal to or larger than ul-DataSplitThreshold:

[0255] - if coordinated / synchronous transmission of PDU Set or QoS flows or importance are configured,

[0256] - For the RLC entity that is selected / configured to transmit the synchronous PDUs, indicate the PDCP data volume to the MAC entity associated with the selected RLC entity;

[0257] - For the primary RLC entity or split secondary RLC entity that are not selected / configured to transmit the synchronous PDUs, indicate the “PDCP data volume minus synchronous data volume” to the MAC entities associated with the not-selected RLC entities.

[0258] - indicate the PDCP data volume as 0 to the MAC entity associated with  RLC entity other than the primary RLC entity and the split secondary RLC entity;

[0259] - else

[0260] - indicate the PDCP data volume to both the MAC entity associated with the primary RLC entity and the MAC entity associated with the split secondary RLC entity;

[0261] - indicate the PDCP data volume as 0 to the MAC entity associated with RLC entity other than the primary RLC entity and the split secondary RLC entity.

[0262] So far, transmission of synchronous data under a split bearer is described. Thereby, data that requires synchronization may be submitted to the same RLC entity (LCH) when a split transmission happens. Thus, a synchronized transmission of multi-modal data may be guaranteed.

[0263] 2. CARRIER SELECTION BASED ON IMPORTANCE

[0264] FIG. 7 illustrates a schematic diagram illustrating another process 700 of transmitting data according to embodiments of the present disclosure. For the purpose of discussion, the process 700 will be described with reference to FIG. 1. The process 700 may involve the terminal device 110 and the network device 120 as illustrated in FIG. 1. Of course, the process 700 may also be applied to the terminal device 111 and the network device 120. It is to be understood that the steps and the order of the steps in FIG. 7 are merely for illustration, and not for limitation. For example, the order of the steps may be changed. Some of the steps may be omitted or any other suitable additional steps may be added.

[0265] As shown in FIG. 7, the terminal device 110 may determine 710 that LCHs are configured for a radio bearer. For example, more than one RLC bearers (i.e., LCHs) are configured for a DRB. In some embodiments, if there are data to be transmitted, the terminal device 110 may map 720 the data to carriers of the LCHs based on importance values associated with the data.

[0266] In some embodiments, the network device 120 may transmit 721, to the terminal device 110, a configuration indicating a mapping between the importance values and the LCHs. For example, the network device 120 may transmit the configuration via an RRC signaling.

[0267] For illustration, an example configuration may be described as below.

[0268] ImportanceValue : : = INTEGER (0.. maxNrOfImportance -1)

[0269] In this example, IE “importanceList” indicates a list of importance values associated with an LCH indicated by IE “logicalChannel” . If an importance value (e.g., identified by IE “importanceList” ) is mapped to a logical channel (e.g., identified by IE “logicalChannel” ) , packets (e.g., PDUs or PDU sets) with the importance value may be mapped to the logical channel.

[0270] Based on the configuration, the terminal device 110 may map 722 a first set of packets of the data having a first importance value to a first carrier of a first LCH corresponding to the first importance value and a second set of packets of the data having a second importance value to a second carrier of a second LCH corresponding to the second importance value. In other words, packets (e.g., PDU sets) with different importance values may be mapped to different carriers by mapping an importance value to a LCH on a specific carrier.

[0271] FIG. 8A illustrates a schematic diagram 800A illustrating an example transmission via an LCH on a specific carrier according to embodiments of the present disclosure. As shown in FIG. 8A, packets 811 and 812 are associated with importance value 1, and packets 813 and 814 are associated with importance value 2. The packets 811 and 812 associated with importance value 1 may be mapped to LCH 1 on a master node (MN) , and packets 813 and 814 associated with importance value 2 may be mapped to LCH 2 on a secondary node (SN) . Alternatively, the packets 813 and 814 associated with importance value 2 may be mapped to both LCH 1 and LCH 2.

[0272] In some embodiments, the terminal device 110 may apply a restriction (also referred to as logical channel mapping restrictions herein) in an MAC entity that the LCHs of the radio bearer are sent on a same carrier. For example, if carrier aggregation (CA) and importance mapping to a logical channel on a specific carrier are configured, logical channel mapping restrictions are used in a MAC entity to ensure that the logical channels of a radio bearer in the MAC entity are sent on the same (or indicated) carrier.

[0273] In this way, packets with different importance values may be submitted to different  RLC entities on different carriers. By mapping packets with an importance value to a specific carrier, a reliable transmission may be guaranteed, and a latency for more important data packets may be reduced.

[0274] Continuing to refer to FIG. 7, in some embodiments, if there are data to be transmitted, the terminal device 110 may map 730 the data to carriers of the LCHs based on QoS flows associated with the data.

[0275] In some embodiments, the network device 120 may transmit 731, to the terminal device 110, a configuration indicating a mapping between the QoS flows and the LCHs. For example, the network device 120 may transmit the configuration via an RRC signaling.

[0276] For illustration, an example configuration may be described as below.

[0277] In this example, IE “mappedQoS-FlowsToAdd” indicates QoS flows associated with an LCH indicated by IE “logicalChannel” . If a QoS flow (e.g., identified by IE “mappedQoS-FlowsToAdd” ) is mapped to a logical channel (e.g., identified by IE “logicalChannel” ) , packets (e.g., PDUs or PDU sets) of the QoS flow may be mapped to the logical channel.

[0278] Based on the configuration, the terminal device 110 may map 732 a first QoS flow of the data to a third carrier of a third LCH corresponding to the first QoS flow and a second QoS flow of the data to a fourth carrier of a fourth LCH corresponding to the second QoS flow. In other words, packets (e.g., PDU sets) of different QoS flows or DRBs may be mapped to different carriers by mapping a QoS flow or DRB to a LCH on a specific carrier.

[0279] FIG. 8B illustrates a schematic diagram 800B illustrating another example transmission via an LCH on a specific carrier according to embodiments of the present disclosure. As shown in FIG. 8B, packets 821 and 822 are associated with QoS flow 1, and packets 823 and 824 are associated with QoS flow 2. The packets 821 and 822 of QoS flow 1 may be mapped to LCH 1 on an MN, and packets 823 and 824 of QoS flow 2 may be mapped to LCH 2 on an SN. Alternatively, the packets 823 and 824 of QoS flow 2 may be  mapped to both LCH 1 and LCH 2.

[0280] In these embodiments, the terminal device 110 may also apply the logical channel mapping restrictions in an MAC entity that the LCHs of the radio bearer are sent on a same carrier. For example, if CA and a DRB / QoS flow mapping to a logical channel on a specific carrier are configured, logical channel mapping restrictions are used in a MAC entity to ensure that the logical channels of a radio bearer in the MAC entity are sent on the same (or indicated) carrier.

[0281] In this way, packets of different QoS flows may be submitted to different RLC entities on different carriers. By mapping packets of a QoS flow to a specific carrier, a reliable transmission may be guaranteed, and a latency for more important data packets may be reduced.

[0282] So far, transmission of data via an LCH on a specific carrier is described. By mapping data packets to a specific carrier, a reliable transmission may be guaranteed, and a latency for more important data packets may be reduced.

[0283] 3. CARRIER SELECTION BASED ON COMMUNICATION SCHEME

[0284] FIG. 9 illustrates a schematic diagram illustrating a still another process 900 of transmitting data according to embodiments of the present disclosure. For the purpose of discussion, the process 900 will be described with reference to FIG. 1. The process 900 may involve the terminal device 110 and the network device 120 as illustrated in FIG. 1. Of course, the process 900 may also be applied to the terminal device 111 and the network device 120. It is to be understood that the steps and the order of the steps in FIG. 9 are merely for illustration, and not for limitation. For example, the order of the steps may be changed. Some of the steps may be omitted or any other suitable additional steps may be added.

[0285] As shown in FIG. 9, the terminal device 110 may determine 910 that carriers are configured for the terminal device 110. In some embodiments, the carriers may comprise a carrier in a licensed band and a carrier in an unlicensed band. For example, the carrier in the licensed band may be a NR or LTE carrier, and the carrier in the unlicensed band may be a NR-U carrier or a carrier on a shared spectrum.

[0286] In some embodiments, the carriers may comprise a carrier based on a first communication protocol and a carrier based on a second communication protocol. In some embodiments, the first communication protocol may be a 3GPP connection, and the carrier based on the 3GPP connection may be a carrier in a licensed band or a carrier in an unlicensed  band. In some embodiments, the second communication protocol may be a non-3GPP connection, and the carrier based on the non-3GPP connection may be a carrier in WiFi, Bluetooth, or wire connection.

[0287] With reference to FIG. 9, if there is synchronous data to be transmitted, the terminal device 110 may transmit 920 the synchronous data to the network device 120 via one of the configured carriers.

[0288] Continuing to refer to FIG. 9, in some embodiments where the carriers comprise the carrier in the licensed band and the carrier in the unlicensed band, the network device 120 may transmit 921, to the terminal device 110, a configuration (for convenience, also referred to as a first configuration herein) for transmission of the synchronous data under licensed and unlicensed bands.

[0289] In some embodiments, the first configuration may indicate the one of the carriers. In other words, the first configuration may indicate on which carrier (e.g., primary cell (PCell) ) packets (e.g., PDU, or PDU set) or QoS flows or DRBs or importance values to be synchronized shall be transmitted.

[0290] In some embodiments, the first configuration may indicate an LCH or a RLC bearer for transmitting the synchronous data. In other words, the first configuration may indicate on which LCH or RLC bearer (e.g., primary LCH or RLC bearer) packets (e.g., PDU, or PDU set) or QoS flows or DRBs or importance values to be synchronized shall be transmitted.

[0291] In some embodiments, the first configuration may comprise an indication that packets with an importance value in the synchronous data are mapped to the one of the carriers. In other words, packets (e.g., PDU set) with different importance values may be mapped to different carriers to provide reliable connection or lower latency for more important packets, for example, by mapping a QoS flow or an importance value to an LCH on a specific carrier.

[0292] Based on the first configuration, the terminal device 110 may determine one of the carrier in the licensed band and the carrier in the unlicensed band, and transmit 921 the synchronous data via the determined carrier. In some embodiments, the carrier in the licensed band may be indicated in the first configuration as it may guarantee synchronization or a shorter latency.

[0293] In other words, for CA or dual connectivity (DC) between a licensed band and an unlicensed band, QoS flows, DRBs, importance values or packets or PDU sets which require  synchronization may be submitted to only one of the connections, i.e., to the same connection (for example, only be submitted to a licensed band NR / LTE carrier / cell) .

[0294] FIG. 10A illustrates a schematic diagram 1000A illustrating an example transmission via a licensed or unlicensed carrier according to embodiments of the present disclosure. As shown in FIG. 10A, both a NR or LTE carrier and an unlicensed carrier may be configured for the terminal device 110. Packets or QoS flows or DRBs or importance values to be synchronized may be transmitted on the same carrier, e.g., a NR or LTE carrier.

[0295] In this way, if a licensed band carrier and an unlicensed band carrier co-exist between a terminal device and a network device, data that requires synchronization or important data may be submitted to only one of the carriers (i.e., to the same connection) . Thus, a delay caused by different connections may be avoided. More important packets may be transmitted on a connection which provides higher reliability or shorter latency.

[0296] Continuing to refer to FIG. 9, in some embodiments where the carriers comprise the carrier based on the first communication protocol and the carrier based on the second communication protocol, the network device 120 may transmit 923, to the terminal device 110, a configuration (for convenience, also referred to as a second configuration herein) for transmission of the synchronous data under multiple communication protocols.

[0297] In some embodiments, the second configuration may comprise an indication indicating whether the synchronous data is transmitted on the one of the carriers. In other words, the second configuration may indicate whether packets (e.g., PDU, or PDU set) to be synchronized shall be transmitted on the same carrier (e.g., 3GPP carrier) .

[0298] In some embodiments, the second configuration may indicate data streams, QoS flows or an importance value associated with the one of the carriers. In other words, the second configuration may indicate data streams or QoS flows or importance values to be synchronized that shall be transmitted on the same carrier (e.g., 3GPP carrier) .

[0299] In some embodiments, the second configuration may comprise an indication that packets with an importance value in the synchronous data are mapped to the one of the carriers. In other words, more important packets may be configured to be transmitted on a more reliable connection or carrier by mapping the data streams / QoS flows / packets to a specific connection / carrier.

[0300] Continuing to refer to FIG. 9, based on the second configuration, the terminal device 110 may determine one of the carrier based on the first communication protocol and the  carrier based on the second communication protocol, and transmit 924 the synchronous data via the determined carrier. In some embodiments, a carrier in a 3GPP connection may be indicated in the second configuration as it may guarantee synchronization or a shorter latency.

[0301] In other words, if both 3GPP connection and non-3GPP connection co-exist between a terminal device and a network device, the network device may configure the packets or data flows / QoS flows that should be synchronized to be transmitted on the same connection (e.g., 3GPP carrier) , and hence guarantee a synchronous transmission of multi-modal data.

[0302] FIG. 10B illustrates a schematic diagram 1000B illustrating an example transmission via 3GPP or non-3GPP network according to embodiments of the present disclosure. As shown in FIG. 10B, both a NR or LTE carrier and a non-3GPP network may be configured for the terminal device 110. Packets or QoS flows or DRBs or importance values to be synchronized may be transmitted on the same carrier, e.g., a NR or LTE carrier.

[0303] In this way, if a 3GPP connection and a non-3GPP connection co-exist between a terminal device and a network device, data that requires synchronization or important data may be submitted to only one of the carriers (i.e., to the same connection) . Thus, a delay caused by different connections may be avoided. More important packets may be transmitted on a connection which provides higher reliability or shorter latency.

[0304] So far, solutions of transmitting synchronous data are described. It is to be understood that operations in the processes 200, 500, 700 and 900 may be carried out separately or in any suitable combination.

[0305] EXAMPLE IMPLEMENTATION OF METHODS

[0306] Corresponding to the above processes, embodiments of the present disclosure provide methods of communication implemented at a terminal device and at a network device. These methods will be described below with reference to FIGs. 11 to 15.

[0307] FIG. 11 illustrates an example method 1100 of communication implemented at a terminal device in accordance with some embodiments of the present disclosure. For example, the method 1100 may be performed at the terminal device 110 as shown in FIG. 1. For the purpose of discussion, in the following, the method 1100 will be described with reference to FIG. 1. It is to be understood that the method 1100 may include additional blocks not shown and / or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

[0308] At block 1110, the terminal device 110 determines that a first packet in a first data stream and a second packet in a second data stream are to be synchronized.

[0309] In some embodiments, if the first packet and the second packet are associated with an identity of a group to be synchronized, the terminal device 110 may determine that the first packet and the second packet are to be synchronized. In some embodiments, if the first packet and the second packet fall within a time window, the terminal device 110 may determine that the first packet and the second packet are to be synchronized. In some embodiments, if a difference between a timestamp associated with the first packet and a timestamp associated with the second packet is below a threshold difference, the terminal device 110 may determine that the first packet and the second packet are to be synchronized.

[0310] At block 1120, the terminal device 110 performs a synchronization of the first packet and the second packet based on at least one of the following: a mapping between data streams and QoS flows, a mapping between packets and QoS flows, a mapping between packets and PDU sets, a mapping between packets and LCHs, a mapping between packets and importance values, or a mapping between packets and sub-LCHs.

[0311] In some embodiments, the terminal device 110 may transmit, to the network device 120, information indicating at least one of the following: terminal devices to be synchronized, QoS flows to be synchronized, DRBs to be synchronized, LCHs or LCGs to be synchronized, importance values to be synchronized, or information of a group of packets or data streams to be synchronized.

[0312] In some embodiments where the information indicates the LCHs or LCGs to be synchronized, the terminal device 110 may transmit, to the network device 120, a BSR comprising at least one of the following: a buffer size of the LCHs or LCGs, or identities of the LCHs or LCGs. In some embodiments, if the buffer size of the LCHs or LCGs is above a threshold size, the terminal device 110 may transmit the BSR.

[0313] In some embodiments, the terminal device 110 may receive, from the network device 120, an indication of an uplink grant for transmitting synchronous data on the LCHs or LCGs, and transmit the synchronous data via the uplink grant. In some embodiments, the terminal device 110 may receive, from the network device 120, an indication that the LCHs or LCGs are multiplexed with a high priority, and multiplex synchronous data on the LCHs or LCGs with the high priority during an LCP procedure.

[0314] In some embodiments, the terminal device 110 may transmit, to the network device  120, capability of the terminal device 120 indicating at least one of the following: whether the terminal device supports a multi-modal service for the synchronization; whether the terminal device supports a synchronized transmission among QoS flows, terminal devices, DRBs, LCHs or importance values; whether the terminal device supports a list of sub-LCHs; or maximum number of sub-LCHs supported by the terminal device.

[0315] In some embodiments, the terminal device 110 may transmit, to the network device 120, information of QoE measurement comprising: a synchronization loss rate for QoS flows, a synchronization delay among QoS flows, or a jitter among QoS flows.

[0316] In some embodiments, the terminal device 110 may receive, from the network device 120, a configuration comprising at least one of the following: an indication indicating whether a multi-modal service for the synchronization is enabled, a group of packets or data streams or terminal devices to be synchronized, the group of packets or data streams or terminal devices being associated with at least one of a LCH, a DRB or a QoS flow; a list of sub-LCHs belonging to the LCH or the DRB that are transmitted synchronously; or an importance value associated with the LCH or a sub-LCH in the list of sub-LCHs.

[0317] In some embodiments, the terminal device 110 may map the first data stream and the second data stream to a QoS flow, map the first packet to a first PDU or a first PDU set with a first importance value and the second packet to a second PDU or a second PDU set with a second importance value, and map the first PDU or the first PDU set to an LCH or a sub-LCH associated with the first importance value and the second PDU or the second PDU set to an LCH or a sub-LCH associated with the second importance value.

[0318] In some embodiments, the terminal device 110 may map the first packet and the second packet to a PDU set, the PDU set being associated with an importance value, and map the PDU set to an LCH or a sub-LCH associated with the importance value.

[0319] In some embodiments, the terminal device 110 may map the first packet and the second packet to a PDU set, the first packet being associated with a first importance value, the second packet being associated with a second importance value; and map the first packet in the PDU set to an LCH or a sub-LCH associated with the first importance value and the second packet in the PDU set to an LCH or a sub-LCH associated with the second importance value.

[0320] In some embodiments, the terminal device 110 may map the first packet and the second packet to a QoS flow, the QoS flow carrying only packets with synchronization  requirement; and map the QoS flow to an LCH or a sub-LCH associated with the QoS flow.

[0321] In some embodiments, the terminal device 110 may map the first data stream and the second data stream to a first QoS flow and a second QoS flow respectively; map the first QoS flow and the second QoS flow to a first DRB and a second DRB respectively; map the first DRB and the second DRB to a first LCH and a second LCH respectively; and multiplex the first LCH and the second LCH together or with a same priority during an LCP procedure.

[0322] In some embodiments, if the first LCH and the second LCH are to be transmitted synchronously, the terminal device 110 may multiplex the first LCH and the second LCH together or with a same priority. In some embodiments, if the first LCH and the second LCH are associated with an identity of a group to be synchronized, the terminal device 110 may multiplex the first LCH and the second LCH together or with a same priority.

[0323] In some embodiments, the terminal device 110 may map the first data stream and the second data stream to a first QoS flow and a second QoS flow respectively; map the first QoS flow and the second QoS flow to a DRB, the first packet and the second packet being mapped to a PDU set by a PDCP or SDAP entity; and map the first QoS flow and the second QoS flow to a first LCH or sub-LCH associated with the first QoS flow and a second LCH or sub-LCH associated with the second QoS flow; and multiplex the first LCH or sub-LCH and the second LCH or sub-LCH together or with a same priority during an LCP procedure.

[0324] In some embodiments, if the first LCH or sub-LCH and the second LCH or sub-LCH are to be transmitted synchronously, the terminal device 110 may multiplex the first LCH or sub-LCH and the second LCH or sub-LCH together or with a same priority. In some embodiments, if the first LCH or sub-LCH and the second LCH or sub-LCH are associated with an identity of a group to be synchronized, the terminal device 110 may multiplex the first LCH or sub-LCH and the second LCH or sub-LCH together or with a same priority.

[0325] With the method 1100, coordination or synchronization of multi-modal data may be achieved.

[0326] FIG. 12 illustrates an example method 1200 of communication implemented at a network device in accordance with some embodiments of the present disclosure. For example, the method 1200 may be performed at the network device 120 as shown in FIG. 1. For the purpose of discussion, in the following, the method 1200 will be described with reference to FIG. 1. It is to be understood that the method 1200 may include additional  blocks not shown and / or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

[0327] At block 1210, the network device 120 determines a configuration comprising at least one of the following: an indication indicating whether a multi-modal service for packet synchronization is enabled; a group of packets or data streams or terminal devices to be synchronized, the group of packets or data streams or terminal devices being associated with at least one of an LCH, a DRB or a QoS flow; a list of sub-LCHs belonging to the LCH or the DRB that are transmitted synchronously; or an importance value associated with the LCH or a sub-LCH in the list of sub-LCHs.

[0328] At block 1220, the network device 120 transmits the configuration to the terminal device 110.

[0329] In some embodiments, the network device 120 may receive, from the terminal device 110, information indicating at least one of the following: terminal devices to be synchronized; QoS flows to be synchronized; DRBs to be synchronized; LCHs or LCGs to be synchronized; importance values to be synchronized; or information of a group of packets or data streams to be synchronized.

[0330] In some embodiments where the information indicates the LCHs or LCGs to be synchronized, the network device 120 may receive the information by receiving, from the terminal device 110, a BSR comprising at least one of the following: a buffer size of the LCHs or LCGs; or identities of the LCHs or LCGs. In some embodiments, the BSR is transmitted upon the buffer size of the LCHs or LCGs being above a threshold size. In some embodiments, the network device 120 may transmit, to the terminal device 110, an indication of an uplink grant for transmitting synchronous data on the LCHs or LCGs. In some embodiments, the network device 120 may transmit, to the terminal device 110, an indication that the LCHs or LCGs are multiplexed with a high priority.

[0331] In some embodiments, the network device 120 may receive, from the terminal device 110, capability of the terminal device 110 indicating at least one of the following: whether the terminal device 110 supports a multi-modal service for the synchronization; whether the terminal device 110 supports a synchronized transmission among QoS flows, terminal devices, DRBs, LCHs or importance values; whether the terminal device 110 supports a list of sub-LCHs; or maximum number of sub-LCHs supported by the terminal device 110.

[0332] In some embodiments, the network device 120 may receive, from the terminal device 100, information of QoE measurement comprising: a synchronization loss rate for QoS flows, a synchronization delay among QoS flows, or a jitter among QoS flows.

[0333] With the method 1200, coordination or synchronization of multi-modal data may be facilitated, and a network configuration may be optimized.

[0334] FIG. 13 illustrates another example method 1300 of communication implemented at a terminal device in accordance with some embodiments of the present disclosure. For example, the method 1300 may be performed at the terminal device 110 as shown in FIG. 1. For the purpose of discussion, in the following, the method 1300 will be described with reference to FIG. 1. It is to be understood that the method 1300 may include additional blocks not shown and / or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

[0335] At block 1310, the terminal device 110 determines that transmission of synchronous data under a split bearer is configured. At block 1320, the terminal device 110 determines that the synchronous data is to be transmitted.

[0336] At block 1330, the terminal device 110 determines an entity from a plurality of entities for the split bearer. In some embodiments, the entity may be a primary RLC entity. In some embodiments, the entity may be a secondary RLC entity.

[0337] At block 1340, the terminal device 110 transmits, to the network device 120, the synchronous data via the entity.

[0338] In some embodiments, the synchronous data is associated with a plurality of QoS flows. In these embodiments, the terminal device 110 may receive, from the network device 120, a configuration indicating the entity associated with the plurality of QoS flows, and determine the entity based on the configuration. In these embodiments, the terminal device 110 may submit, to the entity, PDUs belonging to the plurality of QoS flows upon a split transmission based on the split bearer.

[0339] In some embodiments, the synchronous data may be associated with a PDU set. In these embodiments, the terminal device 110 may receive, from the network device 120, a configuration indicating the entity associated with the PDU set, and determine the entity based on the configuration. In these embodiments, the terminal device 110 may submit, to the entity, PDUs in the PDU set upon a split transmission based on the split bearer.

[0340] In some embodiments, the synchronous data may be associated with a plurality of importance values. In these embodiments, the terminal device 110 may receive, from the network device 120, a configuration indicating the entity associated with the plurality of importance values, and determine the entity based on the configuration. In these embodiments, the terminal device 110 may submit, to the entity, PDUs associated with the plurality of importance values upon a split transmission based on the split bearer.

[0341] In some embodiments, the terminal device 110 may determine a first data volume on the plurality of entities and determine a second data volume on the determined entity. Then the terminal device 110 may determine a data volume on a set of entities unselected for transmission of the synchronous data by the first data volume minus the second data volume.

[0342] With the method 1300, data that requires synchronization may be submitted to the same RLC entity when split transmission happens and thus synchronous transmission of multi-modal data may be guaranteed.

[0343] FIG. 14 illustrates another example method 1400 of communication implemented at a terminal device in accordance with some embodiments of the present disclosure. For example, the method 1400 may be performed at the terminal device 110 as shown in FIG. 1. For the purpose of discussion, in the following, the method 1400 will be described with reference to FIG. 1. It is to be understood that the method 1400 may include additional blocks not shown and / or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

[0344] At block 1410, the terminal device 110 determines that LCHs are configured for a radio bearer. At block 1420, the terminal device 110 determines that data is to be transmitted.

[0345] At block 1430, the terminal device 110 maps the data to carriers of the LCHs based on importance values or QoS flows associated with the data.

[0346] In some embodiments, the terminal device 110 may receive, from the network device 120, a configuration indicating a mapping between the importance values and the LCHs. Based on the configuration, the terminal device 110 may map a first set of packets of the data having a first importance value to a first carrier of a first LCH corresponding to the first importance value and a second set of packets of the data having a second importance value to a second carrier of a second LCH corresponding to the second importance value. In these embodiments, the terminal device 110 may apply a restriction in a MAC entity that  the LCHs of the radio bearer are sent on a same carrier.

[0347] In some embodiments, the terminal device 110 may receive, from the network device 120, a configuration indicating a mapping between the QoS flows and the LCHs. Based on the configuration, the terminal device 110 may map a first QoS flow of the synchronous data to a third carrier of a third LCH corresponding to the first QoS flow and a second QoS flow of the data to a fourth carrier of a fourth LCH corresponding to the second QoS flow. In these embodiments, the terminal device 110 may apply a restriction in a MAC entity that the LCHs of the radio bearer are sent on a same carrier.

[0348] With the method 1400, packets with different importance values or QoS flows may be submitted to different RLC entities on different carriers. By mapping packets to a specific carrier, a reliable transmission may be guaranteed, and latency for more important data may be reduced.

[0349] FIG. 15 illustrates another example method 1500 of communication implemented at a terminal device in accordance with some embodiments of the present disclosure. For example, the method 1500 may be performed at the terminal device 110 as shown in FIG. 1. For the purpose of discussion, in the following, the method 1500 will be described with reference to FIG. 1. It is to be understood that the method 1500 may include additional blocks not shown and / or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

[0350] At block 1510, the terminal device 110 determines that carriers are configured for the terminal device. At block 1520, the terminal device 110 determines that synchronous data is to be transmitted.

[0351] At block 1530, the terminal device 110 transmits, to the network device 120, the synchronous data via one of the carriers.

[0352] In some embodiments, the carriers may comprise a carrier in a licensed band and a carrier in an unlicensed band. In these embodiments, the terminal device 110 may receive, from the network device 120, a configuration indicating at least one of the following: the one of the carriers, a logical channel or a radio link control bearer for transmitting the synchronous data, or an indication that packets with an importance value in the synchronous data are mapped to the one of the carriers. Based on the configuration, the terminal device 110 may transmit the synchronous data.

[0353] In some embodiments, the carriers may comprise a carrier based on a first  communication protocol and a carrier based on a second communication protocol. In these embodiments, the terminal device 110 may receive, from the network device 120, a configuration indicating at least one of the following: an indication indicating whether the synchronous data is transmitted on the one of the carriers; data streams, quality of service flows or an importance value associated with the one of the carriers; or an indication that packets with an importance value in the synchronous data are mapped to the one of the carriers. Based on the configuration, the terminal device 110 may transmit the synchronous data.

[0354] With the method 1500, data that requires synchronization or important data may be submitted to the same connection, and thus a delay caused by different connections may be avoided. In addition, more important packets may be transmitted on a connection which provides higher reliability or shorter latency.

[0355] It is to be understood that operations of the methods 1100 to 1500 correspond to the processes described in connection with FIGs. 2 to 10B, and thus other details are omitted here for conciseness.

[0356] EXAMPLE IMPLEMENTATION OF DEVICES

[0357] FIG. 16 is a simplified block diagram of a device 1600 that is suitable for implementing embodiments of the present disclosure. The device 1600 can be considered as a further example implementation of the terminal device 110 or the network device 120 as shown in FIG. 1A. Accordingly, the device 1600 can be implemented at or as at least a part of the terminal device 110 or the network device 120.

[0358] As shown, the device 1600 includes a processor 1610, a memory 1620 coupled to the processor 1610, a suitable transceiver 1640 coupled to the processor 1610, and a communication interface coupled to the transceiver 1640. The memory 1610 stores at least a part of a program 1630. The transceiver 1640 may be for bidirectional communications or a unidirectional communication based on requirements. The transceiver 1640 may include at least one of a transmitter 1642 or a receiver 1644. The transmitter 1642 and the receiver 1644 may be functional modules or physical entities. The transceiver 1640 has at least one antenna to facilitate communication, though in practice an Access Node mentioned in this application may have several ones. The communication interface may represent any interface that is necessary for communication with other network elements, such as X2 / Xn interface for bidirectional communications between eNBs / gNBs, S1 / NG interface for  communication between a Mobility Management Entity (MME)  / Access and Mobility Management Function (AMF)  / SGW / UPF and the eNB / gNB, Un interface for communication between the eNB / gNB and a relay node (RN) , or Uu interface for communication between the eNB / gNB and a terminal device.

[0359] The program 1630 is assumed to include program instructions that, when executed by the associated processor 1610, enable the device 1600 to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to FIGs. 1 to 15. The embodiments herein may be implemented by computer software executable by the processor 1610 of the device 1600, or by hardware, or by a combination of software and hardware. The processor 1610 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 1610 and memory 1620 may form processing means 1650 adapted to implement various embodiments of the present disclosure.

[0360] The memory 1620 may be of any type suitable to the local technical network and may be implemented using any suitable data storage technology, such as a non-transitory computer readable storage medium, semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. While only one memory 1620 is shown in the device 1600, there may be several physically distinct memory modules in the device 1600. The processor 1610 may be of any type suitable to the local technical network, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1600 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0361] In some embodiments, a terminal device comprises a circuitry configured to: determine that a first packet in a first data stream and a second packet in a second data stream are to be synchronized; and perform synchronization of the first packet and the second packet based on at least one of the following: a mapping between data streams and QoS flows, a mapping between packets and QoS flows, a mapping between packets and PDU sets, a mapping between packets and LCHs, a mapping between packets and importance values, or a mapping between packets and sub-LCHs..

[0362] In some embodiments, a network device comprises a circuitry configured to: determine a configuration indicating at least one of the following: an indication indicating whether a multi-modal service for packet synchronization is enabled, a group of packets or data streams or terminal devices to be synchronized, the group of packets or data streams or terminal devices being associated with at least one of an LCH, a DRB or a QoS flow, a list of sub-LCHs belonging to the LCH or the DRB that are transmitted synchronously, or an importance value associated with the LCH or a sub-LCH in the list of sub-LCHs; and transmit the configuration to a terminal device.

[0363] In some embodiments, a terminal device comprises a circuitry configured to: determine that transmission of synchronous data under a split bearer is configured; in accordance with a determination that the synchronous data is to be transmitted, determine an entity from a plurality of entities for the split bearer; and transmit, to a network device, the synchronous data via the entity.

[0364] In some embodiments, a terminal device comprises a circuitry configured to: determine that LCHs are configured for a radio bearer; and in accordance with a determination that data is to be transmitted, map the data to carriers of the LCHs based on importance values or QoS flows associated with the data.

[0365] In some embodiments, a terminal device comprises a circuitry configured to: determine that carriers are configured for the terminal device; and in accordance with a determination that synchronous data is to be transmitted, transmit, to a network device, the synchronous data via one of the carriers.

[0366] The term “circuitry” used herein may refer to hardware circuits and / or combinations of hardware circuits and software. For example, the circuitry may be a combination of analog and / or digital hardware circuits with software / firmware. As a further example, the circuitry may be any portions of hardware processors with software including digital signal processor (s) , software, and memory (ies) that work together to cause an apparatus, such as a terminal device or a network device, to perform various functions. In a still further example, the circuitry may be hardware circuits and or processors, such as a microprocessor or a portion of a microprocessor, that requires software / firmware for operation, but the software may not be present when it is not needed for operation. As used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (s) or a portion of a hardware circuit or processor (s) and its (or their) accompanying software and / or firmware.

[0367] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0368] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method as described above with reference to FIGs. 1 to 15. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0369] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0370] The above program code may be embodied on a machine readable medium, which may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A  machine readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0371] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0372] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1.A terminal device, comprising:a processor configured to cause the terminal device to:determine that transmission of synchronous data under a split bearer is configured;in accordance with a determination that the synchronous data is to be transmitted, determine an entity from a plurality of entities for the split bearer; andtransmit, to a network device, the synchronous data via the entity.2.The terminal device of claim 1, wherein the entity is a primary or secondary radio link control (RLC) entity.3.The terminal device of claim 1, wherein the synchronous data is associated with a plurality of quality of service (QoS) flows, wherein the terminal device is caused to determine the entity by:receiving, from the network device, a configuration indicating the entity associated with the plurality of QoS flows; anddetermining the entity based on the configuration.4.The terminal device of claim 3, wherein the terminal device is caused to transmit the entity by:submitting, to the entity, protocol data units (PDUs) belonging to the plurality of QoS flows upon a split transmission based on the split bearer.5.The terminal device of claim 1, wherein the synchronous data is associated with a protocol data unit (PDU) set and wherein the terminal device is caused to determine the entity by:receiving, from the network device, a configuration indicating the entity associated with the PDU set; anddetermining the entity based on the configuration.6.The terminal device of claim 5, wherein the terminal device is caused to transmit the entity by:submitting, to the entity, PDUs in the PDU set upon a split transmission based on the split bearer.7.The terminal device of claim 1, wherein the synchronous data is associated with a plurality of importance values and wherein the terminal device is caused to determine the entity by:receiving, from the network device, a configuration indicating the entity associated with the plurality of importance values; anddetermining the entity based on the configuration.8.The terminal device of claim 7, wherein the terminal device is caused to transmit the entity by:submitting, to the entity, PDUs associated with the plurality of importance values upon a split transmission based on the split bearer.9.The terminal device of claim 1, wherein the terminal device is further caused to:determine a first data volume on the plurality of entities;determine a second data volume on the determined entity; anddetermine a data volume on a set of entities unselected for transmission of the synchronous data by the first data volume minus the second data volume.10.A terminal device, comprising:a processor configured to cause the terminal device to:determine that logical channels (LCHs) are configured for a radio bearer; andin accordance with a determination that data is to be transmitted, map the data to carriers of the LCHs based on importance values or quality of service (QoS) flows associated with the data.11.The terminal device of claim 10, wherein the terminal device is caused to map the synchronous data based on the importance values by:receiving, from a network device, a configuration indicating a mapping between the importance values and the LCHs; andmapping, based on the configuration, a first set of packets of the data having a first importance value to a first carrier of a first LCH corresponding to the first importance value and a second set of packets of the data having a second importance value to a second carrier of a second LCH corresponding to the second importance value.12.The terminal device of claim 10, wherein the terminal device is caused to map the synchronous data based on the QoS flows by:receiving, from a network device, a configuration indicating a mapping between the QoS flows and the LCHs; andmapping, based on the configuration, a first QoS flow of the data to a third carrier of a third LCH corresponding to the first QoS flow and a second QoS flow of the data to a fourth carrier of a fourth LCH corresponding to the second QoS flow.13.The terminal device of claim 11 or 12, wherein the terminal device is further caused to:apply a restriction in a medium access control (MAC) entity that the LCHs of the radio bearer are sent on a same carrier.14.A terminal device, comprising:a processor configured to cause the terminal device to:determine that carriers are configured for the terminal device; andin accordance with a determination that synchronous data is to be transmitted, transmit, to a network device, the synchronous data via one of the carriers.15.The terminal device of claim 14, wherein the carriers comprise a carrier in a licensed band and a carrier in an unlicensed band.16.The terminal device of claim 15, wherein the terminal device is caused to transmit the synchronous data by:receiving, from the network device, a configuration indicating at least one of the following:the one of the carriers,a logical channel or a radio link control bearer for transmitting the synchronous data, oran indication that packets with an importance value in the synchronous data are mapped to the one of the carriers; andtransmitting the synchronous data based on the configuration.17.The terminal device of claim 14, wherein the carriers comprise a carrier based on a first communication protocol and a carrier based on a second communication protocol.18.The terminal device of claim 17, wherein the terminal device is caused to transmit the synchronous data by:receiving, from the network device, a configuration indicating at least one of the following:an indication indicating whether the synchronous data is transmitted on the one of the carriers,data streams, quality of service flows or an importance value associated with the one of the carriers, oran indication that packets with an importance value in the synchronous data are mapped to the one of the carriers; andtransmitting the synchronous data based on the configuration.

Images