Methods and apparatus for transceiving packets via data bearer entities established in radio access network in mobile communications

Abstract

Various solutions for transceiving packets via data bearer entities established in Radio Access Network (RAN) with respect to an apparatus in mobile communications are described. The apparatus may establish a plurality of data bearer entities with another apparatus. The plurality of data bearer entities may be mapped to a plurality of Internet Protocol (IP) flows. The apparatus and the another apparatus may be located in a RAN. The apparatus may transceive a plurality of packets associated with the plurality of IP flows with the another apparatus via the plurality of data bearer entities based on a result of mapping the plurality of IP flows to the plurality of data bearer entities.

Description

METHODS AND APPARATUS FOR TRANSCEIVING PACKETS VIA DATA BEARER ENTITIES ESTABLISHED IN RADIO ACCESS NETWORK IN MOBILE COMMUNICATIONSCROSS REFERENCE TO RELATED PATENT APPLICATION (S)

[0001] The present disclosure is part of a non-provisional application claiming the priority benefit of U.S. Patent Application No. 63 / 700,796, filed 30 September 2024, the content of which herein being incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure is generally related to mobile communications and, more particularly, to transceiving packets via data bearer entities established in Radio Access Network (RAN) with respect to apparatus in mobile communications.BACKGROUND

[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.

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

[0005] However, deployment of multiple dedicated DRBs between a User Equipment (UE) , a Base Station (BS) , and a Core Network (CN) in real network structures may be limited due to implementation complexity, operational cost, scalability challenges, and additional control overhead. As a result, in general commercial networks, only a single DRB for Internet best-effort service may be applied for all Internet traffic, and diverse services such as Voice over IP (VoIP) , cloud gaming, video streaming, and background data may be treated with the same priority and multiplexed over the same DRB. Therefore, packets requiring high reliability and low latency may suffer degraded performance due to contention with best-effort or delay-tolerant traffic within the single DRB.

[0006] Accordingly, how to improve network performance while avoiding excessive complexity and cost becomes an important issue in the newly developed wireless communication network. Therefore, there is a need to provide proper schemes to improve network performance while avoiding excessive complexity and cost.SUMMARY

[0007] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0008] An objective of the present disclosure is to propose solutions or schemes that address the aforementioned issues pertaining to transceiving packets via data bearer entities established in Radio Access Network (RAN) with respect to apparatus in mobile communications.

[0009] In one aspect, a method may involve an apparatus establishing a plurality of data bearer entities with another apparatus. The plurality of data bearer entities may be mapped to a plurality of Internet Protocol (IP) flows, and the apparatus and the another apparatus may be located in a RAN. The method may further involve the apparatus transceiving a plurality of packets associated with the plurality of IP flows with the another apparatus via the plurality of data bearer entities based on a result of mapping the plurality of IP flows to the plurality of data bearer entities.

[0010] In one aspect, an apparatus may comprise a transceiver which, during operation, wirelessly communicates with a wireless network. The apparatus may also comprise a processor communicatively coupled to the transceiver. The processor, during operation, may perform operations comprising establishing a plurality of data bearer entities with another apparatus. The plurality of data bearer entities may be mapped to a plurality of IP flows, and the apparatus and the another apparatus may be located in a RAN. The processor may further perform operations comprising transceiving, via the transceiver, a plurality of packets associated with the plurality of IP flows with the another apparatus via the plurality of data bearer entities based on a result of mapping the plurality of IP flows to the plurality of data bearer entities.

[0011] It is noteworthy that, although description provided herein may be in the context of certain radio access technologies, networks and network topologies such as Long-Term Evolution (LTE) , LTE-Advanced, LTE-Advanced Pro, 5th Generation (5G) , New Radio (NR) , Internet-of-Things (IoT) and Narrow Band Internet of Things (NB-IoT) , Industrial Internet of Things (IIoT) , and 6th Generation (6G) , the proposed concepts, schemes and any variation (s)  / derivative (s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies. Thus, the scope of the present disclosure is not limited to the examples described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation in order to clearly illustrate the concept of the present disclosure.

[0013] FIG. 1 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0014] FIG. 2 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0015] FIG. 3A is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0016] FIG. 3B is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0017] FIG. 3C is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0018] FIG. 4A is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0019] FIG. 4B is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0020] FIG. 4C is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0021] FIG. 5 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0022] FIG. 6A is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0023] FIG. 6B is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0024] FIG. 6C is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0025] FIG. 7 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0026] FIG. 8 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0027] FIG. 9 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0028] FIG. 10 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0029] FIG. 11 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0030] FIG. 12 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0031] FIG. 13 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0032] FIG. 14 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0033] FIG. 15 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0034] FIG. 16 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0035] FIG. 17 is a block diagram of an example communication system in accordance with an implementation of the present disclosure.

[0036] FIG. 18 is a flowchart of an example process in accordance with an implementation of the present disclosure. DETAILED DESCRIPTION OF PREFERRED IMPLEMENTATIONS

[0037] Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. Overview

[0038] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to transceiving packets via data bearer entities established in Radio Access Network (RAN) with respect to apparatus in mobile communications. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.

[0039] Regarding the present disclosure, an apparatus (e.g., a network node or a User Equipment (UE) ) may establish a plurality of data bearer entities with another apparatus (e.g., a UE or a network node) . The plurality of data bearer entities may be mapped to a plurality of Internet Protocol (IP) flows. The apparatus and the another apparatus may be located in a RAN.

[0040] Based on the result of mapping the plurality of IP flows to the plurality of data bearer entities, the apparatus may transceive a plurality of packets associated with the plurality of IP flows with the another apparatus via the plurality of data bearer entities. Accordingly, because multiple data bearer entities may be established within the RAN, network performance may be improved while avoiding the complexity and cost that would otherwise arise from establishing multiple data bearer entities in the Core Network (CN) .

[0041] FIG. 1 illustrates an example scenario 100 under schemes in accordance with implementations of the present disclosure. Scenario 100 involves a first apparatus and a second apparatus, which may be a part of a wireless communication network (e.g., an LTE network, a 5G / NR network, an IoT network or a 6G network) . Scenario 100 illustrates the current network framework. The first apparatus may connect to the second apparatus. The first apparatus and the second apparatus may be located in a RAN.

[0042] It should be noted that in the figures of the present application, the first apparatus may be a UE or a network node (e.g., Base Station (BS) ) while the second apparatus may be a network node (e.g., BS) or a UE. However, this is for illustrative purposes and not intended to be limiting.

[0043] In some embodiments, the first apparatus may establish a plurality of data bearer entities with the second apparatus. In particular, the plurality of data bearer entities may be mapped to a plurality of IP flows. The mapping between the plurality of data bearer entities and the plurality of IP flows may be determined by either the first apparatus or the second apparatus. In other words, an initiation of the mapping between the plurality of data bearer entities and the plurality of IP flows may be performed by the first apparatus or the second apparatus. Based on the result of mapping the plurality of IP flows to the plurality of data bearer entities, the first apparatus may transceive, via the plurality of data bearer entities, a plurality of packets associated with the plurality of IP flows with the second apparatus.

[0044] In some implementations, the first apparatus and the second apparatus may be located within the RAN. More specifically, the plurality of data bearer entities may be established in the RAN without involving the CN, thereby reducing signaling overhead and complexity associated with establishing multiple data bearer entities in the CN.

[0045] In some implementations, the plurality of data bearer entities may include a plurality of sub-Data Radio Bearers (DRBs) within one DRB. The plurality of IP flows may be mapped to the plurality of sub-DRBs in a Packet Data Convergence Protocol (PDCP) layer. In particular, the first apparatus may establish the plurality of sub-DRBs inside one DRB with the second apparatus. The first apparatus may include a packet classifier module in the PDCP layer. The first apparatus may use the packet classifier module to map the plurality of IP flows to the plurality of sub-DRBs. In some cases, the plurality of IP flows may be mapped to the plurality of sub-DRBs in a one-to-one manner.

[0046] In some implementations, each sub-DRB may have respective (i.e., its own separate) PDCP sequence number space (i.e., PDCP sequence number domain) . In some implementations, each sub-DRB may have respective (i.e., its own separate) RLC sequence number space (i.e., RLC sequence number domain) when RLC layer exists and the sub-DRBs are applicable to RLC layer. In some implementations, the sub-DRBs may be associated with the same RLC sequence number space in an event that the RLC layer exists but the sub-DRBs are not applicable to the RLC layer. Further, a PDCP Packet Data Unit (PDU) header of a PDCP packet may include a field indicating sub-DRB identification, and an RLC PDU header of an RLC packet may include a field indicating sub-DRB identification.

[0047] FIG. 2 illustrates an example scenario 200 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a User Equipment (UE) , and the second apparatus is a Base Station (BS) . The UE establishes a plurality of sub-DRBs 0 to 3 inside one DRB with the BS. The UE includes a packet classifier module in a PDCP / RLC layer. In some scenarios, the RLC layer exists. In some scenarios, the RLC layer does not exist (e.g., in some sixth generation (6G) networks) . The UE uses the packet classifier module to map a plurality of IP flows (e.g., background data, gaming data, VoIP data, and streaming data) to the plurality of sub-DRBs 0 to 3. The IP flows correspond to a Quality of Service (QoS) flow 0.

[0048] In this example, the sub-DRBs 0 to 3 respectively correspond to sub-DRB identifications sub-IDs 0 to 3. The UE uses the packet classifier module to classify a packet transceived with the BS through Service Data Adaptation Protocol (SDAP) layers, PDCP / RLC layers, and sub-DRBs of one DRB. When a header of the packet includes a field indicating sub-DRB identification ‘A’ , this packet is transceived over sub-DRB ‘A’ .

[0049] Each sub-DRB has its own separate PDCP sequence number space. Each sub-DRB has its own separate RLC sequence number space when RLC layer exists and sub-DRB is applicable to RLC layer. All sub-DRBs share the same RLC sequence number space when RLC layer exists but sub-DRBs are not applicable to RLC layer. In this example, packets transceived over sub-DRB 0 have PDCP / RLC sequence numbers 0, 2 and 3 (illustrated as square boxes) . Packet transceived over sub-DRB 1 has PDCP / RLC sequence number 0 (illustrated as a square box) . Packets transceived over sub-DRB 2 have PDCP / RLC sequence numbers 0 and 1 (illustrated as square boxes) . Packet transceived over sub-DRB 3 has PDCP / RLC sequence number 0 (illustrated as a square box) . The missing packet with sequence number 1 associated with sub-DRB 0 does not impact transmission of IP flow packets over other sub-DRBs 1 to 3.

[0050] It should be noted that, in FIG. 2, a packet classifier of the BS is omitted for ease of illustration. However, this is not intended to limit the scope of the present disclosure. The BS may also include a packet classifier configured to perform the foregoing operations.

[0051] FIG. 3A illustrates an example scenario 300A under schemes in accordance with implementations of the present disclosure. For example, RLC layer exists in 6G network, and sub-DRBs are applicable to RLC layer. Accordingly, a packet transmission / reception architecture of the first / second apparatus includes: (1) PDU session entity, (2) Traffic Flow Template (TFT) packet filter entity, (3) SDAP entity having two QoS flows with QoS Flow Identifier (QFI) 0 and 1, (4) PDCP processing entities with identifiers 0 and 1, (5) RLC processing entities with identifiers 0 to 3, (6) fifth generation (5G) Media Access Control (MAC) processing entity with cell group CG 0, and (7) 6G MAC processing entity with cell group CG 1.

[0052] PDCP processing entity with identifier 0 has a packet classifier for classifying packets as: (a) sub-PDCP 0 according to 5-tuple 5T-0 of corresponding packet, (b) sub-PDCP 1 according to 5-tuple 5T-1 of corresponding packet, and (c) sub-PDCP 2 according to 5-tuple 5T-2 of corresponding packet. PDCP processing entity with identifier 1 has a packet classifier for classifying packets as: (a) sub-PDCP 0 according to 5-tuple 5T-3 of corresponding packet, (b) sub-PDCP 1 according to 5-tuple 5T-4 of corresponding packet, and (c) sub-PDCP 2 according to 5-tuple 5T-5 of corresponding packet. In PDCP layer, each sub-DRB has its own separate PDCP sequence number space.

[0053] RLC processing entities 0 to 3 are normal RLC entities. RLC processing entity with identifier 1 processes packets as sub-RLC 0 according to the RLC header of the corresponding packet. RLC processing entity with identifier 2 processes packets as: (1) sub-RLC 0 according to the RLC header of the corresponding packet, (2) sub-RLC 1 according to the RLC header of the corresponding packet, and (3) sub-RLC 2 according to the RLC header of the corresponding packet. In RLC layer, each sub-DRB has its own separate RLC sequence number space.

[0054] 5G MAC processing entity with cell group CG 0 has Logic Channels (LCs) with LC identifiers (LCIDs) 0 and 1 for processing packets. 6G MAC processing entity with cell group CG 1 has LCs with LCIDs 0 and 1 for processing packets.

[0055] In this example, packets are passed from the PDU session entity to the TFT packet filter entity. TFT packet filter filters packets to different QoS flows based on packet header fields (e.g., IP addresses, port numbers, protocol ID, flow label, etc. ) Packets are passed from the SDAP entity to the PDCP processing entities via different QoS flows. Packer classifier of PDCP processing entity classifies packets as different sub-PDCP based on 5-tuples of corresponding packets. Packets are passed from PDCP processing entities to RLC processing entities based on bearer identification information (e.g., a DRB identifier or a sub-DRB identifier, determined by the packet classifier) . Packets are passed from RLC processing entities to LCs of 5G / 6G MAC processing entity based on LCIDs.

[0056] FIG. 3B illustrates an example scenario 300B under schemes in accordance with implementations of the present disclosure. For example, RLC layer exists, but the sub-DRBs are not applicable to RLC layer. Accordingly, a packet transmission / reception architecture of the first / second apparatus includes: (1) PDU session entity, (2) TFT packet filter entity, (3) SDAP entity having two QoS flows with QFI 0 and 1, (4) PDCP processing entities with identifiers 0 and 1, (5) RLC processing entities with identifiers 0 to 3, (6) 5G MAC processing entity with cell group CG 0, and (7) 6G MAC processing entity with cell group CG 1.

[0057] PDCP processing entity with identifier 0 has a packet classifier for classifying packets as: (a) sub-PDCP 0 according to 5-tuple 5T-0 of corresponding packet, (b) sub-PDCP 1 according to 5-tuple 5T-1 of corresponding packet, and (c) sub-PDCP 2 according to 5-tuple 5T-2 of corresponding packet. PDCP processing entity with identifier 1 has a packet classifier for classifying packets as: (a) sub-PDCP 0 according to 5-tuple 5T-3 of corresponding packet, (b) sub-PDCP 1 according to 5-tuple 5T-4 of corresponding packet, and (c) sub-PDCP 2 according to 5-tuple 5T-5 of corresponding packet. In PDCP layer, each sub-DRB has its own separate PDCP sequence number space.

[0058] In this example, the sub-DRB is not applicable to the RLC layer. Accordingly, all sub-DRBs share the same RLC sequence number space. The RLC processing entities with identifiers 0 to 3 process packets in the normal manner based on the RLC headers of the corresponding packets.

[0059] 5G MAC processing entity with cell group CG 0 has LCIDs 0 and 1 for processing packets. 6G MAC processing entity with cell group CG 1 has LCs with LCIDs 0 and 1 for processing packets.

[0060] In this example, packets are passed from the PDU session entity to the TFT packet filter entity. TFT packet filter filters packets to different QoS flows based on packet header fields (e.g., IP addresses, port numbers, protocol ID, flow label, etc. ) Packets are passed from the SDAP entity to the PDCP processing entities via different QoS flows. Packer classifier of PDCP processing entity classifies packets as different sub-PDCP based on 5-tuples of corresponding packets. Packets are passed from PDCP processing entities to RLC processing entities based on bearer identification information (e.g., a DRB identifier or a sub-DRB identifier, determined by the packet classifier) . Packets are passed from RLC processing entities to LCs of 5G / 6G MAC processing entity based on LCIDs.

[0061] FIG. 3C illustrates an example scenario 300C under schemes in accordance with implementations of the present disclosure. For example, RLC layer does not exist in 6G network. Accordingly a packet transmission / reception architecture of the first / second apparatus includes: (1) PDU session entity, (2) TFT packet filter entity, (3) SDAP entity having two QoS flows with QFI 0 and 1, (4) PDCP processing entities with identifiers 0 and 1, (5) RLC processing entities with identifiers 0 and 3 associated with 5G network, (6) 5G MAC processing entity with cell group CG 0, and (7) 6G MAC processing entity with cell group CG 1.

[0062] PDCP processing entity with identifier 0 has a packet classifier for classifying packets as: (a) sub-PDCP 0 according to 5-tuple 5T-0 of corresponding packet, (b) sub-PDCP 1 according to 5-tuple 5T-1 of corresponding packet, and (c) sub-PDCP 2 according to 5-tuple 5T-2 of corresponding packet. PDCP processing entity with identifier 1 has a packet classifier for classifying packets as: (a) sub-PDCP 0 according to 5-tuple 5T-3 of corresponding packet, (b) sub-PDCP 1 according to 5-tuple 5T-4 of corresponding packet, and (c) sub-PDCP 2 according to 5-tuple 5T-5 of corresponding packet. In PDCP layer, each sub-DRB has its own separate PDCP sequence number space.

[0063] In this example, RLC layer does not exist in 6G network. Accordingly, the sub-DRBs associated with 5G network share the same RLC sequence number space, and only the RLC processing entities with identifiers 0 and 3 associated with 5G network process packets in the normal manner based on the RLC headers of the corresponding packets.

[0064] 5G MAC processing entity with cell group CG 0 has LCs with LCIDs 0 and 1 for processing packets. 6G MAC processing entity with cell group CG 1 has LCs with LCIDs 0 and 1 for processing packets.

[0065] In this example, packets are passed from the PDU session entity to the TFT packet filter entity. TFT packet filter filters packets to different QoS flows based on packet header fields (e.g., IP addresses, port numbers, protocol ID, flow label, etc. ) Packets are passed from the SDAP entity to the PDCP processing entities via different QoS flows. Packer classifier of PDCP processing entity classifies packets as different sub-PDCP based on 5-tuples of corresponding packets. Packets are passed from PDCP processing entities to RLC processing entities based on bearer identification information (e.g., a DRB identifier or a sub-DRB identifier, determined by the packet classifier) . Packets are passed from RLC processing entities to LCs of 5G / 6G MAC processing entity based on LCIDs.

[0066] It should be noted that the packet transmission paths (represented by lines with arrows) in FIGs. 3A to 3C are illustrated for ease of understanding. However, this is not intended to limit the scope of the present disclosure. Any possible path may be employed depending on different network scenarios.

[0067] FIGs. 4A to 4C illustrate example scenarios 400A to 400C under schemes in accordance with implementations of the present disclosure. In particular, a PDCP PDU header of a PDCP data PDU may include a field indicating sub-DRB identification.

[0068] In FIG. 4A, the PDCP data PDU may include a type with a 12-bit PDCP sequence number. The PDCP data PDU may include a type with an 18-bit PDCP sequence number.

[0069] In FIG. 4B, the PDCP data PDU may include a type with 12-bit PDCP sequence number while concatenation and separated PDCP concatenation information headers are enabled. The PDCP data PDU may include a type with 12-bit PDCP sequence number while concatenation and aggregated PDCP concatenation information headers are enabled.

[0070] In FIG. 4C, the PDCP data PDU may include a type with 18-bit PDCP sequence number while concatenation and separated PDCP concatenation information headers are enabled. The PDCP data PDU may include a type with 18-bit PDCP sequence number while concatenation and aggregated PDCP concatenation information headers are enabled.

[0071] FIG. 5 illustrates an example scenario 500 under schemes in accordance with implementations of the present disclosure. In particular, a PDCP PDU header of a PDCP control PDU may include a field indicating sub-DRB identification.

[0072] FIGs. 6A to 6C illustrate example scenarios 600A to 600C under schemes in accordance with implementations of the present disclosure. In particular, an RLC PDU header of an RLC data PDU may include a field indicating sub-DRB identification.

[0073] In FIG. 6A, the RLC data PDU may include an Unacknowledged Mode Data (UMD) PDU having a complete RLC Service Data Unit (SDU) .

[0074] In FIG. 6B, the RLC data PDU may include a UMD PDU with 6-bit sequence number without Segmentation Offset (SO) . The RLC data PDU may include a UMD PDU with 6-bit sequence number and SO. The RLC data PDU may include a UMD PDU with 12-bit sequence number without SO. The RLC data PDU may include a UMD PDU with 12-bit sequence number and SO.

[0075] In FIG. 6C, the RLC data PDU may include an Acknowledged Mode Data (AMD) PDU with 12-bit sequence number without SO. The RLC data PDU may include an AMD PDU with 12-bit sequence number and SO. The RLC data PDU may include an AMD PDU with 18-bit sequence number without SO. The RLC data PDU may include an AMD PDU with 18-bit sequence number and SO.

[0076] FIG. 7 illustrates an example scenario 700 under schemes in accordance with implementations of the present disclosure. In particular, an RLC PDU header of an RLC control PDU may include a field indicating sub-DRB identification.

[0077] It should be noted that, in the figures, (1) ‘sub-DRB identification’ field represents identification of corresponding sub-DRB, (2) ‘R’ field represents a reserved bit field, which may be set to a predetermined value (e.g., 0) and may not be currently used, (3) ‘SN’ field represents a sequence number, which may be used to identify the transmission order of PDUs or SDUs for purposes such as reordering, duplicate detection, and retransmission, (4) ‘D / C’ field represents a data / control indicator, which may indicate whether the PDU is a data PDU or a control PDU, (5) ‘Data’ field represents a payload portion of the PDU, (6) ‘MAC-I’ field represents a message authentication code for integrity protection, which allows verification of the integrity of the corresponding PDU, (7) ‘PDCP concatenation info’ field represents an indication for concatenation of multiple PDCP SDUs into a single PDCP PDU, or continuation of a PDCP SDU across multiple PDUs, (8) ‘SDU type’ field represents an indication of the type of SDU contained in the PDU, for example, whether the SDU corresponds to user-plane data, control-plane data, or other categories, (9) ‘SI’ field represents segmentation information, which indicates whether the payload corresponds to a complete SDU, a first segment, a middle segment, or a last segment of an SDU, (10) ‘SO’ field represents a segmentation offset, which indicates a relative starting position of the PDU payload within the corresponding SDU when segmentation occurs, (11) ‘P’ field represents a polling bit, which may be used to trigger transmission of a status report or acknowledgment by the receiving entity, and (12) ‘CPT’ field represents a control PDU type, which indicates a specific type of control information carried by the control PDU.

[0078] It should be noted that the ‘sub-DRB identification’ field depicted in FIGs. 4A to 7 is shown for illustrative purposes only. The depiction does not limit the placement of the ‘sub-DRB identification’ field, which may be positioned differently within the header based on implementation or network configuration.

[0079] In some implementations, the plurality of data bearer entities may include a plurality of DRBs. The plurality of IP flows may be mapped to the plurality of DRBs in an SDAP layer. In particular, the first apparatus may establish the plurality of DRBs with the second apparatus. The first apparatus may include a packet classifier module in the SDAP layer. The first apparatus may use the packet classifier module to map the plurality of IP flows to the plurality of DRBs. In some cases, the plurality of IP flows may be mapped to the plurality of DRBs in a one-to-one manner.

[0080] In some implementations, each DRB may be associated with a PDCP sequence number space and an RLC sequence number space. In other words, each DRB may have its own separate PDCP entity with PDCP sequence number space (i.e., PDCP sequence number domain) and RLC entity with RLC sequence number space (i.e., RLC sequence number domain) .

[0081] FIG. 8 illustrates an example scenario 800 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a UE, and the second apparatus is a BS. The UE establishes a plurality of DRBs 0 to 3 with the BS. The UE includes a packet classifier module in an SDAP layer. The UE uses the packet classifier module to map a plurality of IP flows (e.g., background data, gaming data, VoIP data, and streaming data) to the plurality of DRBs 0 to 3. The IP flows correspond to a QoS flow 0.

[0082] In this example, the DRBs 0 to 3 respectively correspond to DRB identifications DRB IDs 0 to 3. The UE uses the packet classifier module to classify a packet transceived with the BS through SDAP layers, PDCP / RLC layers, and DRBs.

[0083] Each DRB has a corresponding PDCP entity and RLC entity. Each DRB has its own separate PDCP sequence number space and RLC sequence number space. In this example, packets transceived over DRB 0 have PDCP / RLC sequence numbers 0, 2 and 3 (illustrated as square boxes) . Packet transceived over DRB 1 has PDCP / RLC sequence number 0 (illustrated as a square box) . Packets transceived over DRB 2 have PDCP / RLC sequence numbers 0 and 1 (illustrated as square boxes) . Packet transceived over DRB 3 has PDCP / RLC sequence number 0 (illustrated as a square box) . The missing packet with sequence number 1 associated with DRB 0 does not impact the transmission of IP flow packets over other DRBs 1 to 3.

[0084] It should be noted that, in FIG. 8, a packet classifier of the BS is omitted for ease of illustration. However, this is not intended to limit the scope of the present disclosure. The BS may also include a packet classifier configured to perform the foregoing operations.

[0085] FIG. 9 illustrates an example scenario 900 under schemes in accordance with implementations of the present disclosure. For example, a packet transmission / reception architecture of the first / second apparatus includes: (1) PDU session entity, (2) Traffic Flow Template (TFT) packet filter entity, (3) SDAP entity having two QoS flows with QoS Flow Identifier (QFI) 0 and 1, (4) PDCP processing entities with identifiers 0 to 5, (5) RLC processing entities with identifiers 0 to 7, (6) 5G MAC processing entity with cell group CG 0, and (7) 6G MAC processing entity with cell group CG 1.

[0086] The SDAP entity has a packet classifier for classifying packets for PDCP entities 0 to 5 according to 5-tuple 5T-0 to 5T-5. PDCP processing entities 0 to 5 are normal PDCP entities. RLC processing entities 0 to 7 are normal RLC entities. 5G MAC processing entity with cell group CG 0 has LCs with LCIDs 0 to 3 for processing packets. 6G MAC processing entity with cell group CG 1 has LCs with LCIDs 0 to 3 for processing packets.

[0087] In this example, packets are passed from the PDU session entity to the TFT packet filter entity. TFT packet filter filters packets to different QoS flows based on packet header fields (e.g., IP addresses, port numbers, protocol ID, flow label, etc. ) . Packer classifier of SDAP entity classifies packets for different PDCP processing entities based on 5-tuples of corresponding packets. Packets are passed from PDCP processing entities to RLC processing entities based on bearer identification information (e.g., a DRB identifier) . Packets are passed from RLC processing entities to LCs of 5G / 6G MAC processing entity based on LCIDs.

[0088] It should be noted that the packet transmission paths (represented by lines with arrows) in FIG. 9 are illustrated for ease of understanding. However, this is not intended to limit the scope of the present disclosure. Any possible path may be employed depending on different network scenarios.

[0089] In some implementations, during the data bearer entities (e.g., the sub-DRBs / or the DRBs in the RAN) establishment procedure, the first apparatus or the second apparatus may inform the other apparatus of a maximum number of data bearer entities and / or allowed service types (e.g., gaming, VoIP and streaming) .

[0090] In some implementations, the first apparatus may determine a specific IP flow. The first apparatus may exchange information on mapping the specific IP flow to a corresponding data bearer entity with the second apparatus. The first apparatus may establish the corresponding data bearer entity with the second apparatus. In some cases, the first apparatus may establish multiple data bearer entities, which may be mapped to corresponding IP flows, with the second apparatus based on the previous operations.

[0091] FIG. 10 illustrates an example scenario 1000 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a UE, and the second apparatus is a BS. The BS transmits a configuration of data bearer entity to the UE. The configuration includes Radio Resource Control (RRC) configuration with DRB configuration. The DRB configuration includes information for default DRB establishment. Then, the BS and the UE establish a default data bearer entity 0 (e.g., sub-DRB or DRB) based on the configuration.

[0092] Further, the BS determines a specific IP flow (e.g., gaming traffic) . The BS transmits a configuration of a data bearer entity 1 to the UE. The configuration includes RRC configuration with DRB configuration. The DRB configuration includes at least one of information for DRB establishment, packet classifier information, and service type. The packet classifier information includes information (e.g., 5-tuple) of mapping the data bearer entity 1 to the specific IP flow. Then, the BS and the UE establish the data bearer entity 1 (e.g., sub-DRB or DRB) based on the configuration.

[0093] Further, the BS determines a specific IP flow (e.g., VoIP traffic) . The BS transmits a configuration of a data bearer entity 2 to the UE. The configuration includes RRC configuration with DRB configuration. The DRB configuration includes at least one of information for DRB establishment, packet classifier information, and service type. The packet classifier information includes information (e.g., 5-tuple) of mapping the data bearer entity 2 to the specific IP flow. Then, the BS and the UE establish the data bearer entity 2 (e.g., sub-DRB or DRB) based on the configuration.

[0094] FIG. 11 illustrates an example scenario 1100 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a UE, and the second apparatus is a BS. The BS transmits a configuration of data bearer entity to the UE. The configuration includes RRC configuration with DRB configuration. The DRB configuration includes information for default DRB establishment, a maximum number of data bearer entities and allowed service types (e.g., gaming, VoIP and streaming) . Then, the BS and the UE establish a default data bearer entity 0 (e.g., sub-DRB or DRB) based on the configuration.

[0095] Further, the UE determines a specific IP flow (e.g., gaming traffic) . The UE transmits information of the specific IP flow (e.g., 5-tuple information and service type associated with the specific IP flow) to the BS. The information of the specific IP flow is included in an RRC signaling (e.g., UE assistance information) or a layer 2 control message (e.g., MAC Control Element (MAC CE) ) . After receiving the information of the specific IP flow, the BS approves the data bearer entity establishment associated with the specific IP flow. The BS transmits a configuration of a data bearer entity 1 to the UE. The configuration includes RRC configuration with DRB configuration. The DRB configuration includes at least one of information for DRB establishment, packet classifier information, and service type. The packet classifier information includes information (e.g., 5-tuple) of mapping the data bearer entity 1 to the specific IP flow. Then, the BS and the UE establish the data bearer entity 1 (e.g., sub-DRB or DRB) based on the configuration.

[0096] Further, the UE determines a specific IP flow (e.g., VoIP traffic) . The UE transmits information of the specific IP flow (e.g., 5-tuple information and service type associated with the specific IP flow) to the BS. The information of the specific IP flow is included in an RRC signaling (e.g., UE assistance information) or a layer 2 control message (e.g., MAC CE) . After receiving the information of the specific IP flow, the BS approves the data bearer entity establishment associated with the specific IP flow. The BS transmits a configuration of a data bearer entity 2 to the UE. The configuration includes RRC configuration with DRB configuration. The DRB configuration includes at least one of information for DRB establishment, packet classifier information, and service type. The packet classifier information includes information (e.g., 5-tuple) of mapping the data bearer entity 2 to the specific IP flow. Then, the BS and the UE establish the data bearer entity 2 (e.g., sub-DRB or DRB) based on the configuration.

[0097] In some implementations, the first apparatus may determine a specific IP flow. The first apparatus may establish a corresponding data bearer entity mapped to the specific IP flow with the second apparatus. In some cases, the first apparatus may establish multiple data bearer entities, which may be mapped to corresponding IP flows, with the second apparatus based on the previous operations.

[0098] FIG. 12 illustrates an example scenario 1200 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a UE, and the second apparatus is a BS. The BS transmits a configuration of data bearer entity to the UE. The configuration includes RRC configuration with DRB configuration. The DRB configuration includes information for default DRB establishment and a maximum number of data bearer entities. Then, the BS and the UE establish a default data bearer entity 0 (e.g., sub-DRB or DRB) based on the configuration.

[0099] Further, the BS determines a specific IP flow (e.g., gaming traffic) . Then, the BS and the UE establish the data bearer entity 1 (e.g., sub-DRB or DRB) . The data bearer entity 1 is mapped to the specific IP flow.

[0100] Further, the BS determines a specific IP flow (e.g., VoIP traffic) . Then, the BS and the UE establish the data bearer entity 2 (e.g., sub-DRB or DRB) . The data bearer entity 2 is mapped to the specific IP flow.

[0101] FIG. 13 illustrates an example scenario 1300 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a UE, and the second apparatus is a BS. The BS transmits a configuration of data bearer entity to the UE. The configuration includes RRC configuration with DRB configuration. The DRB configuration includes information for default DRB establishment, a maximum number of data bearer entities and allowed service types (e.g., gaming, VoIP and streaming) . Then, the BS and the UE establish a default data bearer entity 0 (e.g., sub-DRB or DRB) based on the configuration.

[0102] Further, the UE determines a specific IP flow (e.g., gaming traffic) . Then, the BS and the UE establish the data bearer entity 1 (e.g., sub-DRB or DRB) . The data bearer entity 1 is mapped to the specific IP flow.

[0103] Further, the BS determines a specific IP flow (e.g., VoIP traffic) . Then, the BS and the UE establish the data bearer entity 2 (e.g., sub-DRB or DRB) . The data bearer entity 2 is mapped to the specific IP flow.

[0104] In some implementations, the first apparatus may transceive a configuration of one data bearer entity with the second apparatus. The configuration may include a hash function of mapping the plurality of data bearer entities to the plurality of IP flows. The first apparatus may establish the plurality of data bearer entities with the second apparatus.

[0105] FIG. 14 illustrates an example scenario 1400 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a UE, and the second apparatus is a BS. The BS transmits a configuration of data bearer entity to the UE. The configuration includes RRC configuration with DRB configuration. The DRB configuration includes information for default DRB establishment, a maximum number of data bearer entities and a hash function of mapping a plurality of data bearer entities (e.g., sub-DRBs or DRBs) to a plurality of IP flows. Then, the BS and the UE establish the plurality of data bearer entities based on the configuration.

[0106] More specifically, the hash function is used to map information of a specific IP flow (e.g., 5-tuple information associated with the specific IP flow) to a corresponding data bearer entity. In other words, the hash function receives information of the specific IP flow and outputs an identification of the corresponding data bearer entity. Accordingly, the UE and the BS employ the hash function to transceive data of the specific IP flow via the corresponding data bearer entity.

[0107] In some implementations, the first apparatus may perform at least one of a PDCP PDU processing operation, an RLC PDU processing operation, and a handover operation per data bearer entity.

[0108] In some cases, the PDCP PDU processing operation may include at least one of: PDCP Transmission / Reception (TRX) operation, PDCP discard operation, PDCP data recovery operation, PDCP reordering operation, PDCP Ciphering operation, PDCP Integrity operation, PDCP protection operation, PDCP header Compression operation, and PDCP UDC operation.

[0109] In some cases, the RLC PDU processing operation may include at least one of: RLC TRX operation and RLC ARQ operation. FIG. 15 illustrates an example scenario 1500 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a UE, and the second apparatus is a BS. The BS transmits RLC PDUs to the UE over data bearer entities 0 and 1. Regarding data bearer entity 0, RLC PDUs include 50 to 54, while RLC PDUs 51 to 53 are successfully received, and RLC PDUs 50 and 54 are missing. Regarding data bearer entity 1, RLC PDUs include 32 to 36, while RLC PDUs 32, 33, 34 and 36 are successfully received, and RLC PDU 35 is missing.

[0110] Subsequently, the UE generates an RLC status report associated with the data bearer entity 0 while the RLC status report includes information of missing RLC PDUs 50 and 54. The UE generates an RLC status report associated with the data bearer entity 1, while the RLC status report includes information of the missing RLC PDU 35. Then, the UE transmits the RLC status reports corresponding to respective data bearer entities 0 and 1, thereby enabling independent acknowledgement and retransmission control per data bearer entity. After receiving the RLC status reports, the BS retransmits: (1) the missing RLC PDUs 50 and 54 over data bearer entity 0, and (2) the missing RLC PDU 35 over data bearer entity 1.

[0111] In some cases, the handover operation may include a lossless handover operation. FIG. 16 illustrates an example scenario 1600 under schemes in accordance with implementations of the present disclosure. For example, the first apparatus is a UE, and the second apparatus is a BS. The BS transmits PDCP PDUs to the UE over data bearer entities 0 and 1. Regarding data bearer entity 0, PDCP PDUs include 50 to 54, while PDCP PDUs 51 to 53 are successfully received, and PDCP PDUs 50 and 54 are missing. Regarding data bearer entity 1, PDCP PDUs include 32 to 36, while PDCP PDUs 32, 34 and 36 are successfully received, PDCP PDU 33 is successfully received without successful acknowledgement, and PDCP PDU 35 is missing.

[0112] Then, the BS transmits the handover configuration to the UE for the UE to hand over from the BS to another BS. The BS forwards information of PDCP PDUs without acknowledgement (i.e., PDCP PDUs 50 and 54 over data bearer entity 0 and PDCP PDU 35 over data bearer entity1) .

[0113] Next, the UE handovers to the another BS and transmits the handover complete message to the another BS. The UE generates a PDCP status report associated with the data bearer entity 0, while the PDCP status report includes information of received PDCP PDUs 51 to 53. The UE generates a PDCP status report associated with the data bearer entity 1, while the PDCP status report includes information of received PDCP PDUs 32, 33, 34 and 36. Then, the UE transmits the PDCP status reports corresponding to respective data bearer entities 0 and 1, thereby enabling independent acknowledgement and retransmission control per data bearer entity. After receiving the PDCP status reports, the BS retransmits: (1) the missing PDCP PDUs 50 and 54 over data bearer entity 0, and (2) the missing PDCP PDU 35 over data bearer entity 1. Illustrative Implementations

[0114] FIG. 17 illustrates an example communication system 1700 having an example first apparatus 1710 and an example second apparatus 1720 in accordance with an implementation of the present disclosure. Each of first apparatus 1710 and second apparatus 1720 may perform various functions to implement schemes, techniques, processes and methods described herein pertaining to transceiving packets via data bearer entities established in RAN with respect to apparatus in mobile communications, including scenarios / schemes described above as well as process 1800 described below.

[0115] First apparatus 1710 / second apparatus 1720 may be a part of an electronic apparatus, which may be a UE such as a portable or mobile apparatus, a wearable apparatus, a wireless communication apparatus or a computing apparatus. For instance, first apparatus 1710 / second apparatus 1720 may be implemented in a smartphone, a smartwatch, a personal digital assistant, a digital camera, or a computing equipment such as a tablet computer, a laptop computer or a notebook computer. First apparatus 1710 / second apparatus 1720 may also be a part of a machine type apparatus, which may be an IoT, NB-IoT, or IIoT apparatus such as an immobile or a stationary apparatus, a home apparatus, a wire communication apparatus or a computing apparatus. For instance, first apparatus 1710 / second apparatus 1720 may be implemented in a smart thermostat, a smart fridge, a smart door lock, a wireless speaker or a home control center.

[0116] First apparatus 1710 / second apparatus 1720 may be a part of a network apparatus, which may be a network node such as a satellite, a base station, a small cell, a router or a gateway. For instance, first apparatus 1710 / second apparatus 1720 may be implemented in an eNodeB in an LTE network, in a gNB in a 5G / NR, IoT, NB-IoT or IIoT network or in a satellite or base station in a 6G network.

[0117] Alternatively, first apparatus 1710 / second apparatus 1720 may be implemented in the form of one or more integrated-circuit (IC) chips such as, for example and without limitation, 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. First apparatus 1710 / second apparatus 1720 may include at least some of those components shown in FIG. 17 such as a processor 1712 / 1722, for example. First apparatus 1710 / second apparatus 1720 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and, thus, such component (s) of first apparatus 1710 / second apparatus 1720 are neither shown in FIG. 17 nor described below in the interest of simplicity and brevity.

[0118] In one aspect, each of processor 1712 and processor 1722 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, even though a singular term “aprocessor” is used herein to refer to processor 1712 and processor 1722, each of processor 1712 and processor 1722 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of processor 1712 and processor 1722 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, 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 varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of processor 1712 and processor 1722 is a special-purpose machine specifically designed, arranged and configured to perform specific tasks including transceiving packets via data bearer entities established in RAN in a device (e.g., as represented by first apparatus 1710 / second apparatus 1720) and a network (e.g., as represented by first apparatus 1710 / second apparatus 1720) in accordance with various implementations of the present disclosure.

[0119] In some implementations, first apparatus 1710 / second apparatus 1720 may also include a transceiver 1716 / 1726 coupled to processor 1712 / 1722 and capable of wirelessly transmitting and receiving data. In other words, processor 1712 / 1722 may transceive the data such as configuration, message, signal, information, indicator, etc. via transceiver 1716 / 1726. In some implementations, first apparatus 1710 / second apparatus 1720 may further include a memory 1714 / 1724 coupled to processor 1712 / 1722 and capable of being accessed by processor 1712 / 1722 and storing data therein. Accordingly, first apparatus 1710 and second apparatus 1720 may wirelessly communicate with each other via transceiver 1716 and transceiver 1726, respectively. To aid better understanding, the following description of the operations, functionalities and capabilities of each of first apparatus 1710 and second apparatus 1720 is provided in the context of a mobile communication environment in which first apparatus 1710 / second apparatus 1720 is implemented in or as a communication apparatus or a UE and first apparatus 1710 / second apparatus 1720 is implemented in or as a network node of a communication network.

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

[0121] FIG. 18 illustrates an example process 1800 in accordance with an implementation of the present disclosure. Process 1800 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to transceiving packets via data bearer entities established in RAN of the present disclosure. Process 1800 may represent an aspect of implementation of features of first apparatus 1710. Process 400 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1810 and 1820. Although illustrated as discrete blocks, various blocks of process 1800 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1800 may be executed in the order shown in FIG. 18 or, alternatively, in a different order. Process 1800 may be implemented by first apparatus 1710 or any suitable UE, network node or machine type devices. Solely for illustrative purposes and without limitation, process 1800 is described below in the context of first apparatus 1710. Process 1800 may begin at block 1810.

[0122] At block 1810, process 1800 may involve processor 1712 of first apparatus 1710 establishing a plurality of data bearer entities with another apparatus (e.g., second apparatus 1720) . The plurality of data bearer entities may be mapped to a plurality of IP flows. First apparatus 1710 and the another apparatus may be located in a RAN. Process 1800 may proceed from block 1810 to block 1820.

[0123] At block 1820, process 1800 may involve processor 1712 of first apparatus 1710 transceiving a plurality of packets associated with the plurality of IP flows with the another apparatus via the plurality of data bearer entities based on a result of mapping the plurality of IP flows to the plurality of data bearer entities.

[0124] In some implementations, the plurality of data bearer entities may include a plurality of sub-DRBs within one DRB, and the plurality of IP flows may be mapped to the plurality of sub-DRBs in a PDCP layer.

[0125] In some implementations, a PDCP PDU header of a PDCP packet may include a field indicating sub-DRB identification, and an RLC PDU header of an RLC packet may include a field indicating sub-DRB identification.

[0126] In some implementations, each sub-DRB may be associated with a PDCP sequence number space. Each sub-DRB may be associated with a respective RLC sequence number space in an event that an RLC layer exists and the sub-DRBs are applied to the RLC layer. The sub-DRBs may be associated with the same RLC sequence number space in an event that the RLC layer exists but the sub-DRBs are not applied to the RLC layer.

[0127] In some implementations, the plurality of data bearer entities may include a plurality of DRBs, and the plurality of IP flows may be mapped to the plurality of DRBs in an SDAP layer.

[0128] In some implementations, each DRB may be associated with a PDCP sequence number space and an RLC sequence number space.

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

[0130] In some implementations, process 1800 may further involve processor 1712 of first apparatus 1710 determining a specific IP flow. Process 1800 may further involve processor 1712 establishing a corresponding data bearer entity with the another apparatus. The corresponding data bearer entity may be mapped to the specific IP flow.

[0131] In some implementations, process 1800 may further involve processor 1712 of first apparatus 1710 transceiving a configuration of the plurality of data bearer entities. The configuration may include a hash function of mapping the plurality of data bearer entities to the plurality of IP flows. Process 1800 may further involve processor 1712 establishing the plurality of data bearer entities with the another apparatus.

[0132] n some implementations, process 1800 may further involve processor 1712 of first apparatus 1710 performing at least one of a PDCP PDU processing operation, an RLC PDU processing operation, and a lossless handover operation per data bearer entity. Additional Notes

[0133] The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected" , or "operably coupled" , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable" , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0134] Further, with respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0135] Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an, " e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of "two recitations, " without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “asystem having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “asystem having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.”

[0136] From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1.A method, comprising:establishing, by a processor of an apparatus, a plurality of data bearer entities with another apparatus, wherein the plurality of data bearer entities are mapped to a plurality of Internet Protocol (IP) flows, and wherein the apparatus and the another apparatus are located in a Radio Access Network (RAN) ; andtransceiving, by the processor, a plurality of packets associated with the plurality of IP flows with the another apparatus via the plurality of data bearer entities based on a result of mapping the plurality of IP flows to the plurality of data bearer entities.2.The method of Claim 1, wherein the plurality of data bearer entities include a plurality of sub-Data Radio Bearers (DRBs) within one DRB, and wherein the plurality of IP flows are mapped to the plurality of sub-DRBs in a Packet Data Convergence Protocol (PDCP) layer.3.The method of Claim 2, wherein a PDCP Packet Data Unit (PDU) header of a PDCP packet includes a field indicating sub-DRB identification, and wherein a Radio Link Control (RLC) PDU header of an RLC packet includes a field indicating sub-DRB identification.4.The method of Claim 2, wherein each sub-DRB is associated with a PDCP sequence number space, each sub-DRB is associated with a respective Radio Link Control (RLC) sequence number space in an event that an RLC layer exists and the sub-DRBs are applied to the RLC layer, and the sub-DRBs are associated with a same RLC sequence number space in an event that the RLC layer exists but the sub-DRBs are not applied to the RLC layer.5.The method of Claim 1, wherein the plurality of data bearer entities include a plurality of Data Radio Bearers (DRBs) , and wherein the plurality of IP flows are mapped to the plurality of DRBs in a Service Data Adaptation Protocol (SDAP) layer.6.The method of Claim 5, wherein each DRB is associated with a PDCP sequence number space and a Radio Link Control (RLC) sequence number space.7.The method of Claim 1, wherein the establishing of a plurality of data bearer entities with the another apparatus further comprises:determining, by the processor, a specific IP flow;exchanging, by the processor, information of mapping the specific IP flow to a corresponding data bearer entity with the another apparatus; andestablishing, by the processor, the corresponding data bearer entity with the another apparatus.8.The method of Claim 1, wherein the establishing of a plurality of data bearer entities with the another apparatus further comprises:determining, by the processor, a specific IP flow; andestablishing, by the processor, a corresponding data bearer entity with the another apparatus, wherein the corresponding data bearer entity is mapped to the specific IP flow.9.The method of Claim 1, wherein the establishing of a plurality of data bearer entities with the another apparatus further comprises:transceiving, by the processor, a configuration of the plurality of data bearer entities, wherein the configuration includes a hash function of mapping the plurality of data bearer entities to the plurality of IP flows; andestablishing, by the processor, the plurality of data bearer entities with the another apparatus.10.The method of Claim 1, further comprising:performing, by the processor, at least one of a Packet Data Convergence Protocol (PDCP) Packet Data Unit (PDU) processing operation, a Radio Link Control (RLC) PDU processing operation, and a lossless handover operation per data bearer entity.11.An apparatus, comprising:a transceiver which, during operation, wirelessly communicates with a wireless network; anda processor communicatively coupled to the transceiver such that, during operation, the processor performs operations comprising:establishing a plurality of data bearer entities with another apparatus, wherein the plurality of data bearer entities are mapped to a plurality of Internet Protocol (IP) flows, and wherein the apparatus and the another apparatus are located in a Radio Access Network (RAN) ; andtransceiving, via the transceiver, a plurality of packets associated with the plurality of IP flows with the another apparatus via the plurality of data bearer entities based on a result of mapping the plurality of IP flows to the plurality of data bearer entities.12.The apparatus of Claim 11, wherein the plurality of data bearer entities include a plurality of sub-Data Radio Bearers (DRBs) within one DRB, and wherein the plurality of IP flows are mapped to the plurality of sub-DRBs in a Packet Data Convergence Protocol (PDCP) layer.13.The apparatus of Claim 12, wherein a PDCP Packet Data Unit (PDU) header of a PDCP packet includes a field indicating sub-DRB identification, and wherein a Radio Link Control (RLC) PDU header of an RLC packet includes a field indicating sub-DRB identification.14.The apparatus of Claim 12, wherein each sub-DRB is associated with a PDCP sequence number space, each sub-DRB is associated with a respective Radio Link Control (RLC) sequence number space in an event that an RLC layer exists and the sub-DRBs are applied to the RLC layer, and the sub-DRBs are associated with a same RLC sequence number space in an event that the RLC layer exists but the sub-DRBs are not applied to the RLC layer.15.The apparatus of Claim 11, wherein the plurality of data bearer entities include a plurality of Data Radio Bearers (DRBs) , and wherein the plurality of IP flows are mapped to the plurality of DRBs in a Service Data Adaptation Protocol (SDAP) layer.16.The apparatus of Claim 15, wherein each DRB is associated with a PDCP sequence number space and a Radio Link Control (RLC) sequence number space.17.The apparatus of Claim 11, wherein, during operation, the processor further performs operations comprising:determining a specific IP flow;exchanging, via the transceiver, information of mapping the specific IP flow to a corresponding data bearer entity with the another apparatus; andestablishing the corresponding data bearer entity with the another apparatus.18.The apparatus of Claim 11, wherein, during operation, the processor further performs operations comprising:determining a specific IP flow; andestablishing a corresponding data bearer entity with the another apparatus, wherein the corresponding data bearer entity is mapped to the specific IP flow.19.The apparatus of Claim 11, wherein, during operation, the processor further performs operations comprising:transceiving, via the transceiver, a configuration of the plurality of data bearer entities, wherein the configuration includes a hash function of mapping the plurality of data bearer entities to the plurality of IP flows; andestablishing the plurality of data bearer entities with the another apparatus.20.The apparatus of Claim 11, wherein, during operation, the processor further performs operations comprising:performing, by the processor, at least one of a Packet Data Convergence Protocol (PDCP) Packet Data Unit (PDU) processing operation, a Radio Link Control (RLC) PDU processing operation, and a lossless handover operation per data bearer entity.

Images