Method and apparatus for transmitting and receiving packets through a data bearer entity established in a radio access network (RAN) in mobile communication

Abstract

Various solutions for sending and receiving packets in a mobile communication device within a RAN (Radio Area Network) via established data bearer entities are described. The device can establish multiple data bearer entities with another device. These multiple data bearer entities can be mapped to multiple IP streams. The device and the other device can be located within the RAN. Based on the mapping of these multiple IP streams to the multiple data bearer entities, the device can send and receive multiple packets associated with these multiple IP streams with the other device through these multiple data bearer entities.

Description

[0001] Cross-referencing

[0002] This disclosure is a non-provisional application claiming priority to U.S. Patent Application No. 63 / 700,796 (filed September 30, 2024), the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure generally relates to mobile communications, and more specifically, to the transmission and reception of packets associated with mobile communication devices via data bearer entities established in a radio access network (RAN). Background Technology

[0004] Unless otherwise stated, the methods described in this section are not prior art as claimed in the following claims, and are not acknowledged as prior art because they are included in this section.

[0005] In Long-Term Evolution (LTE) or New Radio (NR) mobile communications, dedicated Data Radio Bearers (DRBs) can be configured to provide customized Quality of Service (QoS) parameters for different service types. Specifically, dedicated DRBs can improve latency performance, enable service differentiation, and enhance the user experience for latency-sensitive applications.

[0006] However, in real-world network architectures, deploying multiple dedicated DRBs across User Equipment (UE), Base Stations (BS), and Core Network (CN) can be limited by implementation complexity, operational costs, scalability challenges, and additional control overhead. Therefore, in typical commercial networks, all Internet services typically utilize a single DRB dedicated to best-effort Internet services, and diverse services such as Voice over IP (VoIP), cloud gaming, live video streaming, and backend data may be processed with the same priority and multiplexed on the same DRB. Consequently, packets requiring high reliability and low latency may experience performance degradation due to competition with best-effort or latency-tolerant services within a single DRB.

[0007] Therefore, improving network performance while avoiding excessive complexity and cost has become a crucial issue in newly developed wireless communication networks. Consequently, it is necessary to provide appropriate solutions to enhance network performance while avoiding excessive complexity and cost. Summary of the Invention

[0008] The following abstract is for illustrative purposes only and is not intended to be limiting in any way. That is, the following abstract aims to introduce the concepts, key points, benefits, and advantages of the novel and non-obvious techniques described herein. Some embodiments will be further described in the detailed description below. Therefore, the following abstract is not intended to identify the essential features of the claimed subject matter, nor to determine the scope of the claimed subject matter.

[0009] The objective of this disclosure is to provide a solution or approach to address the aforementioned problems encountered by mobile communication devices when sending and receiving packets through established data bearer entities in a Radio Access Network (RAN).

[0010] In one aspect, a method may involve an apparatus establishing multiple data bearer entities with another apparatus. These multiple data bearer entities may be mapped to multiple Internet Protocol (IP) streams, and the apparatus and the other apparatus may be located in a Radio Access Network (RAN). The method may also involve the apparatus sending and receiving multiple packets associated with the multiple IP streams through the multiple data bearer entities, based on the result of mapping the multiple IP streams to the multiple data bearer entities.

[0011] In one aspect, an apparatus may include a transceiver for wirelessly communicating with a wireless network during operation. The apparatus may also include a processor communicatively coupled to the transceiver. The processor may perform operations during operation, including establishing a plurality of data bearer entities with another device. The plurality of data bearer entities may be mapped to a plurality of IP streams, and the apparatus and the other device may be located in a radio access network (RAN). The processor may also perform operations including, based on the result of mapping the plurality of IP streams to the plurality of data bearer entities, sending and receiving, via the transceiver, a plurality of packets associated with the plurality of IP streams with the other device through the plurality of data bearer entities.

[0012] It is worth noting that although the descriptions provided herein may be within the context of certain wireless access technologies, networks, and network topologies, such as Long Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, 5G, New Radio (NR), Internet of Things (IoT) and Narrowband Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), and 6G, the proposed concepts, schemes, and any variations / derivatives thereof can be implemented, used, and implemented by other types of wireless access technologies, networks, and network topologies. Therefore, the scope of this disclosure is not limited to the examples described herein. Attached Figure Description

[0013] The accompanying illustrations are intended to further understand this disclosure and are incorporated into and constitute a part of this disclosure. The illustrations show embodiments of this disclosure and, together with the description, are used to explain the principles of this disclosure. It will be understood that the illustrations are not necessarily drawn to scale, as some components may be shown out of proportion to their actual dimensions in order to clearly illustrate the concepts of this disclosure.

[0014] Figure 1 This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0015] Figure 2 This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0016] Figure 3A This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0017] Figure 3B This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0018] Figure 3C This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0019] Figure 4A This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0020] Figure 4B This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0021] Figure 4C This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0022] Figure 5 This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0023] Figure 6A This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0024] Figure 6B This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0025] Figure 6C This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0026] Figure 7 This is a schematic diagram of an example scenario under the scheme of the embodiments of this disclosure.

[0027] Figure 8 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0028] Figure 9 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0029] Figure 10 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0030] Figure 11 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0031] Figure 12 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0032] Figure 13 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0033] Figure 14 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0034] Figure 15 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0035] Figure 16 This is a schematic diagram of an example scenario under the scheme of the present disclosure.

[0036] Figure 17 This is a block diagram of an example communication system according to an embodiment of the present disclosure.

[0037] Figure 18 This is a flowchart of an example process according to an embodiment of the present disclosure. Detailed Implementation

[0038] This specification discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the disclosed embodiments and implementations are for illustrative purposes only, and the subject matter can be implemented in various forms. This disclosure can be embodied in many different forms and should not be construed as being limited to the exemplary embodiments and implementations listed herein. Rather, these exemplary embodiments and implementations are intended to make the description of this disclosure thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art. In the following description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.

[0039] Overview

[0040] According to the implementation of this disclosure, various technologies, methods, schemes, and / or solutions relate to mobile communication devices for sending and receiving packets through established data bearer entities in a radio access network (RAN). According to this disclosure, several possible solutions can be implemented individually or in combination. That is, although these possible solutions are described separately below, two or more of them can be implemented in one or another combination.

[0041] Regarding this disclosure, an apparatus (e.g., a network node or user equipment (UE)) can establish multiple data bearer entities with another apparatus (e.g., a UE or a network node). These multiple data bearer entities can be mapped to multiple Internet Protocol (IP) streams. The apparatus and the other apparatus can be located in a radio access network (RAN).

[0042] Based on the mapping of multiple IP flows to multiple data bearer entities, the device can send and receive multiple packets associated with the multiple IP flows with the other device through these multiple data bearer entities. Therefore, since multiple data bearer entities can be established within the RAN, network performance can be improved while avoiding the complexity and cost of establishing multiple data bearer entities in the core network (CN).

[0043] Figure 1 Example scenario 100 is illustrated under a scheme implemented according to this disclosure. Scenario 100 involves a first device and a second device, both of which may be part of a wireless communication network (e.g., an LTE network, a 5G / NR network, an Internet of Things (IoT) network, or a 6G network). Scenario 100 illustrates a current network architecture. The first device may be connected to the second device. The first device and the second device may be located in a radio access network (RAN).

[0044] It should be noted that in the accompanying drawings of this application, the first device may be a UE or a network node (e.g., a base station (BS)), while the second device may be a network node (e.g., a BS) or a UE. However, this is for illustrative purposes only and is not intended to be limiting.

[0045] In some embodiments, the first device may establish multiple data bearer entities with the second device. Specifically, these multiple data bearer entities may be mapped to multiple IP streams. The mapping between the multiple data bearer entities and the multiple IP streams may be determined by either the first or the second device. In other words, the initiation of the mapping between the multiple data bearer entities and the multiple IP streams may be performed by either the first or the second device. Based on the result of mapping the multiple IP streams to the multiple data bearer entities, the first device can send and receive multiple packets associated with the multiple IP streams with the second device through the multiple data bearer entities.

[0046] In some implementations, the first and second devices can be located within the RAN. More specifically, the multiple data bearer entities can be established within the RAN without involving the CN, thereby reducing the signaling overhead and complexity associated with establishing multiple data bearer entities within the CN.

[0047] In some implementations, the multiple data bearer entities may include multiple sub-DRBs within a single data radio bearer (DRB). The multiple IP flows can be mapped to these sub-DRBs at the Packet Data Convergence Protocol (PDCP) layer. Specifically, the first device and the second device can establish multiple sub-DRBs within a single DRB. The first device may include a packet classification module at the PDCP layer. The first device can utilize this packet classification module to map the multiple IP flows to the multiple sub-DRBs. In some cases, the multiple IP flows can be mapped to the multiple sub-DRBs in a one-to-one manner.

[0048] In some implementations, each sub-DRB may have its own (i.e., its own independent) PDCP sequence number space (i.e., PDCP sequence number field). In some implementations, when a Radio Link Control (RLC) layer is present and the sub-DRB is applicable to the RLC layer, each sub-DRB may have its own (i.e., its own independent) RLC sequence number space (i.e., RLC sequence number field). In some implementations, when an RLC layer is present but the sub-DRB is not applicable to the RLC layer, the sub-DRB may be associated with the same RLC sequence number space. Furthermore, the PDCP packet data unit (PDU) header of a PDCP packet may include a field indicating the sub-DRB identifier, and the RLC packet data unit (PDU) header of an RLC packet may include a field indicating the sub-DRB identifier.

[0049] Figure 2Example scenario 200 is illustrated under a scheme implemented according to this disclosure. For example, the first device is a User Equipment (UE), and the second device is a Base Station (BS). The UE and the BS establish multiple sub-DRBs 0 to 3 within a single DRB. The UE includes a packet classification module at the PDCP / RLC layer. In some scenarios, an RLC layer is present. In some scenarios, an RLC layer is not present (e.g., in some sixth-generation (6G) networks). The UE uses this packet classification module to map multiple IP flows (e.g., background data, game data, VoIP data, and live streaming data) to multiple sub-DRBs 0 to 3. This IP flow corresponds to a Quality of Service (QoS) flow 0.

[0050] In this example, sub-DRBs 0 to 3 correspond to sub-DRB identifiers 0 to 3, respectively. The UE utilizes this packet classification module to classify packets transmitted and received with the BS through the Service Data Adaptation Protocol (SDAP) layer, the PDCP / RLC layer, and a sub-DRB of a DRB. When the packet header contains a field indicating the sub-DRB identifier 'A', the packet is transmitted and received through sub-DRB 'A'.

[0051] Each sub-DRB has its own independent Packet Data Convergence Protocol (PDCP) sequence number space. When a Radio Link Control (RLC) layer is present and the sub-DRB is applicable to the RLC layer, each sub-DRB has its own independent RLC sequence number space. When an RLC layer is present but the sub-DRB is not applicable to the RLC layer, all sub-DRBs share the same RLC sequence number space. In this example, packets transmitted and received through sub-DRB 0 have PDCP / RLC sequence numbers 0, 2, and 3 (represented by boxes). Packets transmitted and received through sub-DRB 1 have PDCP / RLC sequence number 0 (represented by a box). Packets transmitted and received through sub-DRB 2 have PDCP / RLC sequence numbers 0 and 1 (represented by boxes). Packets transmitted and received through sub-DRB 3 have PDCP / RLC sequence number 0 (represented by a box). A missing packet associated with sub-DRB 0 and having sequence number 1 will not affect IP stream packets transmitted through other sub-DRBs 1 through 3.

[0052] It is important to note that, in Figure 2 For ease of illustration, the packet classifier of the base station (BS) is omitted. However, this is not intended to limit the scope of this disclosure. The BS may also include a packet classifier configured to perform the operations described above.

[0053] Figure 3AExample scenario 300A is illustrated under the scheme according to the embodiments of this disclosure. For example, an RLC layer exists in a 6G network, and the sub-DRB is applicable to the RLC layer. Therefore, the packet transmission / reception architecture of the first / second device includes: (1) a PDU session entity, (2) a Traffic Flow Template (TFT) packet filtering entity, (3) a Service Data Adaptation Protocol (SDAP) entity with two Quality of Service (QoS) streams, the Quality of Service Stream Identifier (QFI) being 0 and 1, (4) a PDCP processing entity with identifiers 0 and 1, (5) an RLC processing entity with identifiers 0 to 3, (6) a 5G Media Access Control (MAC) processing entity with cell group CG 0, and (7) a 6G MAC processing entity with cell group CG 1.

[0054] The PDCP processing entity with identifier 0 has a packet classifier for classifying packets as: (a) sub-PDCP 0 based on the corresponding packet's 5-tuple 5T-0, (b) sub-PDCP 1 based on the corresponding packet's 5-tuple 5T-1, and (c) sub-PDCP 2 based on the corresponding packet's 5-tuple 5T-2. The PDCP processing entity with identifier 1 has a packet classifier for classifying packets as: (a) sub-PDCP 0 based on the corresponding packet's 5-tuple 5T-3, (b) sub-PDCP 1 based on the corresponding packet's 5-tuple 5T-4, and (c) sub-PDCP 2 based on the corresponding packet's 5-tuple 5T-5. At the PDCP layer, each sub-DRB has its own independent PDCP sequence number space.

[0055] RLC processing entities 0 to 3 are ordinary RLC entities. The RLC processing entity with identifier 1 processes the packet into sub-RLC 0 based on the corresponding packet's RLC header. The RLC processing entity with identifier 2 processes the packet as follows: (1) sub-RLC 0 based on the corresponding packet's RLC header, (2) sub-RLC 1 based on the corresponding packet's RLC header, and (3) sub-RLC 2 based on the corresponding packet's RLC header. At the RLC layer, each sub-DRB has its own independent RLC sequence number space.

[0056] The 5G MAC processing entity with cell group CG 0 has a logical channel (LC) for processing packets, and the LC identifier (LCID) is 0 or 1. The 6G MAC processing entity with cell group CG 1 has an LC, and the LCID is 0 or 1, for processing packets.

[0057] In this example, packets are passed from the PDU session entity to the TFT packet filtering entity. The TFT packet filtering entity filters packets into different QoS flows based on packet header fields (e.g., IP address, port number, protocol ID, flow tag, etc.). Packets are then passed from the SDAP entity to the PDCP processing entity via different QoS flows. The packet classifier of the PDCP processing entity classifies packets into different sub-PDCPs based on the corresponding packet's five-tuple. Packets are then passed from the PDCP processing entity to the RLC processing entity based on bearer identification information (e.g., DRB identifiers or sub-DRB identifiers determined by the packet classifier). Finally, packets are passed from the RLC processing entity to the LC of the 5G / 6G MAC processing entity based on the LCID.

[0058] Figure 3B Example scenario 300B is illustrated under the scheme according to the embodiments of this disclosure. For example, an RLC layer exists, but the sub-DRB is not applicable to the RLC layer. Therefore, the packet transmission / reception architecture of the first / second device includes: (1) a PDU session entity, (2) a TFT packet filtering entity, (3) an SDAP entity with two QoS streams, QFI 0 and 1, (4) a PDCP processing entity with identifiers 0 and 1, (5) an RLC processing entity with identifiers 0 to 3, (6) a 5G MAC processing entity with cell group CG 0, and (7) a 6G MAC processing entity with cell group CG 1.

[0059] The PDCP processing entity with identifier 0 has a packet classifier for classifying packets as: (a) sub-PDCP 0 based on the corresponding packet's 5-tuple 5T-0, (b) sub-PDCP 1 based on the corresponding packet's 5-tuple 5T-1, and (c) sub-PDCP 2 based on the corresponding packet's 5-tuple 5T-2. The PDCP processing entity with identifier 1 has a packet classifier for classifying packets as: (a) sub-PDCP 0 based on the corresponding packet's 5-tuple 5T-3, (b) sub-PDCP 1 based on the corresponding packet's 5-tuple 5T-4, and (c) sub-PDCP 2 based on the corresponding packet's 5-tuple 5T-5. At the PDCP layer, each sub-DRB has its own independent PDCP sequence number space.

[0060] In this example, the sub-DRBs are not applicable to the RLC layer. Therefore, all sub-DRBs share the same RLC sequence number space. RLC processing entities with identifiers 0 to 3 process packets in a normal manner based on the corresponding packet's RLC header.

[0061] The 5G MAC processing entity with cell group CG 0 has LCID 0 and 1 for packet processing. The 6G MAC processing entity with cell group CG1 has LC, with LCID 0 and 1, for packet processing.

[0062] In this example, packets are passed from the PDU session entity to the TFT packet filtering entity. The TFT packet filter filters packets into different Quality of Service (QoS) streams based on packet header fields (e.g., IP address, port number, protocol ID, flow tag, etc.). Packets are then passed from the Serving Data Adaptation Protocol (SDAP) entity to the Packet Data Convergence Protocol (PDCP) processing entity via different QoS streams. The PDCP processing entity's packet classifier classifies packets into different sub-PDCPs based on the corresponding packet's five-tuple. Packets are then passed from the PDCP processing entity to the Radio Link Control (RLC) processing entity based on bearer identification information (e.g., Data Radio Bearer (DRB) identifiers or sub-DRB identifiers determined by the packet classifier). Finally, packets are passed from the RLC processing entity to the logical channel (LC) of the 5G / 6G Media Access Control (MAC) processing entity based on the Logical Channel Identifier (LCID).

[0063] Figure 3C An example scenario 300C under the scheme according to an embodiment of the present disclosure is shown. For example, the RLC layer does not exist in the 6G network. Therefore, the packet transmission / reception architecture of the first / second device includes: (1) a PDU session entity, (2) a TFT packet filtering entity, (3) an SDAP entity with two QoS streams (QFI 0 and 1), (4) a PDCP processing entity with identifiers 0 and 1, (5) an RLC processing entity associated with the 5G network with identifiers 0 and 3, (6) a 5G MAC processing entity with cell group CG 0, and (7) a 6G MAC processing entity with cell group CG 1.

[0064] The PDCP processing entity with identifier 0 has a packet classifier for classifying packets as: (a) sub-PDCP 0 based on the corresponding packet's quintuple 5T-0, (b) sub-PDCP 1 based on the corresponding packet's quintuple 5T-1, and (c) sub-PDCP 2 based on the corresponding packet's quintuple 5T-2. The PDCP processing entity with identifier 1 has a packet classifier for classifying packets as: (a) sub-PDCP 0 based on the corresponding packet's quintuple 5T-3, (b) sub-PDCP 1 based on the corresponding packet's quintuple 5T-4, and (c) sub-PDCP 2 based on the corresponding packet's quintuple 5T-5. Within the PDCP layer, each sub-DRB has its own independent PDCP sequence number space.

[0065] In this example, the RLC layer does not exist in the 6G network. Therefore, the sub-DRBs associated with the 5G network share the same RLC sequence number space, and only the RLC processing entities associated with the 5G network and identified as 0 and 3 process packets normally according to the RLC header of the corresponding packet.

[0066] The 5G MAC processing entity with cell group CG 0 has logical channels with LCIDs of 0 and 1 for packet processing. The 6G MAC processing entity with cell group CG 1 has logical channels with LCIDs of 0 and 1 for packet processing.

[0067] In this example, packets are passed from the PDU session entity to the TFT packet filtering entity. The TFT packet filter filters packets into different QoS flows based on packet header fields (e.g., IP address, port number, protocol ID, flow tag, etc.). Packets are then passed from the SDAP entity to the PDCP processing entity via different QoS flows. The packet classifier of the PDCP processing entity classifies packets into different sub-PDCPs based on the corresponding packet's five-tuple. Packets are then passed from the PDCP processing entity to the RLC processing entity based on bearer identification information (e.g., DRB identifier or sub-DRB identifier determined by the packet classifier). Finally, packets are passed from the RLC processing entity to the logical channel of the 5G / 6G MAC processing entity based on the LCID.

[0068] It should be noted that Figures 3A to 3C The packet transmission paths (indicated by arrowed lines) are shown for illustrative purposes only. However, this is not intended to limit the scope of this disclosure. Any possible path may be used depending on the network scenario.

[0069] Figures 4A to 4C Example scenarios 400A to 400C are shown under the scheme according to embodiments of this disclosure. In particular, the PDCP PDU header of the PDCP data PDU may include a field for indicating the sub-DRB identifier.

[0070] exist Figure 4A In this context, PDCP data PDUs can contain types with 12-bit PDCP sequence numbers. PDCP data PDUs can also contain types with 18-bit PDCP sequence numbers.

[0071] exist Figure 4B In this context, PDCP data PDUs can contain types with 12-bit PDCP sequence numbers, and can also include spliced ​​and split PDCP splicing information headers.

[0072] exist Figure 4CIn this context, PDCP data PDUs can contain types with 18-bit PDCP sequence numbers, and can also include PDCP splicing information headers that are both spliced ​​and split.

[0073] Figure 5 Example scenario 500 is illustrated under the scheme according to the embodiments of this disclosure. In particular, the PDCP PDU header of the PDCP control PDU may include a field for indicating the sub-DRB identifier.

[0074] Figures 6A to 6C Example scenarios 600A to 600C under the scheme according to embodiments of this disclosure are shown. In particular, the RLC PDU header of the RLC data PDU may include a field for indicating the sub-DRB identifier.

[0075] exist Figure 6A In this context, RLC data PDUs may include Unacknowledged Mode Data (UMD) PDUs and have complete RLC Service Data Units (SDUs).

[0076] exist Figure 6B In RLC data PDUs, a UMD PDU with a 6-bit sequence number and no segmentation offset (SO) can be included. A UMD PDU with a 6-bit sequence number and an SO can also be included. A UMD PDU with a 12-bit sequence number and no SO can also be included. A UMD PDU with a 12-bit sequence number and an SO can also be included.

[0077] exist Figure 6C In this context, an RLC data PDU can contain an Acknowledged Mode Data (AMD) PDU with a 12-bit serial number and no SO. An RLC data PDU can contain an AMD PDU with a 12-bit serial number and an SO. An RLC data PDU can contain an AMD PDU with an 18-bit serial number and no SO. An RLC data PDU can contain an AMD PDU with an 18-bit serial number and an SO.

[0078] Figure 7 An example scenario 700 is illustrated under a scheme according to an embodiment of this disclosure. Specifically, the RLC control PDU in the Radio Link Control (RLC) Packet Data Unit (PDU) header may include a field for indicating the sub-Data Radio Bearer (sub-DRB) identifier.

[0079] It should be noted that in the figure: (1) the “Sub-DRB Identifier” field indicates the identifier of the corresponding sub-DRB; (2) the “R” field indicates a reserved bit field, which can be set to a predetermined value (e.g., 0), and may not be currently used; (3) the “SN” field indicates the sequence number, which can be used to identify the transmission order of PDUs or Service Data Units (SDUs) for purposes such as reordering, duplicate detection, and retransmission; (4) the “D / C” field indicates the data / control indicator, which can indicate whether the PDU is a data PDU or a control PDU; (5) the “Data” field indicates the payload part of the PDU; (6) the “MAC-I” field indicates the integrity protection message authentication code, which is used to verify the integrity of the corresponding PDU; (7) the “PDCP splicing information” field indicates that multiple Packet Data Convergence Protocol (PDCP) SDUs are spliced ​​into a single PDCP PDU, or that PDCP SDUs are consecutive across multiple PDUs; (8) the “SDU type” field indicates the type of SDU contained in the PDU, such as SDUs corresponding to user plane data, control plane data, or other categories; (9) The “SI” field indicates segmentation information, indicating whether the payload corresponds to a complete SDU, the first segment, the middle segment, or the last segment of the SDU; (10) The “SO” field indicates segmentation offset, indicating the relative starting position of the PDU payload within the corresponding SDU when segmentation occurs; (11) The “P” field indicates polling bit, which can be used to trigger the receiving entity to send a status report or acknowledgment; (12) The “CPT” field indicates control PDU type, indicating the specific control information type carried by the control PDU.

[0080] It is important to note that Figures 4A to 7 The "Sub-DRB Identifier" field shown is for illustrative purposes only. This illustration does not limit the placement of the "Sub-DRB Identifier" field, which can be set in different locations within the header depending on the implementation or network configuration.

[0081] In some implementations, the plurality of data bearer entities may include a plurality of data radio bearers (DRBs). The plurality of Internet Protocol (IP) streams may be mapped to the plurality of DRBs at the Serving Data Adaptation Protocol (SDAP) layer. Specifically, the first device may establish the plurality of DRBs with the second device. The first device may include a packet classification module at the SDAP layer. The first device may use the packet classification module to map the plurality of IP streams to the plurality of DRBs. In some cases, the plurality of IP streams may be mapped to the plurality of DRBs in a one-to-one manner.

[0082] In some implementations, each DRB may be associated with a Packet Data Convergence Protocol (PDCP) sequence number space and a Radio Link Control (RLC) sequence number space. In other words, each DRB may have its own independent PDCP entity and PDCP sequence number space (i.e., PDCP sequence number field) and RLC entity and RLC sequence number space (i.e., RLC sequence number field).

[0083] Figure 8 An example scenario 800 is illustrated under a scheme according to an embodiment of this disclosure. For example, the first device is a user equipment (UE), and the second device is a base station (BS). The UE establishes multiple DRBs 0 to 3 with the BS. The UE includes a packet classification module at the SDAP layer. The UE uses this packet classification module to map multiple IP streams (e.g., background data, game data, VoIP data, and live data) to the multiple DRBs 0 to 3. The IP stream corresponds to QoS stream 0.

[0084] In this example, DRBs 0 to 3 correspond to DRB IDs 0 to 3, respectively. The UE uses this packet classification module to classify packets sent and received with the BS through the SDAP layer, PDCP / RLC layer, and DRB.

[0085] Each DRB has a corresponding PDCP entity and RLC entity. Each DRB has its own independent PDCP sequence number space and RLC sequence number space. In this example, packets sent and received through DRB 0 have PDCP / RLC sequence numbers 0, 2, and 3 (represented by boxes). Packets sent and received through DRB 1 have PDCP / RLC sequence number 0 (represented by a box). Packets sent and received through DRB 2 have PDCP / RLC sequence numbers 0 and 1 (represented by boxes). Packets sent and received through DRB 3 have PDCP / RLC sequence number 0 (represented by a box). The missing packet with sequence number 1 associated with DRB 0 will not affect the transmission of IP flow packets on other DRBs 1 through 3.

[0086] It is important to note that, in Figure 8 For ease of explanation, the packet classifier of the BS has been omitted. However, this does not limit the scope of this disclosure. The BS may also include a packet classifier configured to perform the above operations.

[0087] Figure 9Example scenario 900 is shown under the scheme according to the embodiments of the present disclosure. For example, the packet transmission / reception architecture of the first / second device includes: (1) a PDU session entity, (2) a Traffic Flow Template (TFT) packet filtering entity, (3) an SDAP entity having two QoS flows and QoS Flow Identifiers (QFI) of 0 and 1, (4) a PDCP processing entity with identifiers of 0 to 5, (5) an RLC processing entity with identifiers of 0 to 7, (6) a 5G MAC processing entity having cell group CG 0, and (7) a 6G MAC processing entity having cell group CG 1.

[0088] The SDAP entity has a packet classifier for classifying PDCP entities 0 to 5 according to 5-tuples (5T) 5T-0 to 5T-5. PDCP processing entities 0 to 5 are ordinary PDCP entities. RLC processing entities 0 to 7 are ordinary RLC entities. The 5G MAC processing entity with cell group CG 0 has logical channels (LCs) with LCIDs 0 to 3 for packet processing. The 6G MAC processing entity with cell group CG 1 has logical channels with LCIDs 0 to 3 for packet processing.

[0089] In this example, packets are passed from the PDU session entity to the TFT packet filtering entity. The TFT packet filter filters packets into different Quality of Service (QoS) flows based on packet header fields (e.g., IP address, port number, protocol ID, flow tag, etc.). The packet classifier of the SDAP entity classifies packets for different PDCP processing entities based on the corresponding packet's five-tuple. Packets are passed from the PDCP processing entity to the RLC processing entity based on bearer identification information (e.g., DRB identifier). Packets are passed from the RLC processing entity to the LC of the 5G / 6G MAC processing entity based on the LCID.

[0090] It should be noted that Figure 9 The packet transmission paths indicated by arrowed lines are shown for ease of understanding only. However, this is not intended to limit the scope of this disclosure. Any possible path may be used depending on the different network scenarios.

[0091] In some implementations, during the establishment process of a data bearer entity (e.g., a sub-DRB or DRB in the RAN), the first or second device may notify the other device of the maximum number of data bearer entities and / or the permitted service types (e.g., gaming, VoIP, and live streaming).

[0092] In some implementations, the first device can identify a specific IP flow. The first device can exchange information with the second device regarding mapping that specific IP flow to a corresponding data bearer entity. The first device can establish that corresponding data bearer entity with the second device. In some cases, the first device can establish multiple data bearer entities with the second device, and these data bearer entities can be mapped to corresponding IP flows according to the aforementioned operations.

[0093] Figure 10 An example scenario 1000 under a scheme according to an embodiment of this disclosure is illustrated. For example, the first device is a user equipment (UE), and the second device is a base station (BS). The BS transmits a configuration of a data bearer entity to the UE. This configuration includes a radio resource control (RRC) configuration and a DRB configuration. The DRB configuration includes information for establishing a default DRB. Subsequently, the BS and the UE establish a default data bearer entity 0 (e.g., a sub-DRB or DRB) according to this configuration.

[0094] In addition, the BS identifies a specific IP flow (e.g., gaming service). The BS transmits the configuration of Data Bearer Entity 1 to the UE. This configuration includes RRC configuration and DRB configuration. The DRB configuration includes at least one of the following: DRB establishment information, packet classifier information, and service type. The packet classifier information includes information that maps Data Bearer Entity 1 to a specific IP flow (e.g., a 5-tuple). Subsequently, the BS and the UE establish Data Bearer Entity 1 (e.g., a sub-DRB or DRB) according to this configuration.

[0095] In addition, the BS identifies a specific IP flow (e.g., VoIP service). The BS transmits the configuration of Data Bearer Entity 2 to the UE. This configuration includes an RRC configuration with DRB configuration. The DRB configuration includes at least one of the following: DRB establishment information, packet classifier information, and service type. The packet classifier information includes information that maps Data Bearer Entity 2 to a specific IP flow (e.g., a 5-tuple). Subsequently, the BS and the UE establish Data Bearer Entity 2 (e.g., a sub-DRB or a DRB) according to this configuration.

[0096] Figure 11 An example scenario 1100 under a scheme according to an embodiment of this disclosure is illustrated. For example, the first device is a UE, and the second device is a BS. The BS transmits a configuration of data bearer entities to the UE. This configuration includes an RRC configuration with a DRB configuration. The DRB configuration includes information for establishing a default DRB, the maximum number of data bearer entities, and allowed service types (e.g., gaming, VoIP, and live streaming). Subsequently, the BS and the UE establish a default data bearer entity 0 (e.g., a sub-DRB or DRB) according to this configuration.

[0097] In addition, the UE identifies a specific IP flow (e.g., a gaming service). The UE transmits information about the specific IP flow to the BS (e.g., 5-tuple information and the service type associated with the specific IP flow). This information is contained in RRC signaling (e.g., UE assistance information) or Layer 2 control messages (e.g., MAC control elements (MAC CE)). Upon receiving the specific IP flow information, the BS approves the establishment of the data bearer entity associated with the specific IP flow. The BS transmits the configuration of data bearer entity 1 to the UE. This configuration includes an RRC configuration with a DRB configuration. The DRB configuration includes at least one of the following: DRB establishment information, packet classifier information, and service type. The packet classifier information includes information mapping data bearer entity 1 to the specific IP flow (e.g., 5-tuple). Subsequently, the BS and the UE establish data bearer entity 1 (e.g., a sub-DRB or a DRB) according to this configuration.

[0098] In addition, the UE identifies a specific IP flow (e.g., VoIP service). The UE transmits information about the specific IP flow to the BS (e.g., 5-tuple information and the service type associated with the specific IP flow). This information is contained in RRC signaling (e.g., UE assistance information) or Layer 2 control messages (e.g., MAC CE). Upon receiving the specific IP flow information, the BS approves the establishment of the data bearer entity associated with the specific IP flow. The BS transmits the configuration of data bearer entity 2 to the UE. This configuration includes an RRC configuration with a DRB configuration. The DRB configuration includes at least one of the following: DRB establishment information, packet classifier information, and service type. The packet classifier information includes information mapping data bearer entity 2 to the specific IP flow (e.g., 5-tuple). Subsequently, the BS and the UE establish data bearer entity 2 (e.g., a sub-DRB or a DRB) according to this configuration.

[0099] In some implementations, the first device can identify a specific IP flow. The first device can establish a corresponding data bearer entity with the second device that is mapped to that specific IP flow. In some cases, the first device can establish multiple data bearer entities with the second device, and these data bearer entities can be mapped to corresponding IP flows according to the aforementioned operations.

[0100] Figure 12 An example scenario 1200 under a scheme according to an embodiment of this disclosure is illustrated. For example, the first device is a UE, and the second device is a BS. The BS transmits a configuration of data bearer entities to the UE. This configuration includes an RRC configuration with a DRB configuration. The DRB configuration includes information for establishing a default DRB and the maximum number of data bearer entities. Subsequently, the BS and the UE establish a default data bearer entity 0 (e.g., a sub-DRB or DRB) according to this configuration.

[0101] In addition, the BS identifies a specific IP flow (e.g., gaming service). Subsequently, the BS establishes a data bearer entity 1 (e.g., a sub-DRB or DRB) with the UE. Data bearer entity 1 is mapped to that specific IP flow.

[0102] Furthermore, the base station (BS) identifies a specific IP flow (e.g., VoIP service). The base station then establishes a data bearer entity 2 (e.g., a sub-DRB or a data radio bearer (DRB)) with the user equipment (UE). Data bearer entity 2 is mapped to that specific IP flow.

[0103] Figure 13 An example scenario 1300 under a scheme according to an embodiment of this disclosure is illustrated. For example, the first device is a UE, and the second device is a BS. The BS sends a configuration of a data bearer entity to the UE. This configuration includes a Radio Resource Control (RRC) configuration with a DRB configuration. The DRB configuration includes information for default DRB establishment, the maximum number of data bearer entities, and allowed service types (e.g., gaming, VoIP, and live streaming). The BS and the UE then establish a default data bearer entity 0 (e.g., sub-DRB or DRB) based on this configuration.

[0104] In addition, the UE identifies a specific IP flow (e.g., gaming service). Then, the BS establishes a data bearer entity 1 (e.g., sub-DRB or DRB) with the UE. Data bearer entity 1 is mapped to that specific IP flow.

[0105] In addition, the BS identifies a specific IP flow (e.g., VoIP service). Then, the BS establishes a data bearer entity 2 (e.g., sub-DRB or DRB) with the UE. Data bearer entity 2 is mapped to that specific IP flow.

[0106] In some implementations, the first device may be configured to send and receive a data bearer entity with the second device. This configuration may include hash functions that map multiple data bearer entities to multiple IP streams. The first device may establish multiple data bearer entities with the second device.

[0107] Figure 14 An example scenario 1400 is illustrated under a scheme according to an embodiment of this disclosure. For example, the first device is a UE, and the second device is a BS. The BS sends a configuration of data bearer entities to the UE. This configuration includes an RRC configuration with DRB configuration. The DRB configuration includes information for default DRB establishment, the maximum number of data bearer entities, and a hash function that maps multiple data bearer entities (e.g., sub-DRBs or DRBs) to multiple IP flows. The BS and the UE then establish multiple data bearer entities based on this configuration.

[0108] More specifically, a hash function is used to map information about a specific IP stream (e.g., the 5-tuple information associated with a specific IP stream) to the corresponding data bearer entity. In other words, the hash function receives information about a specific IP stream and outputs the identifier of the corresponding data bearer entity. Therefore, the UE and BS use this hash function to send and receive data for a specific IP stream through the corresponding data bearer entity.

[0109] In some implementations, the first device may perform at least one PDCP PDU processing operation, an RLC PDU processing operation, and a switching operation for each data bearer entity.

[0110] In some cases, PDCP PDU processing operations may include at least one of the following: PDCP transmit / receive (TRX) operations, PDCP discard operations, PDCP data recovery operations, PDCP reordering operations, PDCP encryption operations, PDCP integrity operations, PDCP protection operations, PDCP header compression operations, and PDCP UDC operations.

[0111] In some cases, RLC PDU processing operations may include at least one of the following: RLC transmit / receive (TRX) operations and RLC automatic repeat request (ARQ) operations. Figure 15 An example scenario 1500 under a scheme according to an embodiment of this disclosure is illustrated. For example, the first device is a UE, and the second device is a BS. The BS sends RLC PDUs to the UE via data bearer entities 0 and 1. Regarding data bearer entity 0, RLC PDUs include 50 to 54, wherein RLC PDUs 51 to 53 are successfully received, and RLC PDUs 50 and 54 are lost. Regarding data bearer entity 1, RLC PDUs include 32 to 36, wherein RLC PDUs 32, 33, 34, and 36 are successfully received, and RLC PDU 35 is lost.

[0112] Subsequently, the UE generates an RLC status report associated with data bearer entity 0, which contains information about the lost RLC PDUs 50 and 54. The UE generates an RLC status report associated with data bearer entity 1, which contains information about the lost RLC PDU 35. Then, the UE sends RLC status reports corresponding to the respective data bearer entities 0 and 1, thereby achieving independent acknowledgment and retransmission control for each data bearer entity. Upon receiving the RLC status report, the BS retransmits: (1) the lost RLC PDUs 50 and 54 for data bearer entity 0, and (2) the lost RLCPDU 35 for data bearer entity 1.

[0113] In some cases, the switching operation may include a lossless switching operation. Figure 16An example scenario 1600 under a scheme according to an embodiment of this disclosure is illustrated. For example, the first device is a UE, and the second device is a BS. The BS sends PDCP PDUs to the UE via data bearer entities 0 and 1. Regarding data bearer entity 0, PDCP PDUs include 50 to 54, of which PDCP PDUs 51 to 53 are successfully received, and PDCP PDUs 50 and 54 are lost. Regarding data bearer entity 1, PDCP PDUs include 32 to 36, of which PDCP PDUs 32, 34, and 36 are successfully received, PDCP PDU 33 is successfully received but not successfully acknowledged, and PDCP PDU 35 is lost.

[0114] Then, the BS sends a handover configuration to the UE to enable the UE to hand over from the BS to another BS. The BS forwards information of unacknowledged PDCP PDUs (i.e., PDCP PDUs 50 and 54 via data bearer entity 0, and PDCP PDU 35 via data bearer entity 1).

[0115] Next, the UE switches to another BS and sends a handover completion message to that BS. The UE generates a PDCP status report associated with data bearer entity 0, which contains information about the received PDCP PDUs 51 to 53. The UE generates a PDCP status report associated with data bearer entity 1, which contains information about the received PDCP PDUs 32, 33, 34, and 36. Then, the UE sends PDCP status reports corresponding to the respective data bearer entities 0 and 1, thereby achieving independent acknowledgment and retransmission control for each data bearer entity. Upon receiving the PDCP status report, the BS retransmits: (1) lost PDCP PDUs 50 and 54 via data bearer entity 0, and (2) lost PDCP PDU 35 via data bearer entity 1.

[0116] Exemplary Implementation

[0117] Figure 17 An example communication system 1700 is shown, having an example first device 1710 and an example second device 1720, according to an embodiment of this disclosure. The first device 1710 and the second device 1720 are capable of performing various functions to implement the schemes, techniques, processes, and methods described herein, relating to the transmission and reception of packets in mobile communications via data bearer entities established in a radio access network (RAN), including the scenarios / schemes described above and the process 1800 described below.

[0118] The first device 1710 / second device 1720 may be part of an electronic device, which may be a user equipment (UE), such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, the first device 1710 / second device 1720 may be implemented in a smartphone, smartwatch, personal digital assistant, digital camera, or computing device (such as a tablet, laptop, or mobile phone). The first device 1710 / second device 1720 may also be part of a machine-type device, which may be an Internet of Things (IoT), Narrowband Internet of Things (NB-IoT), or Industrial Internet of Things (IIoT) device, such as a non-movable or fixed device, a home device, a wired communication device, or a computing device. For example, the first device 1710 / second device 1720 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center.

[0119] The first device 1710 / second device 1720 may be part of a network device, which may be a network node, such as a satellite, base station, small cell, router, or gateway. For example, the first device 1710 / second device 1720 may be implemented in an eNodeB in an LTE network, a gNB in ​​a 5G / New Radio (NR), IoT, NB-IoT, or IIoT network, or a satellite or base station in a 6G network.

[0120] Alternatively, the first device 1710 / second device 1720 may be implemented as one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more Reduced Instruction Set Computing (RISC) processors, or one or more Complex Instruction Set Computing (CISC) processors. The first device 1710 / second device 1720 may include... Figure 17 At least some components are shown, such as processors 1712 / 1722. The first device 1710 / second device 1720 may also include one or more other components unrelated to this disclosure (e.g., internal power supply, display device, and / or user interface device); therefore, for the sake of simplicity and conciseness, Figure 17 These components of the first device 1710 / second device 1720 are not shown and are not described below.

[0121] In one aspect, each of processors 1712 and 1722 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, although the singular term "processor" is used herein to refer to processors 1712 and 1722, in some embodiments of this disclosure, each of processors 1712 and 1722 may comprise multiple processors, and in other embodiments may comprise a single processor. In another aspect, each of processors 1712 and 1722 may be implemented in hardware (and optionally firmware) comprising, for example, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more transformers, these electronic components being configured and arranged to achieve the specific purposes of this disclosure. In other words, in at least some embodiments, each of processors 1712 and 1722 is a dedicated machine specifically designed, arranged, and configured to perform a particular task, including sending and receiving packets in a device (e.g., represented by the first device 1710 / second device 1720) and a network (e.g., represented by the first device 1710 / second device 1720) via data bearer entities established in a radio access network (RAN), according to various embodiments of this disclosure.

[0122] In some embodiments, the first device 1710 / second device 1720 may further include a transceiver 1716 / 1726 coupled to the processor 1712 / 1722, and capable of wirelessly transmitting and receiving data. In other words, the processor 1712 / 1722 can transmit and receive data, such as configurations, messages, signals, information, instructions, etc., through the transceiver 1716 / 1726. In some embodiments, the first device 1710 / second device 1720 may further include a memory 1714 / 1724 coupled to the processor 1712 / 1722, accessible by the processor 1712 / 1722, and capable of storing data. Therefore, the first device 1710 and the second device 1720 can wirelessly communicate through the transceiver 1716 and transceiver 1726, respectively. For ease of understanding, the following description of the operation, function and capability of the first device 1710 and the second device 1720 is provided in the context of a mobile communication environment, wherein the first device 1710 / second device 1720 is implemented as a communication device or user equipment (UE), and the first device 1710 / second device 1720 is implemented as a network node of a communication network.

[0123] In some embodiments, each of memory 1714 and memory 1724 may include a random access memory (RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero-capacitance RAM (Z-RAM). Alternatively, each of memory 1714 and memory 1724 may include a read-only memory (ROM), such as a mask ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), and / or electrically erasable programmable ROM (EEPROM). Alternatively, each of memory 1714 and memory 1724 may include a non-volatile random access memory (NVRAM), such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and / or phase-change memory.

[0124] Example Process

[0125] Figure 18 An example flow 1800 of an embodiment of this disclosure is illustrated. Flow 1800 may be an example implementation of some or all of the above-described scenarios / solutions, involving the transmission and reception of packets via a data bearer entity established in a radio access network (RAN). This flow 1800 may represent one aspect of the functional implementation of the first device 1710. Flow 1800 may include one or more operations, actions, or functions as shown in blocks 1810 and 1820. Although shown as separate blocks, the blocks of flow 1800 may be divided into more blocks, merged into fewer blocks, or omitted depending on the desired implementation. Furthermore, the blocks of flow 1800 may be arranged according to... Figure 18 The process can be executed in the order shown, or in a different order. Process 1800 can be implemented by the first device 1710 or any applicable user equipment (UE), network node, or machine type device. For illustrative purposes only and without limitation, process 1800 is described below with reference to the first device 1710. Process 1800 may begin with block 1810.

[0126] In block 1810, process 1800 may involve the processor 1712 of the first device 1710 establishing multiple data bearer entities with another device (e.g., the second device 1720). These multiple data bearer entities may be mapped to multiple Internet Protocol (IP) streams. The first device 1710 and the other device may be located in a Radio Access Network (RAN). Process 1800 may continue from block 1810 to block 1820.

[0127] In block 1820, process 1800 may involve the processor 1712 of the first device 1710 sending and receiving multiple packets associated with the multiple IP streams through the multiple data bearer entities based on the result of mapping the multiple IP streams to the multiple data bearer entities.

[0128] In some implementations, the plurality of data bearer entities may include a plurality of sub-DRBs within a data radio bearer (DRB), and the plurality of IP streams are mapped to the plurality of sub-DRBs at the Packet Data Convergence Protocol (PDCP) layer.

[0129] In some implementations, the PDCP packet data unit (PDU) header of a PDCP packet may include a field for indicating a sub-DRB identifier, and the RLC packet data unit (PDU) header of a Radio Link Control (RLC) packet may include a field for indicating a sub-DRB identifier.

[0130] In some implementations, each sub-DRB may be associated with a PDCP sequence number space. Where an RLC layer exists and the sub-DRB is applied to that RLC layer, each sub-DRB may be associated with a corresponding Radio Link Control (RLC) sequence number space; where an RLC layer exists but the sub-DRB is not applied to that RLC layer, the sub-DRB may be associated with the same RLC sequence number space.

[0131] In some implementations, the plurality of data bearer entities may include a plurality of data radio bearers (DRBs), and the plurality of IP streams are mapped to the plurality of DRBs at the Serving Data Adaptation Protocol (SDAP) layer.

[0132] In some implementations, each DRB may be associated with a PDCP sequence number space and a Radio Link Control (RLC) sequence number space.

[0133] In some implementations, process 1800 may further involve the processor 1712 of the first device 1710 determining a specific IP flow. Process 1800 may further involve the processor 1712 exchanging information with the other device to map the specific IP flow to a corresponding data bearer entity. Process 1800 may further involve the processor 1712 establishing the corresponding data bearer entity with the other device.

[0134] In some implementations, process 1800 may further involve processor 1712 of the first device 1710 determining a specific IP flow. Process 1800 may further involve processor 1712 establishing a corresponding data bearer entity with the other device, wherein the corresponding data bearer entity is mapped to the specific IP flow.

[0135] In some implementations, process 1800 may further involve configuring the processor 1712 of the first device 1710 to send and receive the plurality of data bearer entities, wherein the configuration includes a hash function that maps the plurality of data bearer entities to the plurality of IP streams. Process 1800 may further involve the processor 1712 establishing the plurality of data bearer entities with the other device.

[0136] In some implementations, process 1800 may further involve the processor 1712 of the first device 1710 performing at least one of Packet Data Convergence Protocol (PDCP) Packet Data Unit (PDU) processing operations, Radio Link Control (RLC) PDU processing operations, and lossless handover operations for each data bearer entity.

[0137] Additional Notes

[0138] The topics described herein sometimes demonstrate that different components are contained within or connected to other different components. It should be understood that such architectures are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” to achieve the desired function. Therefore, any two components combined in this document to achieve a specific function can be considered “associated with each other” to achieve the desired function, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to achieve the desired function, and any two components that can be suchly associated can also be considered “operably coupled” to achieve the desired function. Specific examples of operational coupling include, but are not limited to, physically matable and / or physically interactive components, wirelessly interactive and / or wirelessly interactive components, and logically interactive and / or logically interactive components.

[0139] Furthermore, regarding the use of almost all plural and / or singular terms in this document, those skilled in the art can appropriately convert from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations and combinations may be explicitly listed herein.

[0140] Furthermore, those skilled in the art will understand that terms commonly used herein, particularly in appended claims, such as the body portion of appended claims, are generally considered "open-ended" terms. For example, the word "comprising" should be interpreted as "including but not limited to," "having" should be interpreted as "having at least," and "including" should be interpreted as "including but not limited to," etc. Those skilled in the art will also further understand that if a particular quantity introduced in a claim is intentional, that intention will be explicitly stated in the claim; if it is not stated, then that intention does not exist. For example, for ease of understanding, the following appended claims may contain the use of the introductory phrases "at least one" and "one or more" to introduce the content of the claim. However, the use of such phrases should not be construed as limiting any particular claim containing that content to containing only one instance of that content when the content of the claim is introduced by the indefinite article "a," even if the same claim contains the introductory phrases "one or more" or "at least one" and indefinite articles such as "a," for example, "a" should be interpreted as "at least one" or "one or more"; the same applies to definite articles used to introduce the content of the claim. Furthermore, even if a specific number of introduced elements is explicitly stated in the claims, those skilled in the art will recognize that such a statement should be interpreted as at least the number stated. For example, the phrase "two elements" alone, without further modification, implies at least two elements, or two or more elements. Additionally, when using conventions such as "at least one A, B, and C," such structures should generally be interpreted in the way that those skilled in the art understand the convention. For example, "a system having at least one A, B, and C" includes, but is not limited to, systems with only A, only B, only C, A and B, A and C, B and C, and systems where A, B, and C coexist. Similarly, when using conventions such as "at least one A, B, or C," such structures should generally be interpreted in the way that those skilled in the art understand the convention. For example, "a system having at least one A, B, or C" includes, but is not limited to, systems with only A, only B, only C, A and B, A and C, B and C, and systems where A, B, and C coexist. Those skilled in the art will further understand that virtually any separable term and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to include the possibility of including one, any, or both terms. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B” or “A and B”.

[0141] As can be seen from the foregoing, various embodiments of this disclosure have been described for illustrative purposes, and various modifications can be made without departing from the scope and spirit of this disclosure. Therefore, the various embodiments disclosed herein are not intended to be limiting, and the true scope and spirit are defined by the following claims.

Claims

1. A method comprising: The processor of the device establishes multiple data bearer entities with another device, wherein the multiple data bearer entities are mapped to multiple Internet Protocol streams, and wherein the device and the other device are located in a wireless access network; as well as Based on the result of mapping the multiple Internet Protocol streams to the multiple data bearer entities, the processor sends and receives multiple packets associated with the multiple Internet Protocol streams with the other device through the multiple data bearer entities.

2. The method of claim 1, wherein, The plurality of data bearer entities include a plurality of sub-data radio bearers within a data radio bearer, wherein the plurality of Internet Protocol streams are mapped to the plurality of sub-data radio bearers at the packet data convergence protocol layer.

3. The method of claim 2, wherein, The Packet Data Convergence Protocol (PDCP) packet data unit header contains a field for indicating the sub-data radio bearer identifier, and the Radio Link Control (RANC) packet data unit header contains a field for indicating the sub-data radio bearer identifier.

4. The method of claim 2, wherein, Each sub-data radio bearer is associated with a packet data aggregation protocol sequence number space. In the presence of a radio link control layer and where the sub-data radio bearer is applied to the radio link control layer, each sub-data radio bearer is associated with a corresponding radio link control sequence number space. In the presence of a radio link control layer but where the sub-data radio bearer is not applied to the radio link control layer, the sub-data radio bearer is associated with the same radio link control sequence number space.

5. The method of claim 1, wherein, The plurality of data bearer entities include a plurality of data radio bearers, and wherein the plurality of Internet Protocol streams are mapped to the plurality of data radio bearers at the Service Data Adaptor Protocol layer.

6. The method of claim 5, wherein, Each data radio bearer is associated with a packet data aggregation protocol sequence number space and a radio link control sequence number space.

7. The method of claim 1, wherein, Establishing the plurality of data bearer entities with the other device further includes: The processor determines the specific Internet Protocol (IP) flow; The processor exchanges information with the other device mapping a specific Internet Protocol stream to the corresponding data bearer entity; and The processor establishes the corresponding data carrier entity with the other device.

8. The method of claim 1, wherein, Establishing the plurality of data bearer entities with the other device further includes: The processor determines the specific Internet Protocol (IP) stream; and The processor establishes a corresponding data bearer entity with the other device, wherein the corresponding data bearer entity is mapped to the specific Internet Protocol stream.

9. The method of claim 1, wherein, Establishing the plurality of data bearer entities with the other device further includes: The processor is configured to send and receive the plurality of data bearer entities, wherein the configuration includes hash functions mapping the plurality of data bearer entities to the plurality of Internet Protocol streams; and The processor and the other device establish the multiple data-bearing entities.

10. The method of claim 1, further comprising: The processor performs at least one of the following operations for each data bearer entity: packet data aggregation protocol packet data unit processing operation, radio link control packet data unit processing operation, and lossless handover operation.

11. An apparatus comprising: A transceiver is used to communicate wirelessly with a wireless network during operation; as well as A processor, communicatively coupled to the transceiver, performs the following operations: Multiple data bearer entities are established with another device, wherein the multiple data bearer entities are mapped to multiple Internet Protocol streams, and wherein the device and the other device are located in a wireless access network; as well as Based on the result of mapping the multiple Internet Protocol streams to the multiple data bearer entities, the transceiver and the multiple data bearer entities are used to send and receive multiple packets associated with the multiple Internet Protocol streams with the other device.

12. The apparatus of claim 11, wherein the plurality of data bearer entities include a plurality of sub-data radio bearers within a data radio bearer, and wherein the plurality of Internet Protocol streams are mapped to the plurality of sub-data radio bearers at the packet data convergence protocol layer.

13. The apparatus of claim 12, wherein, The Packet Data Convergence Protocol (PDCP) packet data unit header contains a field for indicating the sub-data radio bearer identifier, and the Radio Link Control (RANC) packet data unit header contains a field for indicating the sub-data radio bearer identifier.

14. The apparatus of claim 12, wherein, Each sub-data radio bearer is associated with a packet data aggregation protocol sequence number space. In the presence of a radio link control layer and where the sub-data radio bearer is applied to the radio link control layer, each sub-data radio bearer is associated with a corresponding radio link control sequence number space. In the presence of a radio link control layer but where the sub-data radio bearer is not applied to the radio link control layer, the sub-data radio bearer is associated with the same radio link control sequence number space.

15. The apparatus of claim 11, wherein, The plurality of data bearer entities include a plurality of data radio bearers, and wherein the plurality of Internet Protocol streams are mapped to the plurality of data radio bearers at the Service Data Adaptor Protocol layer.

16. The apparatus of claim 15, wherein, Each data radio bearer is associated with a packet data aggregation protocol sequence number space and a radio link control sequence number space.

17. The apparatus of claim 11, wherein, The processor then performs the following operations: Identify a specific Internet Protocol (IP) stream; The transceiver exchanges information with the other device that maps a specific Internet Protocol stream to the corresponding data bearer entity; and Establish a corresponding data carrier entity with the other device.

18. The apparatus of claim 11, wherein, The processor further performs the following operations, including: Determine a specific Internet Protocol (IP) stream; and A corresponding data bearer entity is established with the other device, wherein the corresponding data bearer entity is mapped to the specific Internet Protocol stream.

19. The apparatus of claim 11, wherein, The processor further performs the following operations, including: The transceiver is configured to send and receive the plurality of data bearer entities, wherein the configuration includes a hash function that maps the plurality of data bearer entities to the plurality of Internet Protocol streams; and Establish the multiple data-bearing entities with the other device.

20. The apparatus of claim 11, wherein, The processor further performs the following operations, including: The processor performs at least one of the following operations for each data bearer entity: packet data aggregation protocol packet data unit processing operation, radio link control packet data unit processing operation, and lossless handover operation.

Images