Patent Description:
Currently, there are many wireless communication technologies that may be used to communicate between two communication devices. In certain scenarios, communication of data packets between two communication devices may be interrupted or may suffer data loss, experience low-throughput, and/or latency. For example, one communication device may move beyond a communication range of the other communication device in a device-to-device communication causing interruptions in data communication. In another example, a cellular communication may be used to communicate between the two communication devices. Typically, a cellular network provides a larger coverage area as compared to the device-to-device communication. However, sequence numbers of the data packets received via uplink and downlink in cellular communication may be different or the data packets may be disarranged, thereby resulting in data to be erroneous. Thus, the receipt of data packets at a destination device may be unreliable, inefficient, or may be delayed. Generally, the next generation services (e.g. vehicle-to-everything services) have demanding quality-of-service requirements, which may be challenging to meet using conventional methods and systems of wireless communication.

Therefore, in light of the foregoing discussion, there exists a need to overcome the aforementioned drawbacks associated with conventional systems and methods for wireless communication of data packets.

<CIT> Al describes multi-path wireless communication.

<CIT> Al describes multiple path reactive routing in a mobile ad hoc network.

This invention is defined by the appended claims. The present disclosure seeks to provide a method, a device and a computer program product for executing multipath communication. The present disclosure seeks to provide a solution to the existing problem of inefficient and unreliable wireless communication of data between at least two communication devices. An aim of the present disclosure is to provide a solution that overcomes at least partially the problems encountered in prior art, and provides improved methods and devices that are able to efficiently and reliably communicate data packets.

The object of the present disclosure is achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims.

In a first aspect, the present disclosure provides a method for executing multipath communication at a network entity. The method comprises obtaining, from a source communication device, a first set of data packets, wherein a header of each data packet of the first set of data packets comprises packet information. The packet information is indicative of an association among the first set of data packets. The method further comprises mapping an uplink sequence number to a downlink sequence number for each data packet of the received first set of data packets based on the packet information, and providing each received data packet of the first set of data packets that includes the packet information to at least one of a target communication device or a further network entity based on the mapped uplink sequence number to the downlink sequence number.

The mapping of the uplink sequence number to a downlink sequence number for each data packet of the first set of data packets addresses the data packets disarrangement issues. As a result of the mapping, there is no need to apply the conventional sequence number derivation method for the downlink data packets. Moreover, based on the packet information and the mapping, the method enables an end-to-end tracking and correlation of the first set of data packets obtained from the source communication device, and further provided to the target communication device or the further network entity (e.g. another radio access network node or a core network entity).

The uplink sequence number is received in a specified network layer from the source communication device, and wherein the uplink sequence number is mapped to the downlink sequence number in the specified network layer. The specified network layer is at least one of a Packet Data Convergence Protocol (PDCP) layer, a Service Data Adaptation Protocol (SDAP) layer, or other network layer.

The uplink sequence number in the specified network layer (e.g. uplink PDCP sequence number) is retained and mapped to the downlink sequence number in the specified network layer (e.g. downlink PDCP sequence number), which addresses the data packets disarrangement issues, and ensures correct ordering of such data packets.

In a first implementation form of the first aspect, the method further comprises appending, by the network entity, the uplink sequence number received from the source communication device in a core network protocol-based header of each received data packet of the first set of data packets. The method further comprises communicating, by the network entity, each received data packet of the first set of data packets having the core network protocol-based header that includes the appended uplink SN to the core network entity, wherein the core network protocol-based header that includes the appended uplink sequence number is a modified core network protocol-based header that includes the appended uplink sequence number as an extension in a header structure of the core network protocol-based header.

In order to address disarrangement issues of data packets and allow the target communication device to be able to compare data packets transmitted via the first path with the second path, the core network protocol-based header of each data packet obtained by the network entity (i.e. source network entity) is appended with the uplink sequence number obtained from the source communication device.

In a second implementation form of the first aspect, the core network protocol-based header is a General Packet Radio Service (GPRS) Tunnelling Protocol User plane (GTP-U) header.

In conventional systems, sequence numbers of the data packets received via uplink and downlink in a cellular communication is potentially different or the data packets potentially becomes disarranged (i.e. incorrectly ordered). Thus, by use of the modified GTP-U header that includes the appended uplink sequence number, the disarrangement issue of data packets is addressed while a data packet travels via a cellular network.

In a third implementation form of the first aspect, the method further comprises setting, by the network entity, the retrieved uplink sequence number as a downlink sequence number in each received data packet of the plurality of data packets prior to a downlink transmission of the received data packets of the first set of data packets to the target communication device.

As the downlink sequence number of each data packet is same as that of the respective uplink sequence number, thus, there is no need to apply the usual sequence number derivation method for the downlink data packets, and a reliable end-to-end tracking of the data packets is ensured throughout the communication process.

In a fourth implementation form of the first aspect, the method further comprises enabling, by the network entity, a multipath function based on an indicator in the header of each data packet of the first set of data packets or in a signalling message transmitted by the source communication device. The enablement of the multipath function includes storing the packet information in each data packet of the first set of data packets received at the network entity and reusing the packet information to further provide each received packet to the target communication device; or routing each data packet of the first set of data packets having the packet information to a further network entity that reuses the packet information to further provide each received packet to the target communication device via the network entity, or another network entity.

In order to allow the target communication device to be able to compare and track data packets transmitted via the first path and the second path, the method enables to activate the multipath function by a per data packet basis by use of the indicator in the header of each data packet or by a session level basis by use of the signalling message.

In a second aspect, the present disclosure provides a network entity for executing a multipath communication. The network entity comprises an entity control circuitry that is configured to obtain, from a source communication device, a first set of data packets, wherein a header of each data packet of the first set of data packets comprises packet information, wherein the packet information is indicative of an association among the first set of data packets. The entity control circuitry is further configured to map an uplink sequence number to a downlink sequence number for each data packet of the received first set of data packets based on the packet information. The entity control circuitry is further configured to provide each received data packet of the first set of data packets that includes the packet information to at least one of a target communication device or a further network entity based on the mapped uplink sequence number to the downlink sequence number.

In further implementation forms of the network entity of the second aspect the control circuit is configured to perform the features of the implementation forms of the method according to the third aspect. Hence, implementation forms of the network entity comprise the feature(s) of the corresponding implementation form of the method of the second aspect.

The network entity of the sixth aspect achieves all the advantages and effects of the method of the third aspect.

In a third aspect, the present disclosure provides a computer program product that comprises a non-transitory computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a computerised device comprising processing hardware to execute the aforementioned method of the first aspect, the second aspect, or the third aspect.

The computer program product of the third aspect achieves all the advantages and effects of the method of the first aspect.

It has to be noted that all devices, elements, circuitry, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof.

<FIG> is a flowchart of a method <NUM> for executing multipath communication at a target communication device, in accordance with an embodiment of the present disclosure. The method <NUM> is executed by a target communication device described, for example, in <FIG>. The method <NUM> includes steps <NUM> and <NUM>.

At step <NUM>, a plurality of data packets is obtained via two or more different paths from a source communication device. Each path of the two or more different path is different from other paths in use of at least a radio access technology, a communication protocol, a radio link, an interface, or a combination thereof. In an example, the two or more different paths may refer to a cellular communication path and a sidelink communication path. In another example, the two or more different paths may refer to different device-to-device communications. A header of each data packet of the plurality of data packets comprises packet information. The packet information is indicative of an association among the plurality of data packets. Alternatively stated, the packet information links the plurality of data packets irrespective of different radio access technologies, communication protocols, or radio links used in the two or more different paths. The packet information in each data packet at the source communication device is the same as the packet information in each data packet at the target device irrespective of different radio access technologies, communication protocols, or radio links used in the two or more different paths. The plurality of data packets includes different data packets having different payload or duplicate data packets having a copy of same payload.

At step <NUM>, a first set of data packets from the plurality of data packets received via a first path and a second set of data packets from the plurality of data packets received via a second path are identified based on the packet information. In an example, the packet information may be a packet identifier (e.g. for a split data packet or a duplicate data packet) or a sequence number that is stored (i.e. maintained) in the header of each data packet of the plurality of data packets irrespective of a path traversed by the plurality of data packets from the source communication device to the target communication device. Such packet information is used to identify which data packets are received from which path of the two or more different paths at the target communication device.

In accordance with an embodiment, one of the first path or the second path corresponds to a device-to-device communication between the source communication device and the target communication device. Alternatively, the first path of the two or more different paths is a cellular communication path and the second path of the two or more different paths is a sidelink communication path that corresponds to the device-to-device communication. Notably, the cellular communication path has different transmission characteristics than the sidelink communication path. For instance, the cellular communication path provides a better signal coverage area than the sidelink communication path, whereas the sidelink communication path reduces latency and increases capacity and network performance through spatial frequency reuse. It is known that the next generation services, such as vehicle-to-everything (V2X) services have demanding Quality of service (QoS) requirements as specified in 3rd Generation Partnership Project (3GPP). Thus, the two or more different paths may be utilized concurrently for data communication in order to achieve the target QoS requirements. Other examples of the first path and the second path are described, for example, in <FIG>.

In accordance with an embodiment, the method <NUM> further comprises filtering, by the target communication device, duplicate data packets from the plurality of data packets received at the target communication device based on the packet information. In a case where the plurality of data packets obtained by the target communication device includes duplicate data packets, the redundant data packets in the first set of data packets or the second set of data packets are removed before final presentation (i.e. output for user consumption) at the target communication device. In an example, the filtering of duplicate data packets is executed at a specific network layer (also referred to as a protocol layer), such as an application layer, a convergence layer (a V2X layer in case of a vehicle), or a packet data convergence protocol (PDCP) layer, of a radio protocol stack in the target communication device.

In accordance with an embodiment, the method <NUM> further comprises reordering, by the target communication device, the plurality of data packets by a sequence number associated with each of the plurality of data packets based on the packet information, where the plurality of data packets includes different data packets obtained via the first path and the second path in a split mode. In a case where the plurality of data packets obtained by the target communication device includes different data packets, the packet information that includes a dedicated sequence number is checked in each data packet and accordingly the plurality of data packets are aligned in a sequential order before final presentation (i.e. output for user consumption) at the target communication device. The first set of data packets received via the first path and the second set of data packets received concurrently via the second path improves data-throughput and reduces latency of data communication.

The steps <NUM> and <NUM> are only illustrative and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

<FIG> is a flowchart of a method <NUM> for executing multipath communication at a source communication device, in accordance with an embodiment of the present disclosure. The method <NUM> is executed by a source communication device described, for example, in <FIG>.

At step <NUM>, a first set of data packets from a plurality of data packets via a first path and a second set of data packets from the plurality of data packets via a second path are provided to a target communication device. Alternatively stated, a multipath communication is executed at the source communication device to provide the plurality of data packets to the target communication device. The multipath communication refers to communication of data via two or more different paths to a common destination device (such as the target communication device in this case), where each path is different from other paths in use of at least a radio access technology, a communication protocol, a radio link, an interface, or a combination thereof, to communicate data. For example, a data item, such as text, audio, video, or other media, or their combination, may be communicated from the source communication device to the target communication device. Such data item is segmented into the plurality of data packets. A header of each data packet of the plurality of data packets includes packet information indicative of an association among the plurality of data packets. For example, the packet information indicates that the plurality of data packets belongs a same data item and further indicates whether a data packet is a duplicate data packet or a split data packet. Alternatively stated, the packet information links the plurality of data packets irrespective of different radio access technologies, communication protocols, or radio links traversed by the first set of data packet and the second set of data packets from the source communication device to the target communication device. The plurality of data packets includes different data packets having different payload (i.e. the split data packets) or duplicate data packets having a copy of same payload. The duplicate data packets and the split data packets are further described, for example, in <FIG> respectively.

In accordance with an embodiment, at least one of the first path or the second path corresponds to a device-to-device communication between the source communication device and the target communication device. For example, the first path may be a cellular communication path and the second path may be a sidelink communication path that corresponds to the device-to-device communication. In a case where the first path is the cellular communication path, the first set of data packets from the plurality of data packets is communicated via a cellular interface (e.g. a Uu interface). In a case where the second path is the sidelink communication path, the second set of data packets of the plurality of data packets are communicated via a sidelink interface (e.g. a PC5 or PC3 interface) or other interfaces configured for device-to-device communication. The source communication device may support both the cellular interface and the sidelink interface. Alternatively, the first path and the second path may refer to different device-to-device communication (e.g. IEEE <NUM>. 11p (also known as dedicated short-range communication (DSRC) or intelligent transport system (ITS)-G5 dedicated to road transport and traffic telematics), Wireless Fidelity (Wi-Fi), Wi-Fi Direct, Long Term evolution (LTE) Direct, <NUM> New Radio (NR) based device-to-device communication, and the like).

In accordance with an embodiment, the method <NUM> further includes selecting, by the source communication device, a duplication mode or a split mode to communicate the plurality of data packets to the target communication device via two or more different paths. The selection of the duplication mode or the split mode occurs before a start of a data session or during a data session. Optionally, one of the duplication mode or the split mode is set as default at the source communication device. Optionally, the selection of the duplication mode or the split mode is made based on a user input provided to the source communication device. Alternatively, the selection is made automatically based on a type or a size of data (or data item) to be communicated. In the duplication mode, duplicate data packets having a copy of same payload are communicated via at least two different paths to ensure that all data packets reliably reach a common destination, such as the target communication device. The duplication mode enables redundancy of radio links that increases reliability of data communication. In the split mode, the plurality of data packets are split into the first set of data packets and the second set of data packets, where each data packet have different payload. Thereafter, the first set of data packets and the second set of data packets are provided from the source communication device to a common destination, such as the target communication device, via at least two different paths to increase throughput and reduce latency.

In accordance with an embodiment, the method <NUM> further includes communicating, by the source communication device, the first set of data packets via the first path to a network entity in an uplink transmission and the second set of data packets via the second path to the target communication device as duplicate data packets based on the selection of the duplication mode. In this case, at least a payload of the first set of data packets is same as the payload of the second set of data packets in the duplication mode. Alternatively, the method <NUM> further includes comprising communicating, by the source communication device, the first set of data packets via the first path to the network entity in an uplink transmission and the second set of data packets via the second path to the target communication device. In this case, a payload of the first set of data packets is different from a payload of the second set of data packets in the split mode. In a case where the first path is the cellular communication path, the first set of data packets is communicated to the network entity, such as a base station, in the uplink transmission. Optionally, the first set of data packets traverses through various network entities, such as a source radio access network node (e.g. the base station), a core network entity, or a target radio access network node, where different types communication protocols are used. This means that different headers and identifiers may be used from one node to another network node. In contrast to conventional methods and systems, the packet information in the header of each data packet of the plurality of data packet is an additional control information that remains unaltered in the header of each data irrespective of different radio access technologies, communication protocols, or radio links used in the first path and the second path, and the different network nodes traversed by the first set of data packets.

In accordance with an embodiment, the header of each data packet of the plurality of data packets or a signalling message transmitted by the source communication device to at least one of a network entity or the target communication device upon establishment or update of the data session includes an indicator. The indicator indicates enablement of a multipath function at network entity or at the target communication device. The signalling message may refer to control plane signalling or other signalling message. In an example, the indicator may be a specific bit value (e.g. bit value "<NUM>") from the binary bit value ("<NUM>" or "<NUM>") which may be set in a data packet in at least one reserve field of a specific network layer (e.g. PDCP layer header) at the source communication device. The specific bit value acts as a flag to signal the network entity or the target communication device that the multipath function is to be enabled. An example of the indicator is further described in <FIG>. The enablement of the multipath function refers to an indication that a specific treatment needs to be provided to the data packets that has the indicator. The specific treatment refers to a configuration change or a network capability which allows storage (or maintenance) of the packet information in the header of each data packet of the plurality of data packets received at the network entity (e.g. a base station) and reusage of the packet information to further provide each received packet to the target communication device.

The steps <NUM> is only illustrative and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

<FIG> is a flowchart of a method <NUM> for executing multipath communication at a network entity, in accordance with an embodiment of the present disclosure. The method <NUM> is executed by a network entity described, for example, in <FIG>. The method <NUM> includes steps <NUM> to <NUM>.

At step <NUM>, a first set of data packets is obtained from a source communication device. For example, the first set of data packets are obtained via the cellular communication path. A header of each data packet of the first set of data packets comprises packet information. The packet information is indicative of an association among the first set of data packets.

At step <NUM>, an uplink sequence number is mapped to a downlink sequence number for each data packet of the received first set of data packets based on the packet information. In accordance with an embodiment, the uplink sequence number is received in a specified network layer from the source communication device. The uplink sequence number is mapped to the downlink sequence number in the specified network layer. The specified network layer is at least one of a PDCP layer, a Service Data Adaptation Protocol (SDAP) layer, or another network layer. In an example, the network entity (such as the source network access node) may be configured to perform mapping of uplink PDCP sequence number with downlink PDCP sequence number in order to address incorrect ordering of data packets and enable the target communication device to compare (or match) data packets received via sidelink communication path with the data packets received via the cellular communication path. Thus, in this case there no need for the network entity (or the target network entity) to apply the conventional PDCP sequence derivation method for the downlink data packets.

At step <NUM>, each received data packet of the first set of data packets that includes the packet information is provided to at least one of a target communication device or a further network entity based on the mapped uplink sequence number to the downlink sequence number.

Optionally, the method <NUM> further includes appending, by the network entity, the uplink sequence number (SN) received from the source communication device in a core network protocol-based header of each received data packet of the first set of data packets. The method further includes communicating, by the network entity, each received data packet of the first set of data packets having the core network protocol-based header that includes the appended uplink SN to a core network entity. The core network protocol-based header that includes the appended uplink SN is a modified core network protocol-based header that includes the appended uplink SN as an extension in a header structure of the core network protocol-based header. Optionally, the core network protocol-based header is a General Packet Radio Service (GPRS) Tunnelling Protocol User Plane (GTP-U) header. An example of the GTP-U header is described, for example, in <FIG>. Alternatively, the first set of data packets may not be forwarded to the core network entity, and may directly be communicated from the network entity to the target communication device in the downlink transmission. Optionally, the first set of data packets may not be forwarded to the core network entity, and but may be forwarded to a further network entity, such as the target radio access node, which then forwards the first set of data packets to the target communication device in the downlink transmission. In such cases, the core network protocol-based header may not be used.

In accordance with an embodiment, the method <NUM> further includes setting, by the network entity, the retrieved uplink SN as a downlink SN in each received data packet of the plurality of data packets prior to a downlink transmission of the received data packets of the first set of data packets to the target communication device.

In accordance with an embodiment, the method <NUM> further includes enabling, by the network entity, a multipath function based on an indicator in the header of each data packet of the first set of data packets or in a signalling message transmitted by the source communication device. An example of the indicator in the header of a data packet is described, for example, in <FIG>. An example of the signalling message(s) in a session is described, for example, in <FIG>. The enablement of the multipath function includes storage (or maintenance) of the packet information in each data packet of the first set of data packets received at the network entity and reusing the packet information to further provide each received packet to the target communication device. Alternatively, the enablement of the multipath function includes routing each data packet of the first set of data packets having the packet information to a further network entity that reuses the packet information to further provide each received packet to the target communication device via the network entity, or another network entity.

The steps <NUM>, <NUM>, and <NUM> are only illustrative and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

<FIG> is a block diagram that illustrates a network environment of a system 400A for executing multipath communication, in accordance with an embodiment of the present disclosure. With reference to <FIG>, there is shown a network environment of the system 400A that includes a source communication device <NUM> and a target communication device <NUM>. There is further shown a first path <NUM> and a second path <NUM>. The source communication device <NUM> and the target communication device <NUM> may be configured to establish communication with each other via two or more different paths, such as the first path <NUM> and the second path <NUM>.

Each of the source communication device <NUM> and the target communication device <NUM> may include suitable logic, circuitry, interfaces and/or code that is configured to communicate (send/receive) data via the two or more different paths. In accordance with an embodiment, each of the source communication device <NUM> and the target communication device <NUM> is at least one of: a vehicle, an electronic device (e.g. an electronic control unit (ECU), an in-vehicle infotainment (IVI) system, or other in-vehicle device) used in a vehicle, or a portable electronic device (e.g. a smart phone, a drone, an Internet-of-Things (IoT) device, a machine type communication (MTC) device, a hand-held computing device, an evolved universal mobile telecommunications system (UMTS) terrestrial radio access (E-UTRAN) NR-dual connectivity (EN-DC) device, or any other customized hardware for wireless telecommunication). The vehicle may be a non-autonomous, a semi-autonomous, or an autonomous vehicle.

The multipath communication refers to communication of data via two or more different paths to a common destination device, where each path is different from other paths in use of at least a radio access technology, a communication protocol, a radio link, an interface, or a combination thereof, to communicate data. Thus, the first path <NUM> is different from the second path <NUM> in use of the radio access technology, one or more communication protocols, the radio link, and/or the interface to communicate data.

In an example, the first path <NUM> may be a cellular communication path (i.e. a cellular network-based communication), whereas the second path <NUM> may be a sidelink communication path (i.e. a device-to-device communication). Examples of the cellular network-based communication includes, but is not limited to <NUM>th generation (<NUM>) or <NUM> NR (e.g. sub <NUM>, cmWave, or mmWave communication), Long term evolution (LTE) <NUM>, <NUM>, or <NUM>. In cases where the source communication device <NUM> or the target communication device <NUM>, is a vehicle or an electronic device used in a vehicle, such cellular network-based communication may be a vehicle-to-network (V2N) communication, which operates, for example, by use of a Uu interface in mobile broadband spectrum. The Uu interface refers to a radio interface between a communication device and a radio access network. In this example, the first path <NUM> uses a cellular network having different radio access technology, communication protocols, radio link, and interface (e.g. the Uu interface) to communicate data, whereas the second path <NUM> uses a device-to-device communication independent of a cellular network. The device-to-device communication improves spectrum utilisation and capacity and enhance network performance and throughput. Examples of the device-to-device communication include, but is not limited to IEEE <NUM>. 11p, Wireless Fidelity (Wi-Fi), Wi-Fi Direct, LTE Direct, an inband device-to-device communication, an outband device-to-device communication, or a proximity-based services (ProSe) based device-to-device communication. The device-to-device communication may be performed in cellular system, which is known as inband device-to-device communication or may occur in unlicensed spectrum, which is known as outband device-to-device communication. The device-to-device communication is a direct communication between the source communication device <NUM> and the target communication device <NUM>, which is potentially implemented via different interfaces (e.g. a PC5 interface, a PC3 interface, or other wireless local area network (WLAN)-based interface).

In another example, the first path <NUM> may employ IEEE <NUM>. 11p, whereas the second path <NUM> may employ a <NUM>-V2X communication or an LTE-V2X (via PC5) communication. In yet another example, the first path <NUM> and the second path <NUM> may employ different device-to-device communication, such as the first path <NUM> may employ LTE PC5, whereas the second path <NUM> may employ NR PC5. In yet another example, the first path <NUM> may employ a Wi-Fi based communication, whereas the second path <NUM> may employ a PC5 interface-based device-to-device communication.

In operation, a user of the source communication device <NUM> may want to communicate data with the target communication device <NUM>. In accordance with an embodiment, the source communication device <NUM> is configured to select a duplication mode or a split mode to communicate a plurality of data packets to the target communication device <NUM> via two or more different paths. The selection of the duplication mode or the split mode occurs before a start of a data session or during a data session. The duplication mode and the split mode is described in details, for example, in <FIG> respectively.

The source communication device <NUM> is further configured to provide, to the target communication device <NUM>, a first set of data packets from the plurality of data packets via the first path <NUM> and a second set of data packets from the plurality of data packets via the second path <NUM>. The plurality of data packets includes different data packets having different payload (e.g. in a case where the split mode is selected) or duplicate data packets having a copy of same payload (e.g. in a case where the duplicate mode is selected). A header of each data packet includes packet information indicative of an association among the plurality of data packets.

Optionally, the source communication device <NUM> is configured to provide the second set of data packets to the target communication device <NUM> via the second path <NUM> in a multi-hop process. For example, even if the target communication device <NUM> moves beyond a specified device-to-device communication range from the source communication device <NUM>, the first set of data packets may traverse through multiple communication devices in device-to-device communication to finally arrive at the destination device, such as the target communication device <NUM>. For example, the source communication device <NUM> is "A" and the target communication device is "D". "B" and "C" are intermediate communication devices. "B" may be in device-to-device communication range from "A" and "C" but not "D". "C" may be in device-to-device communication range from "B" and "D" but not "C". Thus, in such cases, "A" can provide the second set of data packets to "D" in the following manner: A to B to C to D, whereas the "D" due to the large coverage area of the cellular communication, may obtain the first set of data packets via the cellular communication path in a downlink transmission.

The target communication device <NUM> is configured to obtain, from the source communication device <NUM>, the plurality of data packets via the two or more different paths. Notably, the header of each data packet of the plurality of data packets includes packet information. The packet information is indicative of an association among the plurality of data packets. The packet information in each data packet at the source communication device <NUM> is the same as the packet information in each data packet at the target communication device <NUM> irrespective of different radio access technologies, communication protocols, or radio links used in the two or more different paths. The plurality of data packets includes different data packets having different payload or duplicate data packets having a copy of same payload. The target communication device <NUM> is further configured to identify the first set of data packets from the plurality of data packets received via the first path <NUM> and the second set of data packets from the plurality of data packets received via the second path <NUM> based on the packet information.

<FIG> is a block diagram that illustrates data communication via a duplication mode, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>. With reference to <FIG>, there is shown an exemplary scenario 400B to depict data communication in a duplication mode. There is further shown the source communication device <NUM>, the target communication device <NUM>, the first path <NUM>, the second path <NUM>, a first set of data packets 410a, 412a, and 414a, and a second set of data packets 410b, 412b, and 414b.

There are two modes (or options) for the multipath communication. The two modes are referred to as a duplication mode and a split mode. The duplication mode enables redundancy of radio links that increases reliability of data communication. In the duplication mode, duplicate data packets having a copy of same payload are communicated via at least two different paths to ensure that all data packets reach a common destination, such as the target communication device <NUM>. In the split mode, different data packets having different payload are provided concurrently to the common destination, such as the target communication device <NUM>, via at least two different paths to increase throughput and reduce latency. In other words, some data packets out of a plurality of data packets are communicated via one path whereas some other data packets are concurrently communicated via another path to increase throughput and reduce latency.

In accordance with an embodiment, the source communication device <NUM> is configured to select the duplication mode to communicate the plurality of data packets to the target communication device <NUM> via the two or more different paths. The selection of the duplication mode occurs before a start of a data session, i.e. before initiation of transmission of data packets or during the data session. Based on the selection of the duplication mode, the source communication device <NUM> is configured to provide the first set of data packets 410a, 412a, and 414a via the first path <NUM>. The source communication device <NUM> is further configured to provide, to the target communication device <NUM>, the second set of data packets 410b, 412b, and 414b via the second path <NUM> as duplicate data packets based on the selection of the duplication mode. In such a case, at least a payload of the first set of data packets 410a, 412a, and 414a is same as the payload of the second set of data packets 410b, 412b, and 414b in the duplication mode. The data packets of the first set of data packets 410a, 412a, and 414a and duplicate data packets of first set of data packets 410a, 412a, and 414a (i.e. the second set of data packets 410b, 412b, and 414b) are transmitted in sequence (also represented by consecutive numbers <NUM>, <NUM>, and <NUM> in the <FIG>).

In an exemplary implementation, the target communication device <NUM> is configured to filter the duplicate data packets from the plurality of data packets received at the target communication device <NUM> based on the packet information. Thus, for data to be error-free, the redundant data packets in the first set of data packets 410a, 412a, and 414a and the second set of data packets 410b, 412b, and 414b that are potentially obtained by the target communication device <NUM> are filtered out. Such multipath communication via the duplication mode is advantageous to achieve better reliability than communication via a single path.

<FIG> is a block diagram that illustrates data communication via a split mode, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG> and <FIG>. With Reference to <FIG>, there is shown an exemplary scenario 400C to depict data communication in a split mode. In the split mode, the plurality of data packets is split into a first set of data packets <NUM>, <NUM>, and <NUM> that are communicated via the first path <NUM> and a second set of data packets <NUM>, <NUM>, and <NUM> that are communicated via the second path <NUM>. The payload of the first set of data packets <NUM>, <NUM>, and <NUM> is different from a payload of the second set of data packets <NUM>, <NUM>, and <NUM> in the split mode. In an example, as shown in <FIG>, if total six data packets <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, are to be provided to the target communication device <NUM>, the plurality of data packets are split and communicated concurrently via two paths (i.e. the first path <NUM> and the second path <NUM>) to increase throughput and reduce latency. The sequence of transmission of data packets is also represented by consecutive numbers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. The selection of the duplication mode or the split mode may be made by the source communication device <NUM> to improve the QoS of the communication between the source communication device <NUM> and the target communication device <NUM>.

<FIG> is a block diagram that illustrates various exemplary components of a source communication device, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, <FIG>. With reference to <FIG>, there is shown the source communication device <NUM>. The source communication device <NUM> includes a control circuitry <NUM>, a transceiver <NUM>, one or more interfaces <NUM>, an input/output (I/O) device <NUM>, and a memory <NUM>. The control circuitry <NUM> may be communicatively coupled to the transceiver <NUM>, the one or more interfaces <NUM>, the I/O device <NUM>, and the memory <NUM>. In case the source communication device <NUM> is a vehicle, the control circuitry <NUM> is communicatively coupled to various components of the source communication device <NUM> via an in-vehicle network, such as in-vehicle data buses, such as a vehicle area network (VAN) and/or a controller area network (CAN) bus.

As already indicated above, the control circuit in this and in the following embodiments may be a general-purpose processor running a dedicated software or a dedicated hardware circuitry.

The control circuitry <NUM> is configured to provide a plurality of data packets to the target communication device <NUM> via two or more different paths. In an implementation, the control circuitry <NUM> is configured to execute instructions stored in the memory <NUM>. Examples of the control circuitry <NUM> may include, but is not limited to a microprocessor, a microcontroller, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a reduced instruction set (RISC) processor, a very long instruction word (VLIW) processor, a central processing unit (CPU), a state machine, a data processing unit, and other processors or circuits. Moreover, the control circuitry <NUM> may refer to one or more individual processors, processing devices, a processing unit that is part of a machine.

The transceiver <NUM> may include suitable logic, circuitry, and/or interfaces that may be configured to communicate with one or more external devices, such as a radio access network node (e.g. a base station) or a target communication device <NUM> via two or more different paths. Examples of the transceiver <NUM> may include, but is not limited to, an antenna, a telematics unit, a radio frequency (RF) transceiver, one or more amplifiers, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, and/or a subscriber identity module (SIM) card. The transceiver <NUM> may wirelessly communicate by use of various communication protocols of the first path <NUM> and the second path <NUM> (as described in <FIG>).

The one or more interfaces <NUM> refers to a sidelink interface and a cellular interface. Examples of the sidelink interface include, but is not limited to a PC5 interface, a PC3 interface, or another interface that allows device-to-device communication. Examples of the cellular interface include, but is not limited to Uu interface. In an exemplary implementation, a unified interface may be provided that allows communication to two or more paths via a same unified interface.

The I/O device <NUM> refers to input and output devices that can receive input from a user and provide output to the user. The I/O device <NUM> may be communicatively coupled to the control circuitry <NUM>. Examples of input devices may include, but are not limited to, a touch screen, such as a touch screen of a display device, a microphone, a motion sensor, a light sensor, a dedicated hardware input unit (such as a push button), and a docking station. Examples of output devices include a display device and a speaker. Examples of the display device include, but is not limited to a vehicle display (such as a head-up display (HUD), an augmented reality system (AR-HUD), a display screen of a driver information console (DIC), an infotainment unit or head unit (HU)), a non-vehicle display, such as a smart-glass display, a display screen of a portable device, or other display screen.

The memory <NUM> may include suitable logic, circuitry, and/or interfaces that may be configured to store machine code and/or instructions with at least one code section executable by the control circuitry <NUM>. The memory <NUM> may store the plurality of data packets for processing and presentation to an application layer of the source communication device <NUM>. Examples of implementation of the memory <NUM> may include, but are not limited to, Electrically Erasable Programmable Read-Only Memory (EEPROM), Random Access Memory (RAM), Read Only Memory (ROM), Hard Disk Drive (HDD), Flash memory, a Secure Digital (SD) card, Solid-State Drive (SSD), and/or CPU cache memory. The memory <NUM> may store an operating system and/or other program products to operate the source communication device <NUM>. A computer readable storage medium for providing a non-transient memory may include, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

<FIG> is a block diagram that illustrates various exemplary components of a target communication device, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, and <FIG>. With reference to <FIG>, there is shown the target communication device <NUM>. The target communication device <NUM> includes a control circuitry <NUM>, a transceiver <NUM>, one or more interfaces <NUM>, an input/output (I/O) device <NUM>, and a memory <NUM>. The control circuitry <NUM> may be communicatively coupled to the transceiver <NUM>, the one or more interfaces <NUM>, the I/O device <NUM>, and the memory <NUM>. In case the target communication device <NUM> is a vehicle, the control circuitry <NUM> is communicatively coupled to various components of the target communication device <NUM> via an in-vehicle network, such as in-vehicle data buses, such as a vehicle area network (VAN) and/or a controller area network (CAN) bus.

The control circuitry <NUM> is configured to obtain a plurality of data packets via two or more different paths. In an implementation, the control circuitry <NUM> is configured to execute instructions stored in the memory <NUM>. Examples of the control circuitry <NUM> is similar to that of the control circuitry <NUM> (<FIG>). Similarly, examples of implementation of the transceiver <NUM>, the one or more interfaces <NUM>, the I/O device <NUM>, and the memory <NUM> is similar to that of the transceiver <NUM>, the one or more interfaces <NUM>, the I/O device <NUM>, and the memory <NUM>, respectively of <FIG>.

<FIG> is a block diagram that illustrates a network environment of a system <NUM> with various nodes of a cellular network, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, and <FIG>. With reference to <FIG>, there is shown the system <NUM> that includes the source communication device <NUM>, the target communication device <NUM>, and one or more network entities of a cellular network <NUM>, such as a source radio access network (RAN) node <NUM>, a core network entity <NUM>, a target RAN node <NUM>.

Each of the source RAN node <NUM> and the target RAN node <NUM> refers to a radio base station, such as a NodeB, an evolved Node B (eNB), Next Generation Node B (gNB), a base transceiver station, an access point base station, a base station router, or any other network entity capable of communicating with a wireless device (e.g. the source communication device <NUM> or the target communication device <NUM>). The cellular network <NUM> covers a geographical area which is divided into cell areas, where one or more cell areas are served by the source RAN node <NUM> and the target RAN node <NUM>.

The core network entity <NUM> is a part of the cellular network <NUM> that connects the different nodes (or parts) of the access network (i.e. RAN). In LTE, the core network entity <NUM> includes, for example, serving gateway (S-GW), packet data network (PDN) gateway (PDN GW), mobility management entity, Home Subscriber Server (HSS) as evolved packet core (EPC). In case of <NUM>, network entities are referred to as "functions" and are usually not referred to as "nodes". For example, the functions of the <NUM> S-GW and PDN-GW is merged into a single entity, called user plane function (UPF). In another example, the <NUM> MME is split into two individual functions, such as access management function (AMF) and session management function (SMF). However, in the present disclosure, a network entity may cover both access node entities and core network entities (e.g. network nodes or functions).

In operation, the source communication device <NUM> is configured to provide a first set of data packets from a plurality of data packets to the target communication device <NUM> via a cellular communication path <NUM>. In order to provide the first set of data packets to the target communication device <NUM> via the cellular communication path <NUM>, the first set of data packets are first communicated to a network entity (such as the source RAN node <NUM>) in an uplink transmission <NUM>. Thereafter, the first set of data packets may be further communicated to the target communication device <NUM> or a further network entity, such as the core network entity <NUM> and the target RAN node <NUM>, to provide to the target communication device <NUM> in a downlink transmission <NUM>. The source communication device <NUM> is further configured to communicate a second set of data packets from the plurality of data packets to the target communication device <NUM> via a sidelink communication path <NUM>. A header of each data packet includes packet information that is indicative of an association among the plurality of data packets.

The network entity, such as the source RAN node <NUM>, is configured to obtain, from the source communication device <NUM>, the first set of data packets. The header of each data packet of the first set of data packets comprises packet information.

In accordance with an embodiment, the network (such as the source RAN node <NUM>) is configured to enable a multipath function based on an indicator in the header of each data packet of the first set of data packets or in a signalling message transmitted by the source communication device <NUM>. The multipath function refers to a network capability which allows storage (or maintenance) of the packet information in the header of each data packet of the first set of data packets received at the network entity (such as the source RAN node <NUM>) and reusage of the packet information to further provide each received packet to the target communication device <NUM>. In a case where the data packet from the network entity (such as the source RAN node <NUM>) traverses through the core network entity <NUM> or one or more other RAN nodes, such as the target RAN node <NUM>, the multipath function refers to a network capability which allows routing of each data packet of the first set of data packets having the packet information to a further network entity that reuses the packet information to further provide each received packet to the target communication device <NUM> via the network entity (such as the source RAN node <NUM>), or another network entity (such as the target RAN node <NUM>).

The network entity, such as the source RAN node <NUM>, is further configured to map an uplink sequence number (e.g. uplink PDCP sequence number) to a downlink sequence number (e.g. downlink PDCP sequence number) for each data packet of the received first set of data packets based on the packet information. The network entity, such as the source RAN node <NUM>, is further configured to provide each received data packet of the first set of data packets that includes the packet information to at least one of the target communication device <NUM> or a further network entity (such as the core network entity <NUM> or the target RAN node <NUM>) based on the mapped uplink sequence number to the downlink sequence number.

The target communication device <NUM> is configured to obtain the plurality of data packets via the cellular communication path <NUM> and the sidelink communication path <NUM>. The plurality of data packets includes different data packets having different payload or duplicate data packets having a copy of same payload. The target communication device <NUM> is configured to identify the first set of data packets from the plurality of data packets received via the cellular communication path <NUM> and the second set of data packets from the plurality of data packets received via the sidelink communication path <NUM> based on the packet information.

<FIG> is a block diagram that illustrates various exemplary components of a network entity, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, and <FIG>. With reference to <FIG>, there is shown a network entity <NUM>. The network entity <NUM> corresponds to one of the network entities of the cellular network <NUM> (<FIG>). The network entity <NUM> covers both access network entities (e.g. RAN node) and core network entities (e.g. nodes or functions). The network entity <NUM> includes an entity control circuitry <NUM>, a transceiver <NUM>, and a memory <NUM>. The entity control circuitry <NUM> is communicatively coupled to the transceiver <NUM>, and the memory <NUM>.

The entity control circuitry <NUM> is configured to obtain a first set of data packets from the source communication device <NUM>, where a header of each data packet of the first set of data packets comprises packet information. The packet information is indicative of an association among the first set of data packets. Examples of the entity control circuitry <NUM> is similar to that of the control circuitry <NUM> (<FIG>). As already indicated above, the entity control circuit, or simply control circuit, in this and in the following embodiments may be a general-purpose processor running a dedicated software or a dedicated hardware circuitry. Similarly, examples of implementation of the transceiver <NUM> and the memory <NUM> is similar to that of the transceiver <NUM> and the memory <NUM>, respectively of <FIG>.

In accordance with an embodiment, the entity control circuitry <NUM> is configured to append the uplink sequence number (SN) received from the source communication device <NUM> in a core network protocol-based header of each received data packet of the first set of data packets. The entity control circuitry <NUM> is further configured to communicate each received data packet of the first set of data packets having the core network protocol-based header that includes the appended uplink SN to the core network entity <NUM>. The core network protocol-based header that includes the appended uplink SN is a modified core network protocol-based header that includes the appended uplink SN as an extension in a header structure of the core network protocol-based header. Optionally, the core network protocol-based header is a GTP-U header. The entity control circuitry <NUM> is further configured to set the retrieved uplink SN as a downlink SN in each received data packet of the plurality of data packets prior to a downlink transmission of the received data packets of the first set of data packets to the target communication device <NUM>.

In accordance with an embodiment, the entity control circuitry <NUM> is configured to enable the multipath function based on an indicator in the header of each data packet of the first set of data packets or in a signalling message transmitted by the source communication device <NUM>. The enablement of the multipath function includes storage of the packet information in each data packet of the first set of data packets received at the network entity <NUM> and reusing the packet information to further provide each received packet to the target communication device <NUM>. The enablement of the multipath function further includes routing of each data packet of the first set of data packets having the packet information to a further network entity (such as the core network entity <NUM>) that reuses the packet information to further provide each received packet to the target communication device <NUM> via the network entity <NUM>, or another network entity.

<FIG> illustrates an exemplary scenario <NUM> to execute multipath communication with network layers, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, <FIG>. With reference to <FIG>, there is shown a first plurality of network layers 702A (i.e. a user plane protocol stack) in the source communication device <NUM> and a second plurality of network layers 702B (i.e. a corresponding user plane protocol stack) in the target communication device <NUM>. Each of the first plurality of network layers 702A and the second plurality of network layers 702B includes a physical (PHY) layer, a media access control (MAC) layer, a radio link control (RLC) layer, a PDCP layer, a convergence layer, and an application layer. In some embodiments, for example, in case of a <NUM> capable cellular network (i.e. a NR user plane protocol stack), a service data adaptation protocol (SDAP) layer is additionally provided in the source communication device <NUM> and the target communication device <NUM>. Each network layer may also be referred to as a protocol layer of the user plane protocol stack.

In accordance with an embodiment, the method to execute multipath communication at the source communication device <NUM>, the network entity <NUM>, and the target communication device <NUM>, is potentially implementable at different network layers. Based on a specific network layer (or protocol layer) in which the duplication or splitting of data takes place in the source communication device <NUM> (and consequently in the target communication device <NUM>), different approaches (or solutions) may be used to execute the multipath communication. The different approaches include a communication device-based approach and a network-based approach.

In the communication device-based approach, the source communication device <NUM> is configured to generate a packet identifier (e.g. for a duplicated or a split packet) or a sequence number. The packet identifier (or the sequence number) is appended to the header (e.g. in the application layer or the convergence layer (such as a V2X layer in case of a vehicle)) of each data packet of a plurality of data packet that are to be provided to the target communication device <NUM>. Optionally, the packet identifier (or the sequence number) is introduced in a header of each data packet at the communication layer, the application layer, or at the V2X layer (in case of vehicles) to reduce the impact on existing protocol layers of the user plane protocol stack.

Typically, a sequence number is assigned to each data packet at a transmitting end (i.e. the source communication device <NUM>) in the PDCP layer before each data packet passes to a next layer (i.e. the RLC layer). This sequence number is used at the PDCP layer at the receiving end (i.e. the target communication device <NUM>) to align data packets in a sequential order. However, currently, there is a problem in transmission of data packets via different paths (e.g. the cellular communication path <NUM> and the sidelink communication path <NUM>) that employs different interfaces (e.g. a NR Uu interface and the NR PC5 interface). The problem is that the target communication device <NUM> may not able to compare (or match) the data packets received via a cellular interface (i.e. the Uu interface) with data packets received from a sidelink interface (i.e. the PC5 interface). In such cases, the downlink and the uplink sequence numbers of the data packets may be different or the packets may become disarranged (i.e. incorrectly ordered). Thus, in conventional methods and systems, the comparison of data packets communicated via the sidelink interface with the data packets sent via the cellular interface is not feasible. Thus, in the present disclosure, the packet information (i.e. the packet identifier for a split data packet or a duplicate data packet or a dedicated sequence number) is appended (or assigned) to the header of each data packet in upper layers (i.e. the application layer or the convergence layer (such as a V2X layer in case of a vehicle)). Such packet information is additional control information (e.g. additional packet identifier or additional sequence number other than the usual PDCP sequence number) that is retained in the header of each data packet of the plurality of data packets irrespective of the path (e.g. the cellular communication path <NUM> and the sidelink communication path <NUM>) or different network nodes that the data packets traverses. The corresponding layer (e.g., the application layer or the convergence layer, and the like) at the target communication device <NUM> is utilized to compare and identify the packets based on the packet information (e.g. the additional packet identifier or the additional sequence number) in each data packet. The communication device-based approach does not have any impact on the network.

Optionally, in a case where the duplication mode is selected at the source communication device <NUM>, the source communication device <NUM> is configured to generate a duplication identifier (ID), which is set for the duplicate data packets. The duplicate ID is stored (i.e. maintained) in the header of each data packet irrespective of the different radio access technologies, communication protocols, or radio links used in the two or more different paths traversed by the data packets. The convergence layer or the V2X layer (in case of V2V communication) may be used to generate the duplication ID at the source communication device <NUM> and to perform reordering or filtering of the received data packets at the corresponding convergence layer at the target communication device <NUM>. The generation of such duplication ID allows unique identification of the duplicated data packets at the target communication device <NUM> regardless of the paths or intermediate protocols and network nodes followed by the data packets. Similarly, a packet ID may be set for the split data packets that remains in the data packet throughout the communication process for unique identification of the split data packets at the target communication device <NUM>.

In the network-based approach, the network is enabled to maintain the packet information (e.g. the packet identifier or the sequence number) that is set at the source communication device <NUM> at a specific network layer (e.g. the PDCP, SDAP, or another network layer) across the end-to-end network. The network entity <NUM> (e.g. a base station) is configured to map an uplink sequence number to a downlink sequence number for each data packet obtained from the source communication device <NUM> based on the packet information. Optionally, the network-based approach has a network impact as it involves signalling to the network to maintain the packet information in header of each data packet throughout the end-to-end network.

<FIG> illustrates an exemplary scenario <NUM> for execution of multipath communication using different radio access technologies, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, <FIG>, <FIG>, and <FIG>. With reference to <FIG>, there is shown an application layer 802A at the source communication device <NUM> and a corresponding application layer 802B at the target communication device <NUM>. There is further shown the control circuitry <NUM> of the source communication device <NUM> and the control circuitry <NUM> of the target communication device <NUM>.

In accordance with an embodiment, the control circuitry <NUM> of the source communication device <NUM> is configured to provide, to the target communication device <NUM>, a first set of data packets from a plurality of data packets via a first path and a second set of data packets from the plurality of data packets via a second path. In this embodiment, the first path uses a first radio access technology (RAT-<NUM>) and the second path uses a second radio access technology (RAT-<NUM>) that is different than the RAT-<NUM>. In this case, the first path and the second path correspond to different device-to-device communication that employ different radio access technologies (e.g. NR PC5 interface and LTE PC5 interface as shown).

In an example, in a case where the split mode is selected at the source communication device <NUM>, the control circuitry <NUM> is configured to set a sequence number (i.e. a dedicated sequence number) for each data packet at the application layer 802A, irrespective of the radio access technologies (i.e. RAT-<NUM> or RAT-<NUM>) used for data communication. The RAT may be for example, LTE, <NUM>, and the like. The corresponding application layer 802B of the target communication device <NUM> is used to check the sequence number of each data packet obtained from the source communication device <NUM>. The control circuitry <NUM> of the target communication device <NUM> is configured to reorder the plurality of data packets obtained in the first path and the second path (i.e. via different radio access technologies) in the split mode at the corresponding application layer 802B in accordance with the sequence number associated with each of the plurality of data packets. Alternatively, instead of the application layer 802A, the convergence layer, the V2X layer, or any other network layer outside the access stratum (AS) may be used to set the sequence number. The same network layer that is used to set the sequence number is then used at the target communication device <NUM> to check the sequence number and accordingly perform the reordering.

In another example, in a case where the duplication mode is selected at the source communication device <NUM>, the control circuitry <NUM> is configured to set a sequence number (i.e. additional dedicated sequence number) for each data packet at the application layer 802A, irrespective of the radio access technologies (i.e. RAT-<NUM> or RAT-<NUM>) used for data communication. Moreover, a duplicate ID is potentially assigned to duplicate data packets (e.g. the second set of data packets may have same payload as the first set of data packets) at the application layer 802A (or the convergence layer, or V2x layer in case of a vehicle). The control circuitry <NUM> of the target communication device <NUM> is configured to identify the duplicate data packets based on the duplication ID even if the plurality of data packets is obtained from the source communication device <NUM> via the different radio access technologies (i.e. via NR PC5 interface and LTE PC5 interface). The control circuitry <NUM> is configured to filter the duplicate data packets from the plurality of data packets received at the target communication device at the corresponding application layer 802B (or convergence layer, or the V2x layer) based on the packet information (e.g. the duplication ID and the dedicated sequence number).

<FIG> illustrates an exemplary scenario <NUM> for execution of multipath communication with packets duplication and splitting at a PDCP layer, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>. With reference to <FIG>, there is shown a SDAP layer 902A, a PDCP layer 904B, an RLC layer 906A, a MAC layer 908A of a user plane protocol stack in the source communication device <NUM> associated with a cellular interface (e.g. the Uu interface). Similarly, the corresponding network layers, such as a SDAP layer 902B, a PDCP layer 904B, a RLC layer 906B, and a MAC layer 908B that are associated with corresponding Uu interface is shown in the target communication device <NUM>. In addition to the network layers that are associated with the Uu interface, network layers associated with the sidelink communication (such as sidelink (SL) RLC 910A and SL MAC 912A) are further shown in the source communication device <NUM> and the target communication device <NUM> (e.g. SL RLC 910B and SL MAC 912B). There is further shown the control circuitry <NUM> of the source communication device <NUM> and the control circuitry <NUM> of the target communication device <NUM>.

In accordance with this embodiment, the data packets duplication or splitting is described with respect to the PDCP layer 904A instead of upper layers (such as the application layer, the convergence layer, or the V2X layer in case of a vehicle). However, it is to be understood that the data packets duplication or splitting may be implemented at different network layers, such as the SDAP layer 902A. In this embodiment, as the duplication is executed at the PDCP layer 904A of the source communication device <NUM>, the data packets with same PDCP headers (i.e. same PDCP SN) are used for transmission via the cellular the communication path (e.g. via Uu interface) as well as the sidelink communication path (e.g. PC5 interface) in the duplication mode. Thus, the uplink PDCP SN is same as that of the sidelink PDCP SN. However, the uplink PDCP SN still needs to be same as that of the downlink PDCP SN for efficient and error free transmission of data from the source communication device <NUM> to the target communication device <NUM> in the multipath communication. Typically, in conventional systems, the PDCP SN of a given data packet in the uplink transmission may not be same with the PDCP SN of the same given packet in the downlink transmission. Thus, the source RAN node <NUM> is configured to map an uplink PDCP SN received from the source communication device <NUM> with a downlink PDCP SN for each data packet of the first set of data packets received at the source RAN node <NUM>. The mapping of the uplink PDCP SN with the downlink PDCP SN is done in order to address incorrect ordering issues and allow the target communication device <NUM> to compare (or match) the data packets obtained via the cellular communication path <NUM> with the data packets obtained via the sidelink communication path <NUM>. It will be appreciated that the mapping between the uplink PDCP SN with the corresponding downlink PDCP SN requires cooperation between the RAN (such as the source RAN node <NUM> and the target RAN node <NUM>) and the core network entity <NUM> of the cellular network <NUM> for comparison of the data packets. The source RAN node <NUM> is further configured to append the uplink PDCP SN obtained from the source communication device <NUM> in a core network protocol-based header (e.g. the GTP-U header) of each received data packet of the first set of data packets. In an example, the source RAN node <NUM> appends the uplink PDCP SN in the GTP-U header of the data packets that are sent via, for example, N3 interface, for a specific service flow (QFI).

Notably, the GTP-U is responsible for carrying the data within the GPRS core network as well as between the RANs (such as the source RAN node <NUM> and the target RAN node <NUM>) and the core network entity <NUM>. The transported data in the form of data packets may be in several formats such as Internet Protocol version <NUM> (IPv4) format, Internet Protocol version <NUM> (IPv6) format, point-to-point protocol (PPP) format and the like. Moreover, the source RAN node <NUM> communicates each received data packet of the first set of data packets having the GTP-U header that includes the appended uplink PDCP SN to the core network entity <NUM>. The GTP-U header that includes the appended uplink PDCP SN is a modified GTP-U header that includes the appended uplink PDCP SN as an extension in a header structure of the GTP-U header. An example of the GTP-U header is described in <FIG>. The uplink PDCP SN is forwarded via the core network entity <NUM> entities of the first path <NUM>. Further, the user plane function (UPF) node maintains the PDCP SN in the GTP-U header that are transmitted over the N3 interface or an N9 interface. The GTP-U header is thus a modified GTP-U header that includes at least the packet information, for example, the uplink PDCP SN.

<FIG> illustrates an exemplary structure of a GPRS Tunnelling Protocol User Plane (GTP-U) header <NUM>, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, <FIG>, and <FIG>. With reference to <FIG>, there is shown an example of a core network protocol-based header, such as the GTP-U header <NUM>.

The GTP-U header <NUM> includes various fields in accordance to the 3GPP specification, such as "Message type" that is reserved for a type of data present in a data packet. For example, the message type may be text, an image, an audio, or a video. The GTP-U header <NUM> may further includes fields, such as length (i.e. measured in terms of number of bits) of the data packet, "Tunnel endpoint identifier", "Sequence number" and the like. Moreover, the GTP-U header <NUM> further includes a new extension header type field <NUM>.

In accordance with an exemplary implementation, the new extension header type field <NUM> is used to include information, such as duplication mode or the split mode associated with the data packets that are potentially sent via N3 interface between a RAN node (such as the source RAN node <NUM>) and a user plane function (UPF) or via N9 interface between two two UPFs (e.g. intra-Public Land Mobile Network (PLMN) interface or inter-PLMN interface). The new extension header type field <NUM> is enhanced or extended) to include, for instance, uplink PDCP SN and the Quality of service Flow Identifier (QFI). Optionally, in another implementation, the uplink PDCP SN is appended in a <NUM> encapsulation header, in a <NUM> cellular network on N3 (and/or N9) interfaces to reduce changes to the header of a data packet across the e2e network.

Activation of multipath function: there are two options for the activation of the multipath function, for example, in the network-based approach (or solution). The first option is activation on a session level and the second option is activation on per data packet basis. In the first option, a radio access network node (e.g. a base station, such as a gNB) and a user plane function (UPF) are signalled at protocol data unit (PDU) session establishment or modification to provide a specific treatment to uplink and downlink data packets by various network nodes and interfaces on the session level. The first option is described in details, for example, in <FIG>. In the second option, the multipath function is activated based on an indicator in the header of each data packet of the first set of data packets, to provide a specific treatment to uplink and downlink data packets by the various network nodes and interfaces on per data packet basis. The activation of the multipath function based on the indicator in the header of each data packet is described in details, for example, in <FIG>.

<FIG> is a sequence diagram <NUM> that illustrates a portion of a procedure of protocol data unit (PDU) session establishment, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>. With reference to <FIG>, there is shown a user equipment (UE) <NUM>, a radio access network (R)AN <NUM>, an access and mobility management function (AMF) <NUM>, a user plane function (UPF) <NUM>, a session management function (SMF) <NUM>, a policy control function (PCF) <NUM>, a unified data management (UDM) <NUM>, and a data network <NUM>. The UE <NUM> corresponds to the source communication device <NUM>. The RAN <NUM> corresponds to the source RAN node <NUM> (<FIG>).

The sequence diagram <NUM> depicts a portion of a procedure of PDU session establishment that is compliant to the 3GPP specification. In an exemplary implementation, some operations in the sequence diagram <NUM> that involve SMF <NUM> signalling to RAN <NUM> and UPF <NUM> are potentially enhanced (or extended) to enable the multipath function at one or more network entities based on an indicator in a signalling message transmitted by the source communication device <NUM> (e.g. by control plane signalling). For example, the SMF <NUM> signalling to the RAN <NUM> (e.g. steps <NUM> and <NUM>) and the UPF <NUM> (e.g. step 1134A) are potentially enhanced (i.e. extended) to enable the uplink sequence number received in a specified network layer (e.g. the PDCP layer) from the source communication device <NUM> to be the same as the downlink sequence number in the specified network layer. specifically, the SMF <NUM> signalling to RAN <NUM> is potentially enhanced (or extended) to enable transfer of the sequence number received in a specific network layer (e.g. PDCP SN) in N3 in an uplink data packet, and further enable use of the uplink SN in the specified network layer (e.g. downlink PDCP SN) for the downlink packet. Moreover, in the sequence diagram <NUM>, the signalling of SMF <NUM> to UPF <NUM> is potentially extended to enable the UPF <NUM> to forward the received data packets that includes the modified core network protocol-based header (e.g. the modified GTP-U header) that includes the appended uplink sequence number to appropriate QFIs in the downlink PDU session.

In the sequence diagram <NUM>, the procedure of PDU session establishment (or modification) is described from UPF <NUM> selection by the SMF <NUM> at a step <NUM>. It is to be understood by a person of ordinary skill in the art that there are various steps to be potentially performed before the step <NUM>. For example, PDU session establishment request, SMF selection by the AMF, signalling from AMF to SMF (i.e. in the form of a Nsmf_PDUSession_CreateSMContext Request), retrieval of session management subscription data by SMF (if not available), signalling from SMF to AMF (i.e. in the form of a Nsmf_PDUSession_CreateSMContext Response), and the like (e.g. as specified in 3GPP-<NUM>).

At step <NUM>, the SMF <NUM> initiates a session management policy association modification between the SMF <NUM> and the PCF <NUM>. At step <NUM>A, a N4 session establishment/modification request is communicated from the SMF <NUM> to the UPF <NUM>. At step 1122B, a N4 session establishment or modification response is communicated from the UPF <NUM> to the SMF <NUM>. At step <NUM>, a Namf_communication_N1N2message transfer is executed from the SMF <NUM> to the AMF <NUM>. In a case where N2 session management (SM) information is not included in the step <NUM>, then the following step <NUM> to 1134B and step <NUM> are potentially omitted. Beneficially, in an exemplary implementation of the present disclosure, the Namf_communication_N1N2 message transfer is enhanced and extended to enable transfer of the sequence number received in a specific network layer (e.g. PDCP SN) in N3 in an uplink data packet. At step <NUM>, a N2 PDU session request is communicated from AMF <NUM> to RAN <NUM>. In the exemplary implementation, the N2 PDU session request is also enhanced and extended to enable use of the uplink SN in the specified network layer (e.g. downlink PDCP SN) for the downlink packet (in the downlink transmission). At step <NUM>, the N2 PDU session request is accepted. At step <NUM>, a N2 PDU session request acknowledgement is communication from the RAN <NUM> to the AMF <NUM>. At step <NUM>, Nsmf_PDUSession_updateSMContext request is communicated from the AMF <NUM> to the SMF <NUM>. At step 1134A, a N4 session modification request is communicated from the SMF <NUM> to the UPF <NUM>. In the exemplary implementation, the signalling of the SMF <NUM> to UPF <NUM> is potentially enhanced and extended to enable the UPF <NUM> to forward the received data packets that includes the modified core network protocol-based header (e.g. the modified GTP-U header) that includes the appended uplink sequence number to appropriate QFIs in the downlink PDU session. The N4 session modification request is used to enable the UPF <NUM> to forward the received data packets that includes the modified core network protocol-based header (e.g. the modified GTP-U header) that includes the appended uplink sequence number to appropriate QFIs in the downlink PDU session. At step 1134B, a N4 session modification response is received by the SMF <NUM>. At step <NUM>, a Nsmf_PDUSession_updateSMContext response is communicated from the SMF <NUM> to the AMF <NUM>. At step <NUM>, a Nsmf_PDUSession_SMContext_status_notify service is executed from the SMF <NUM> to the AMF <NUM>.

In the conventional systems and methods, and existing standards, there are various issues, for example, different packet identifiers for different protocols and different protocol layers and network entities (e.g. RAN part, core network part etc). In a first example, IPv4 has an identifier (ID) (i.e. IP ID) that is enabled for packets fragmentation, but such IP ID is not included in IPv6. In a second example, QoS Flow Identifier (QFI) allows a granularity in QoS differentiation in the PDU Session. Usually, a QoS Flow ID (QFI) is used to identify a QoS Flow in a <NUM> (NR) capable device. Typically, a user plane traffic with the same QFI within a PDU session receives the same traffic forwarding treatment (e.g. scheduling, admission threshold, and the like). The QFI is carried in an encapsulation header on N3 (and N9) interface i.e. without any changes to the packet header across the e2e network. This QFI is used for all PDU session types. The QFI is unique within a PDU Session. The QFI may be dynamically assigned or may be equal to the 5QI (i.e. <NUM> QoS characteristics). However, in such conventional methods and systems, there is no per packet treatment or handling. In a third example, currently a PDCP SN is available only at RAN (e.g. the RAN <NUM>) from the UE <NUM> to a base station in uplink transmission, whereas another PDCP SN may be set in the downlink transmission from the base station to the user equipment (i.e. a wireless communication device). This depends on packets disarrangement, path followed by data packets, and the like. In a fourth example, core network packet identifier (in N3) includes in the user plane, an increasing SN for transport (T)-PDUs is transmitted via GTP-U tunnels (GTP-U header), when transmission order of data packets must be preserved. This field is an optional field in G-PDUs that consists of a GTP-U header plus a T-PDU within the GPRS backbone network. However, in the conventional methods and systems, the focus is on the one part of N3 transmission (i.e. from RAN to UPF, or from UPF to RAN) and there is no direct link/correlation with RAN packet IDs. Moreover, in conventional methods and devices, there is no end-to-end tracking, mapping, or correlation of (R)AN <NUM> and core network packets. Thus, the various steps (e.g. steps 1122A to <NUM>) and step 1134A of the sequence diagram <NUM> are enhanced and extended to enable the multipath function, and solve the issues associated with the conventional methods and systems as described above.

<FIG> illustrates an exemplary indicator in a header of a data packet, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, <FIG>, <FIG>, and <FIG>. With reference to <FIG>, there is shown a PDCP header structure <NUM>. The PDCP header structure <NUM> includes a plurality of fields, such as a plurality of reserve fields <NUM>, <NUM>, and <NUM>, and fields for MAC address of a data packet.

In accordance with an embodiment, any one or more reserve fields of the plurality of reserve fields <NUM>, <NUM>, and <NUM> is potentially used as an indicator (e.g. a flag) in order to enable the RAN mapping of the uplink PDCP SN with the downlink PDCP SN for a data packet. In an example, the reserve field <NUM> may be set to a specific bit value (e.g. bit value "<NUM>") from the binary bit values (<NUM> or <NUM>) by the source communication device <NUM> to signal to the network entity <NUM> (e.g. the source RAN node <NUM>) to activate the multipath function to enable mapping of the uplink PDCP SN with the downlink PDCP SN. Thus, the source RAN node <NUM> is configured to map the uplink PDCP SN with the downlink PDCP SN based on the indicator (i.e. a bit value of "<NUM>" in the reserve filed <NUM> in this example). In another example, the source communication device <NUM> is further configured to set the reserve field <NUM> in the PDCP header structure <NUM> for an uplink data packet as an indication of the selection of the duplication mode at the source communication device <NUM>. Thus, based on such indication, the target communication device <NUM> is configured to determine that the plurality of data packets obtained from the source communication device <NUM> via two or more different paths includes duplicate data packets. Beneficially, the use of the plurality of reserve fields <NUM>, <NUM>, and <NUM> as an indicator allows per packet treatment of the uplink and downlink data packets instead of a pre flow treatment, without the need to modify existing PDCP header to minimize cost of implementation.

<FIG> illustrates an exemplary scenario <NUM> to execute vehicle-to-vehicle (V2V) multipath communication, in accordance with an embodiment of the present disclosure. <FIG> is described in conjunction with elements from <FIG>, <FIG>, <FIG>, and <FIG>. With reference to <FIG>, there is shown the exemplary scenario <NUM> that includes a source vehicle <NUM> and a target vehicle <NUM> moving on a road portion <NUM>. The source vehicle <NUM> includes an electronic control unit (ECU) <NUM> and the target vehicle <NUM> includes an ECU <NUM>. There is further shown a source base station <NUM>, a target base station <NUM>, a cellular communication path <NUM>, and a sidelink communication path <NUM>.

In accordance with the exemplary scenario <NUM>, the source vehicle <NUM> and the target vehicle <NUM> correspond to the source communication device <NUM> and the target communication device <NUM>, respectively (<FIG>). The source base station <NUM> and the target base station <NUM> correspond to the source RAN node <NUM> and the target RAN node <NUM> respectively (<FIG>). The source vehicle <NUM> may be within a communication range to establish a D2D communication with each other. A user of the source vehicle <NUM> may want to communicate data to the target vehicle <NUM>.

In accordance with an embodiment, the ECU <NUM> of the source vehicle <NUM> is configured to select a duplication mode or a split mode to communicate a plurality of data packets to the target vehicle <NUM> via the cellular communication path <NUM> and the sidelink communication path <NUM>. The ECU <NUM> of the source vehicle <NUM> is configured to provide, to the target vehicle <NUM>, a first set of data packets from the plurality of data packets via the cellular communication path <NUM> and a second set of data packets from the plurality of data packets via the sidelink communication path <NUM>. In other words, a plurality of V2X packets are communicated through different radio access technologies, radio links, interfaces, or communication protocols to improve the QoS of the communication between two vehicles, so as to increase reliability of V2V communication. A header of each data packet includes packet information indicative of an association among the plurality of data packets. The first set of data packets traverses through various network entities, such as the source base station <NUM>, and a neighbouring base station, such as the target base station <NUM>. In some cases, the first set of data packet may also traverse through a core network entity.

In accordance with an embodiment, the source base station <NUM> is configured to obtain the first set of data packets from the source vehicle <NUM>. The header of each data packet of the first set of data packets comprises packet information. The source base station <NUM> is configured to map an uplink sequence number received in a specified network layer (e.g. PDCP layer or other network layer) to a downlink sequence number for each data packet of the received first set of data packets based on the packet information. The source base station <NUM> is configured to provide each received data packet of the first set of data packets that includes the packet information to the target vehicle <NUM> in a case where the target vehicle is within a communication range of the source base station <NUM> at the time of communication. In a case where the target vehicle <NUM> is beyond the communication range of the source base station <NUM>, the source base station <NUM> is configured to provide each received data packet of the first set of data packets that includes the packet information to a neighbouring base station, such as the target base station <NUM>.

In accordance with an embodiment, the ECU <NUM> of the target vehicle <NUM> is configured to identify the first set of data packets received via the cellular communication path <NUM> and the second set of data packets received via the sidelink communication path <NUM> based on the packet information. As the packet information in the header of each data packet do not change irrespective of different radio access technologies, communication protocols, or radio links used in the two or more different paths (i.e. the cellular communication path <NUM> and the sidelink communication path <NUM> in this case), the quality-of-service (QoS) of data communication between the source vehicle <NUM> and the target vehicle <NUM> is improved. For example, in a case where the plurality of data packets obtained via two or more different paths includes different data packets having different payload (i.e. in the split mode), data-throughput is increased and latency in data communication is reduced. Further, in a case where the plurality of data packets obtained via two or more different paths includes duplicate data packets having a copy of same payload, reliability of data communication between the source vehicle <NUM> and the target vehicle <NUM> is significantly improved. Beneficially, such V2V multipath communication between the source vehicle <NUM> and the target vehicle <NUM> is useful in improvement of road safety by providing an efficient and reliable mechanism to share alerts and other data (such as text, image, audio, or video) concurrently via two or more different paths between the source vehicle <NUM> and the target vehicle <NUM>.

Claim 1:
A method (<NUM>) for executing multipath communication at a network entity (<NUM>), the method comprising:
obtaining, from a source communication device (<NUM>), a first set of data packets, wherein a header of each data packet of the first set of data packets comprises packet information, wherein the packet information is indicative of an association among the first set of data packets;
mapping an uplink sequence number to a downlink sequence number for each data packet of the first set of data packets based on the packet information; and
providing each received data packet of the first set of data packets that includes the packet information to at least one of a target communication device (<NUM>) or a further network entity based on the mapped uplink sequence number to the downlink sequence number; wherein
the uplink sequence number is received in a specified network layer from the source communication device (<NUM>), and wherein the uplink sequence number is mapped to the downlink sequence number in the specified network layer, wherein the specified network layer is at least one of a packet data convergence protocol layer, a service data adaptation protocol layer, or other network layer.