WO2018031081A1

WO2018031081A1 - Systems and methods for packet data convergence protocol sequencing

Info

Publication number: WO2018031081A1
Application number: PCT/US2017/026857
Authority: WO
Inventors: Jerome Parron; Jing Zhu
Original assignee: Intel IP Corporation
Priority date: 2016-08-08
Filing date: 2017-04-10
Publication date: 2018-02-15

Abstract

Methods, systems, and storage media for improving packet data convergence protocol (PDCP) sequencing in wireless communications networks are described. In embodiments, a computer device may determine that a data radio bearer (DRB) is to be classified into individual flows of a plurality of flows; and may instantiate a plurality of PDCP entities where individual PDCP entities of the plurality of PDCP entities process corresponding flows of the plurality of flows. The computer device may classify received packets of the DRB into the corresponding flows; and provide, to the individual PDCP entities of the plurality of PDCP entities, the classified packets of the corresponding flows. Other embodiments may be described and/or claimed.

Description

SYSTEMS AND METHODS FOR PACKET DATA CONVERGENCE PROTOCOL

SEQUENCING

RELATED APPLICATIONS

The present application claims priority under 35 U.S.C. § 119 to U.S. Provisional Application No. 62/372, 138 filed on August 8, 2016, which is hereby incorporated by reference in its entirety.

FIELD

Various embodiments of the present application generally relate to the field of wireless communications, and in particular, to improving packet data convergence protocol (PDCP) sequencing in wireless communications networks.

BACKGROUND

Protocol stacks used in most cellular communications networks, such as Long Term Evolution (LTE), LTE-Advanced (LTE-A), Next Generation Cellular Network (5G NR, etc.), and the like, may include a packet data convergence protocol (PDCP) layer. The PDCP layer may provide services to a radio resource control (RRC) layer and user plane upper layers at a user equipment (UE) or an evolved Node B (eNB) or a general Node B (gNB). The PDCP layer may perform various functions including ordering incoming packets according to each packet's sequence number (SN), and in-sequence delivery of those packets to other layers. Many cellular communications networks also use radio bearers (for example, data radio bearers (DRBs), sidelink radio bearers (SLRBs), and signalling radio bearers (SRB)) to route data flows to and from a UE. When a radio bearer is established, a PDCP entity may be created to order packets flowing through the radio bearer. According to current cellular communications standards, each radio bearer is associated with one PDCP entity.

However, the packets that flow through a particular radio bearer (for example, a

DRB) may belong to more than one data flow. Additionally, according to current cellular communications standards, the PDCP layer does not differentiate between the different flows traveling through a DRB. This may result in packet processing delays because packets of a flow in a DRB may have to wait for other packets of another flow to be processed due to the SN order of the other packets. Additionally, because the PDCP layer is required to provide in-sequence delivery of packets to other layers, if a packet is missing, then processing of all other packets, including packets belonging to different flows, may be delayed while packet re-transmission procedures take place. Once solution to these shortcomings may include setting up an individual DRB for an individual data flow. However, these solutions require more signaling to establish additional DRBs, which may increase overhead costs associated with increased network resource consumption.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

FIG. 1 illustrates a cellular communications network in accordance with various example embodiments;

FIG. 2 illustrates a logical representation of various embodiments discussed herein;

FIG. 3 illustrates an example protocol stack, in accordance with various embodiments;

FIG. 4 illustrates example packet data convergence protocol (PDCP) protocol data units (PDUs), in accordance with various embodiments;

FIG. 5 illustrates example components of an electronic device for wireless communication, in accordance with various example embodiments; and

FIG. 6 illustrates an example process that may be performed by an electronic device to perform various embodiments discussed herein.

DETAILED DESCRIPTION

Embodiments discussed herein relate to improving packet data convergence protocol (PDCP) sequencing in wireless communications networks. Embodiments provide a flow-based quality of service (QoS) framework that may be employed in wireless communication networks. In embodiments, a core network (CN) (or a network element therein) may perform flow level QoS control and enforcement procedures. In embodiments, the CN (or a network element therein) may transfer per-Flow QoS information to a Radio Access Network (RAN), and the QoS control may be performed in the RAN on a per-flow basis or may implement traditional radio bearer (RB) concepts. In other embodiments, the RAN itself or a user equipment (UE) may perform the flow level QoS control and enforcement procedures.

In embodiments, the flow-based QoS framework may be implemented by a computer device, such as a UE and/or a base station (for example, an evolved nodeB (eNB), a next generation nodeB (gNB), and the like). In such embodiments, the computer device may instantiate a plurality of PDCP entities to process a corresponding plurality of flows of a data radio bearer (DRB). As used herein, the terms "instantiate", "instantiation", and the like may refer to the creation of an instance, and an "instance" may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. The computer device may also classify traffic of the DRB into individual flows of the plurality of flows and provide the traffic of the individual flows to a corresponding PDCP entity. In embodiments, the classification of the individual flows may be based on a flow classification rule (also referred to as a "flow classification configuration"). In such embodiments, the flow classification rule may be generated by a network element (for example, an eNB/gNB or a CN element) and signaled to the UE, generated by the UE and signaled to the network element, or independently generated by each of the UE and the network element without requiring over-the-air (OTA) signaling of the flow classification rule.

Embodiments also provide various PDCP enhancements to allow the PDCP instances to identify a flow to which a packet may belong. In embodiments, each packet may include a new flow identifier field in a header portion of a PDCP packet or protocol data unit (PDU), portions of existing fields of a PDCP packet/ PDU, or the PDCP payload (for example, the beginning or the end of the packet/PDU) may be used for flow identification. Other embodiments may be described and/or claimed.

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc., in order to provide a thorough understanding of the various aspects of the claimed invention. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the invention claimed may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.

Further, various operations will be described as multiple discrete operations, in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

The phrase "in various embodiments," "in some embodiments," and the like are used repeatedly. The phrase generally does not refer to the same embodiments; however, it may. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrase "A and/or B" means (A), (B), or (A and B). The phrases "A/B" and "A or B" mean (A), (B), or (A and B), similar to the phrase "A and/or B ." For the purposes of the present disclosure, the phrase "at least one of A and B" means (A), (B), or (A and B). The description may use the phrases "in an embodiment," "in embodiments," "in some embodiments," and/or "in various embodiments," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

Example embodiments may be described as a process depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently, or simultaneously. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but may also have additional steps not included in the figure(s). A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and the like. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function and/or the main function.

As used herein, the term "circuitry" refers to, is part of, or includes hardware components such as an Application Specific Integrated Circuit (ASIC), an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. Example embodiments may be described in the general context of computer-executable instructions, such as program code, software modules, and/or functional processes, being executed by one or more of the aforementioned circuitry. The program code, software modules, and/or functional processes may include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular data types. The program code, software modules, and/or functional processes discussed herein may be implemented using existing hardware in existing communication networks. For example, program code, software modules, and/or functional processes discussed herein may be implemented using existing hardware at existing network elements or control nodes.

As used herein, the term "processor circuitry" refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations; recording, storing, and/or transferring digital data. The term "processor circuitry" may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes. As used herein, the term "interface circuitry" refers to, is part of, or includes circuitry providing for the exchange of information between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces (for example, buses, input/output (I/O) interfaces, peripheral component interfaces, and the like).

As used herein, the term "user equipment" may be considered synonymous to, and may hereafter be occasionally referred to, as a client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, UE, subscriber, user, remote station, access agent, user agent, receiver, etc., and may describe a remote user of network resources in a communications network. Furthermore, the term "user equipment" may include any type of wireless/wired device such as consumer electronics devices, cellular phones, smartphones, tablet personal computers, wearable computing devices, personal digital assistants (PDAs), desktop computers, and laptop computers, for example.

As used herein, the term "network element" may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, and/or any other like device. The term "network element" may describe a physical computing device of a wired or wireless communication network and be configured to host a virtual machine. Furthermore, the term "network element" may describe equipment that provides radio baseband functions for data and/or voice connectivity between a network and one or more users. The term "network element" may be considered synonymous to and/or referred to as a "base station." As used herein, the term "base station" may be considered synonymous to and/or referred to as a node B, an enhanced or evolved node B (e B), base transceiver station (BTS), access point (AP), etc., and may describe equipment that provides the radio baseband functions for data and/or voice connectivity between a network and one or more users.

It should also be noted that the term "channel" as used herein may refer to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. Additionally, the term "channel" may be synonymous with and/or equivalent to "communications channel," "data communications channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radiofrequency carrier," and/or any other like term denoting a pathway or medium through which data is communicated.

FIG. 1 illustrates an example of a cellular communications network 100 (also referred to as "network 100" and the like), according to various embodiments. Network 100 includes UEs 105, two base stations (BSs) 110 (BS 110-1 and BS 110-2 are collectively referred to as "BS 110" or "BSs 110"), and to cells 115 (cell 115-1 and cell 115-2 are collectively referred to as "cell 115" or "cells 115"). The following description is provided for an example network 100 that operates in conjunction with the Long Term Evolution (LTE) standard as provided by 3rd Generation Partnership Project (3GPP) technical specifications (TS). However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as new radio access technologies (NR) and the like. In addition, the following description provided for functionality of the UE 105 and/or downlink (DL) transmissions may be equally applicable to network-side (e.g., BS 110, CN 140, etc.) functionality and/or uplink (UL) transmissions unless stated otherwise.

Referring to FIG. 1, UE 105 may be a physical hardware device capable of running one or more applications and capable of accessing network services via one or more radio links 120 (radio link 120-1 and radio link 120-2 are collectively referred to as "radio links 120" or "links 120") with corresponding BSs 110. A link 120 may allow the UE 105 to transmit and receive data from a BS 110 that provides the link 120. To transmit/receive data to/from one or more BSs 110, UE 105 may include a transmitter/receiver (or alternatively, a transceiver), memory, one or more processors, and/or other like components that enable UE 105 to operate in accordance with one or more wireless communications protocols and/or one or more cellular phone communications protocols. In various embodiments, UE 105 may have multiple antenna elements that enable the UE 105 to maintain multiple links 120 to transmit/receive data to/from multiple BSs 110. For example, as shown in FIG. 1, UE 105 may connect with BS 110-1 via link 120-1 and simultaneously connect with BS 110-2 via link 120-2. Furthermore, UE 105 may be capable of measuring various cell-related criteria, such as channel conditions and signal quality (for example, reference signal received power (RSRP), reference signal received quality (RSRQ), and the like), and provide a measurement report including this information to a BS 110. Examples of UE 105 may include a wireless phone or smartphone, a laptop personal computer (PC), a tablet PC, a wearable computing device, an autonomous sensor or other like machine type communication (MTC) device, and/or any other physical device capable of recording, storing, and/or transferring digital data to/from BS 110 and/or any other like network element.

The BSs 110 are hardware computing devices configured to provide wireless communication services to mobile devices (for example, UE 105) within a coverage area or cell 115 associated with a BS 110 (for example, cell 115-1 associated with BS 110-1). In embodiments where the cellular communications network 100 is an LTE or LTE-A system, the BSs 110 may be referred to as evolved nodeBs (e Bs) 110 and the like. In embodiments where the cellular communications network 100 is an R system, the BSs 110 may be referred to as next generation nodeBs (gNBs) 110, transmission reception points (TRPs) 110, and the like. In some embodiments, at least one of the BSs 110 may be a WiFi access point (AP), such as a router, switch, hub, gateway device, or other like network element that provides connection to a Wireless Local Area Network (WLAN) in accordance with an Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol.

A cell 115 providing services to UE 105 may also be referred to as a "serving cell,"

"cell coverage area," and the like. As discussed previously, BSs 110 may provide wireless communication services to UE 105 via links 120. The links 120 between the BSs 110 and the UE 105 may include one or more DL (or forward) channels for transmitting information from BS 110 to UE 105. Although not shown by FIG. 1, links 120 may also include one or more UL (or reverse) channels for transmitting information from UE 105 to a BS 110. The channels may include the physical downlink shared channel (PDSCH), physical downlink control channel (PDCCH), physical hybrid automatic repeat request (HARQ) indicator channel (PHICH), physical control format indicator channel (PCFICH), physical broadcast channel (PBCH), physical uplink shared channel (PUSCH), physical uplink control channel (PUCCH), physical random access channel (PRACH), and/or any other like communications channels or links used to transmit/receive data.

The BSs 110 include a transmitter/receiver (or alternatively, a transceiver) connected to one or more antennas, one or more memory devices, one or more processors, and/or other like components. The one or more transmitters/receivers may be configured to transmit/receive data signals to/from one or more UEs 105 within its cell 115 via one or more links that may be associated with a transmitter and a receiver. In embodiments where network 100 employs the LTE or LTE-A standard, one or both BSs 110 may employ Evolved Universal Terrestrial Radio Access (E-UTRA) protocols, for example, using orthogonal frequency-division multiple access (OFDMA) for scheduling and transmitting DL communications and single carrier frequency-division multiple access (SC-FDMA) for scheduling and receiving UL communications from UE 105. When one of the BSs 110 acts as a WiFi AP, that BS 110 may use direct-sequence spread spectrum (DSSS) signaling, OFDM signaling, etc., according to the particular version of the IEEE 802.11 protocol being. Different protocols may be used in embodiments where network 100 employs other cellular communications standard.

Furthermore, BSs 110 may be capable of communicating with one another over a backhaul connection 125 and may communicate with one or more servers 135 within a core network (CN) 140 over another backhaul connection 130. In embodiments where network 100 employs the LTE/LTE-A and/or R standards, backhaul connection 125 may include a wired connection employing an X2 interface, which defines an interface for communicating data packets directly between BSs 110. In embodiments where one BS 110 is an e B or g B and the other BS 110 is a WiFi AP, the backhaul connection may include a wired or wireless connection employing an Xw interface. Furthermore, in such embodiments the backhaul connection 130 may include a wired connection employing an SI interface, which defines a protocol for the forwarding of packets indirectly between BSs 110 by way of one or more mobility management entities (MMEs), one or more Serving Gateways (SGWs), and/or other like core network elements. In embodiments, various HO-related messages may be communicated directly between the BSs 110 over the X2 interface (for example, during an X2-HO operation or an Intra-MME HO, or to forward packets to a secondary e B (SeNB) in DC mode) or between the BSs 110 and CN elements over the SI interface (for example, during an SI -HO operation or an Inter-MME HO, or to receive user-plane data from the CN 140).

In many deployment scenarios, an end-to-end bearer may be established between the UE 105 and a device 150. The device 150 may be a UE that is the same or similar to UE 105, a desktop PC, server, or some other electronic device. As discussed previously, a bearer may be a tunnel or pipeline connecting two or more points (e.g., UE 105 and device 150) through which a data flow may travel. Bearers that carry user plane traffic may be referred to as data radio bearers (DRBs), and bearers that carry control plane traffic may be referred to as signaling radio bearers (SRBs).

In embodiments, DRBs may be established according to normal procedures, for example, during an Evolved Packet System (EPS) Session Establishment procedure between the UE 105, a BS 110, and/or one or more elements within the CN 140 (for example, a mobility management entity (MME)). The EPS Session Establishment procedure may include initial attachment procedures, connection re-establishment procedure, among other procedures. During the DRB establishment procedure, the BS 110 may signal a Radio Resource Control (RRC) message (for example, an RRC Connection Setup message, an RRC Connection Reconfiguration message, an RRC Connection Re- establishment message, and the like) to the UE 105 to setup the radio bearer. The RRC message may include all the necessary configuration parameters to establish the radio interface and a radio bearer, such as radio bearer QoS parameters, a session management request, an EPS radio bearer identifier (ID) and/or DRB ID, and other like configuration parameters. In various embodiments, the RRC message may be enhanced to notify the UE 105 that flow-based PDCP functionality is configured. For example, in some embodiments, the UE 105 may signal a first RRC message (for example, a UECapability Information message) to a BS 110 to indicate that the UE 105 supports flow- based PDCP functionality. In response, the BS 110 may activate or configure the UE 105 with flow-based PDCP functionality by signaling a second RRC message (for example, an RRC Connection Reconfiguration message) to the UE 105 that may include a new element/field in an information element (IE) (for example, a new element/field in the PDCP-Config), which may be used to indicate that flow-based PDCP should be used for a particular radio bearer. In other embodiments, a Non-Access Stratum (NAS) message may be enhanced to notify the UE 105 that flow-based PDCP is configured. NAS signaling may be used in scenarios where filter rules used to identify individual flows are provided at the NAS level. This may be done in a similar manner as configuring traffic flow template (TFT) filters at the NAS layer. In embodiments, the NAS layer/entity may be in charge of flow detection, setting flow identifiers for individual flows (for example, in PDCP service data units (SDUs)), and mapping individual flows to DRBs. In such embodiments, the access stratum (AS) layer may be responsible for creating new PDCP entities for individual flows. In such embodiments, the UE 105 may indicate that the UE 105 supports flow- based PDCP functionality using, for example, a UE Network Capability IE of an Attach Request message or Tracking Area Update message (or equivalent messages for NG implementations). In response, a network element (for example, an MME) may activate or configure the UE 105 with flow-based PDCP functionality when activating an EPS bearer using, for example, an "activate default EPS bearer context request" message or an "activate dedicated EPS bearer context request" message, which may be a NAS message encapsulated in an RRC message (for example, an RRC Connection Reconfiguration message, and the like).

Regardless of how flow-based PDCP procedures are configured, when a DRB is established, a PDCP instance may be created to perform various PDCP functions (for example, aggregate, (re-)order, cipher/decipher, etc.) for packets of an individual flow according to their corresponding flow IDS and/or sequence numbers (SNs) as discussed herein.

In embodiments, the network 100 may implement one or more multi-cell aggregation technologies, such as Dual-Connectivity (DC), LTE-WLAN Aggregation (LWA), and/or LTE-NR aggregation. In such embodiments, split bearers may be used to provide higher throughput by combining the resources available at multiple cells 115. Additionally, split bearers may be used to convey packets with different QoS requirements over separate links 120.

In DC mode, DL transmissions may be conveyed to the UE 105 according to the following example: user plane data from the CN 140 may be first transferred to the BS 110-1 operating as a master eNB (MeNB) or primary cell (PCell) 115-1. At the BS 110-1, the DRB may be split so that some data packets are transmitted to the UE 105 via the PCell 115-1, while other data packets are transmitted to the UE 105 by BS 110-2 operating as the secondary eNB (SeNB) or a secondary cell (SCell) 115-2. The other data packets to be transmitted by BS 110-2 may be transferred over the backhaul connection 125 from BS 110-1 to BS 110-2. In some cases, the data packets transmitted by the BS 110-1 and the BS 110-2 may belong to the same flow. In various embodiments, packets belonging to an individual flow may be transmitted over a specified link 120 (for example, link 120-1), while other packets may be transmitted over a different link 120 (for example, link 120-2). Typically, all the packets received by the UE 105, from either BS 110-1 or BS 110-2 may be aggregated, cipher/deciphered, and re-ordered at a PDCP layer of the UE 105. In embodiments, all the packets received by the UE 105, from either BS 110-1 or BS 110-2 may be classified as belonging to individual flows, and the classified packets may be provided to corresponding PDCP entities to be aggregated, cipher/deciphered, and reordered. For example, embodiments provide that packets of a first flow may be received from BS 110-1 over link 120-1 and provided to a first PDCP entity for processing, while packets of a second flow may be received from BS 110-2 over link 120-2 and provided to a second PDCP entity for processing. This may reduce the need for aggregation of an individual flow, which may reduce the end-to-end and delay for that flow.

In the UL direction, the UE 105 may transmit some packets to BS 110-1 acting as the Me B and other packets to BS 110-2 acting as the Se B. Typically, the other data packets received by BS 110-2 may be transferred over the backhaul connection 125 from BS 110-2 to BS 110-1, where the PDCP entity at BS 110-1 may aggregate, decipher, and re-order the packets for upper layer entities. In embodiments, all the packets received by the BS 110-1, from either the UE 105 or BS 110-2 may be classified as belonging to individual flows, and the classified packets may be provided to corresponding PDCP entities to be aggregated, cipher/deciphered, and re-ordered. Similar to the DL direction, packets of a first flow may be received from UE 105 over link 120-1 and provided to a first PDCP entity for processing, while packets of a second flow may be received from BS 110-2 over backhaul link 125 and provided to a second PDCP entity for processing.

In LTE- R aggregation mode, UL and DL transmissions may be communicated to/from the UE 105 in a similar manner as in DC mode except that one BS 110 (for example BS 110-1) may be an "LTE e B" that only provides connectivity to an EPC CN 140 or may be an "eLTE eNB", which is an eNB that supports connectivity to both EPC and NG CNs 140, and another BS (for example, BS 110-2) may be a gNB that supports connectivity to a NG CN 140, for example. Additionally, either BS 110 may act as a master node or a secondary node. One difference between LTE-NR aggregation and DC mode is that user-plane traffic may be routed to an EPC CN 140 when an LTE eNB is acting as the master node, or user-plane traffic may be routed to an NG CN 140 when a gNB or eLTE e B acts as the master node.

In LWA mode, DL transmissions may be conveyed to the UE 105 in a similar manner as in DC mode except that the BS 110-2 may act as a WiFi AP, for example. In such embodiments, the BS 110-1 may perform scheduling for PDCP packets at its PDCP layer, and may transmit some packets over an LTE (or R) interface (for example, the "Uu interface") and other packets may be provided to the BS 110-2 for transmission over a WiFi interface. The BS 110-1 may transmit these packets to the BS 110-2 after encapsulating the packets in LWA Adaptation Protocol (LWAAP) packets/units/frames, which carry the bearer identity. Typically, all of the packets received over the LTE and WiFi interfaces may be aggregated and re-ordered at a PDCP layer of the UE 105. In embodiments, packets received by the UE 105 may be processed in a similar manner as discussed with regard to the DC mode, such as classifying packets as belonging to individual flows, and providing the classified packets to corresponding PDCP entities to be aggregated, cipher/deciphered, and re-ordered. Additionally, packets received by the UE 105 from BS 110-1 may be classified as belonging to a first individual flow and provided to a corresponding first PDCP entity to be aggregated, cipher/deciphered, and reordered, while packets received by the UE 105 from BS 110-2 may be classified as belonging to a second individual flow and provided to a corresponding second PDCP entity to be aggregated, cipher/deciphered, and re-ordered.

In the UL direction, the UE 105 may transmit some packets to LTE (or NR) BS 110-1 and other packets to the WiFi AP BS 110-2. Typically, the other data packets received by the BS 110-2 may be transferred over a backhaul connection 125 (for example, the Xw interface) from BS 110-2 to BS 110-1, where the PDCP entity at BS 110-1 may aggregate and re-order the packets for upper layer entities. In embodiments, all the packets received by the BS 110-1, from either the UE 105 or BS 110-2 may be classified as belonging to individual flows, and the classified packets may be provided to corresponding PDCP entities to be aggregated, cipher/deciphered, and re-ordered. Similar to the DL direction, packets of a first flow may be received from UE 105 over link 120-1 and provided to a first PDCP entity for processing, while packets of a second flow may be received from BS 110-2 over backhaul link 125 and provided to a second PDCP entity for processing.

Regardless of whether or not multi-cell aggregation technologies are implemented, in conventional systems re-ordering and aggregation operations may be accomplished at the PDCP layer of a receiver entity using PDCP SNs, and PDCP SNs may be managed on a per-bearer basis. The re-ordering may be required to ensure that all received packets are delivered in sequence to upper layers, and in DC or LWA systems, the re-ordering operations of the PDCP entity may be required even if individual links have different available bandwidths and/or latency. Since data flows from different applications with different latency constraints may be transmitted in the same DRB, in conventional systems, data packets of a first flow may be pending in a re-ordering queue waiting for the reception of data packets of a second flow, which may arrive over another link 120 in DC or LWA systems. This may lead to increased latency or delay for processing packets of the first flow.

According to various embodiments, multiple flows may be assigned to a single DRB and individual PDCP instances may be generated to aggregate, cipher/decipher, and re-order packets of individual flows of a same DRB. In some embodiments, lower layer entities (for example, radio link control (RLC) entities and media access control (MAC) entities) may support individual queues for individual flows of a same DRB. Additionally, the PDCP instances at the UE 105 and/or BSs 110 may aggregate, cipher/decipher, and reorder packets of individual flows based on flow ID and/or an SN included in obtained PDCP packets. Examples of such embodiments are shown and described with regard to FIGS. 2-6.

According to various embodiments, once a DRB is established, a default PDCP entity may be created/generated to process all packets of the DRB. After the default PDCP entity is created, a flow classification rule (also referred to as a "flow classification configuration" and the like) may be activated. The flow classification rule may indicate various parameters for identifying and/or labeling packets belonging to an individual flow and various parameters for processing packets of an individual flow. For example, the flow classification rule may indicate a tag, QoS ID, or flow ID that belongs to an individual flow; a location of a tag/QoS ID/flow ID in individual received packets; a location of a tag/QoS ID/flow ID to be inserted into individual packets for transmission; the size (in bits or bytes) of the tag/QoS ID/flow ID; a destination for the packets once processed, a link over which the packets of the flow will be received or should be sent (for example, in DC or LWA implementations), and/or other like parameters. In some embodiments, the flow classification rule may be provided by upper layers. Additionally, a flow classification rule may map traffic from different protocol data unit (PDU) sessions to different DRBs. In embodiments, an IP flow may be mapped to a QoS flow or class and a DRB. For example, in some embodiments mapping of IP flows may include a two-step procedure for DL and UL transmissions, in which a NAS entity may be responsible for mapping an IP flow to a QoS flow/class, and access stratum (AS) entity may be responsible for the mapping the QoS flow/class to an individual DRB. In another embodiment, a NAS entity may be responsible for flow identification and creation/addition of the flow ID, and the AS entity may be responsible for creation of a new PDCP entity to manage the identified flow when that flow is reported to the AS entity by the NAS entity.

In embodiments, a flow classification rule may be activated and/or configured at the NAS layer and/or AS layer. In one example, a flow classification rule may be activated when a flow ID is obtained by the PDCP layer from a NAS layer, where receipt of the flow ID may cause PDCP entity creation by the BS 110 and/or the UE 105. In another example, a flow classification rule may be activated when a new flow is detected by an AS entity, where the detection may cause PDCP entity creation by the BS 110 and/or the UE 105. In alternative embodiments, a flow classification rule may be activated in advance (for example, at DRB setup), which may cause creation of a new PDCP entity even when there are no packets of an individual flow to transfer to the newly created PDCP entity. In such embodiments, the new PDPC entity may be created according to instructions/commands in the activated flow classification rule.

Once the flow classification rule is activated, the BS(s) 110 and UE 105 may create a new flow-specific PDCP entity, which may be used to process an individual flow. In some embodiments, the individual flow may be indicated by the flow classification rule. In such embodiments, all other packets of the DRB may still be processed by the default PDCP entity. After activation of the flow classification rule, another flow classification rule may be activated, which may cause the BS(s) 110 and UE 105 to create another flow- specific PDCP entity to process another individual flow indicated by the other flow classification rule. In such embodiments, all other packets of the DRB that are not included in both individual flows may still be processed by the default PDCP entity. There may be multiple flow-specific PDCP entities per DRB, which together with the default PDCP entity may be associated to the same RLC entity of the DRB. As a result, all traffic of the same DRB may be processed by the lower layer entities (for example, RLC and MAC entities) as belonging to the same bearer.

Using flow classification rules in this way may provide resource utilization efficiencies. For example, the flow classification rules may allow offloading of PDCP functionality to multiple processors or processor-cores, such as operating a first PDCP entity by a first processor, a second PDCP entity for a second processor, and so forth. In some embodiments, the individual PDCP entities may be operated by a corresponding virtual machine. With conventional bearer-based PDCP procedures, data received on multiple links must be aggregated and processed in the same PDCP entity, which may lead to reduced performance when applications for different flows run on different processors or when individual links operate on different processors. This is because all the data must be aggregated at the same PDCP entity. Additionally, in data aggregation implementations, the flow classification rules may indicate an individual link 120 over which an individual flow may be transmitted. This may reduce computational burdens on a cellular modem of the UE 105 by, for example, allowing a WiFi modem of the UE 105 to operate a PDCP entity for a flow that is received over a WiFi link.

In various embodiments, the flow classification rule may be internally configured at the UE 105, or may be configured by a BS 110. Where a BS 110 configures the traffic classification rule, the BS 110 may use a traffic flow template (TFT) to map a flow to individual packets, and may communicate the flow classification rule to the UE 105 using AS or NAS signaling. In alternative embodiments, the UE 105 may determine the flow classification rule, for example, based on a local application programming interface (API) for various applications, and may communicate the flow classification rule to a BS 110 using AS (for example, RRC signaling) or NAS signaling. According to various embodiments, there may be three ways to activate flow classification rules.

In first embodiments, flow classification rules may be activated by the UE 105. In such embodiments, the UE 105 may determine how to map a flow for both DL and UL transmissions, and may send the DL flow classification rule to the BS 1 10 and/or a CN 140 element (for example, an MME, PGW, etc.).

In second embodiments, flow classification rules may be activated by the BS 110 or a CN 140 element (for example, an MME, PGW, etc.). In such embodiments, the BS 110 or a CN 140 element may determine how to map a flow for both DL and UL, and may send the UL flow classification rule to the UE 105. In embodiments where the CN 140 element (for example, an MME, PGW, etc.) determines the flow classification rule, the CN 140 element may send the DL flow classification rule to BS 110, which may in turn provide the flow classification rule to the UE 105.

In third embodiments, flow classification rules may be activated by the UE 105 and the BS 110 or CN 140 element independently. In such embodiments, the UE 105 may determine how to map a flow for UL transmissions, and the BS 110 or CN 140 element may determine how to map a flow for DL transmissions. In such embodiments, the flow classification rules may not be signaled OTA. In embodiments where the CN 140 element (for example, an MME, PGW, etc.) determines the flow classification rule, the CN 140 element may provide the DL flow classification rule to the BS 110.

In various embodiments, when a flow classification rule is activated, a sending/transmitting entity may identify or classify a new flow to be transmitted. In embodiments, Internet Protocol (IP) tuples or subset/combinations of IP tuples may be used to identify or classify a flow. The tuples may include a source IP address, a source port, a destination IP address, and a destination port. In some embodiments, a flow may be identified based on a range of ports, a range of IP addresses, and/or a combination of various port ranges and/or various IP address ranges. In some embodiments, the sending/transmitting entity may map all tuples having the QoS requirements or the same QCI to the same flow. Additionally or alternatively, when a flow classification rule is activated, a sending/transmitting entity may identify or classify a new flow to be transmitted according to one or more QoS characteristics. The QoS characteristics/requirements may comprise a QoS class ID (QCI), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level. Additionally or alternatively, when a flow classification rule is activated, a sending/transmitting entity may identify or classify a new flow to be transmitted based on a tag or identification field of a header portion of received packets or an API of the system/application from which the packets are obtained. These embodiments may be applicable when the packets are received/obtained from upper layers, such as a transmission control protocol (TCP)/IP layer/entity and/or an application layer/entity.

In embodiments where link aggregation mechanisms are used (for example DC or

LWA), the UE 105 and/or BSs 110 may select a link 120 over which to obtain or send individual flows. The link 120 selection or routing selection can be either determined by the UE 105 itself or configured by the BS 110 or a CN element. The link selection may be based on QoS requirements/characteristics (discussed previously) for an individual flow and a channel quality of a particular link 120. For example, when the UE 105 operates an application with real-time or near real-time latency requirements, the UE 105 or a BS 110 may select a link 120 that has less latency and jitter than other links 120 for communicating packets for that application rather than sending packets of an individual flow over both links 120. This is because, in some cases, high throughput may be less of a concern for applications with real-time or near real-time latency requirements when compared to applications with relatively high latency and jitter tolerance. For applications with less stringent latency and/or QoS requirements, throughput may be more important, and in such cases, the UE 105 or BS 1 10 may send packets for an individual flow over both links 120 in a similar manner as convention link aggregation procedures.

Although not shown by FIG. 1, each BS 1 10 may be part of a radio access network (RAN) or associated with a radio access technology (RAT). In embodiments where communications network 100 employs the LTE standard, the RAN may be referred to as an evolved universal terrestrial radio access network (E-UTRAN). In embodiments where communications network 100 employs NR. standards, the RAN may be referred to as an NR. RAN, a next generation RAN (gRAN), and the like. RANs and their typical functionality are generally well-known, and thus, a further detailed description of the typical functionality of RAN is omitted.

The network 100 may include CN 140, which may include one or more hardware devices, such as the one or more servers 135. The CN 140 may be an EPC CN or a next generation (NG) CN. These servers may provide various telecommunications services to the UEs 105. In embodiments where network 100 employs the LTE standards, the one or more servers 135 of the CN 140 may comprise components of the System Architecture Evolution (SAE) with an Evolved Packet Core (EPC) as described by 3 GPP technical specifications. In such embodiments, the one or more servers 135 of the CN 140 may include components such as one or more MMEs and/or Serving General Packet Radio Service Support Nodes (SGSNs) (which may be referred to as an "SGSN/MME"), a serving gateway (SGW), packet data network (PDN) gateway (PGW), home subscriber server (HSS), access network discovery and selection function (ANDSF), evolved packet data gateway (ePDG), an MTC interworking function (ΓνΥΤ), and/or other like components as are known. In embodiments where network 100 employs NR standards, the one or more servers 135 of the CN 140 may comprise the same components as an EPC core, enhanced versions of those elements, and/or additional or different elements not yet defined. The various elements of the CN 140 may route phone calls from UE 105 to other mobile phones or landline phones, or provide the UE 105 with a connection to the internet 145 for communication with one or more other computer devices, such as device 150. Because the components of the SAE core network and their functionality are generally well-known, a further detailed description of the SAE core network is omitted. The aforementioned functions may be provided by the same physical hardware device or by separate components and/or devices.

FIG. 2 illustrates a logical representation of various embodiments discussed herein. FIG. 2 shows three DRBs including DRB1 205A ("first DRB") with three flows 210 (flowl 21 OA, flow2 21 OB, and flow3 2 IOC). Additionally, arrangement 200 includes DRB2 205B ("second DRB") and DRB 3 205C ("third DRB") each have a corresponding flow 210 (flow4 210D of DRB2 210B and flow5 210E of DRB3 210C). Although FIG. 2 only shows a single DRB with three flows, in various embodiments more than one DRB may have a plurality of flows, and each DRB may include any number of flows.

FIG. 3 illustrates an example protocol stack 300, in accordance with various embodiments. The protocol stack 300 may correspond to the DRBs 205 and flows 210 shown by FIG. 2. As shown by FIG. 3, each of PDCP entities 310A-E in the protocol stack 300 correspond with the flows 210A-E of FIG. 2, .respectively. For example, PDCP entity 310A in FIG. 3 may correspond to flowl 210A of DRB1 205A in FIG. 2, PDCP entity 310B in FIG. 3 may correspond to flow2 210B of DRB 1 205 A in FIG. 2, PDCP entity 3 IOC in FIG. 3 may correspond to flow3 2 IOC of DRB 1 205 A in FIG. 2, PDCP entity 310D in FIG. 3 may correspond to flow4 210D of DRB2 210B in FIG. 2, and PDCP entity 310E in FIG. 3 may correspond to flow5 210E of DRB3 2 IOC in FIG. 2. Additionally, the protocol stack includes a default PDCP entity 310Z for each of the DRBs 205. The default PDCP entities 310Z may perform the various PDCP functions for received packets that do not belong to either of the flow-based PDCP entities 310A-E. Further, each DRB 205 may have a corresponding RLC entity 305, for example, RLC entity 305A in FIG. 3 may correspond with DRB 205 A in FIG. 2, RLC entity 305B in FIG. 3 may correspond with DRB 205B in FIG. 2, and RLC entity 305C in FIG. 3 may correspond with DRB 205C in FIG. 2. Furthermore, all of the DRBs 210 may correspond with the MAC entity 315.

The UE 105 and BSs 110-1 and 110-2 may each include a separate protocol stack 300. Each protocol stack 300 may be used as a control plane protocol stack for establishing radio-specific functionality, or may be used as a user plane protocol stack for establishing data-specific functionality including communicating data between the UE 105 and the BS 110 over an air interface, such as the LTE-Uu interface.

The main functions of the PDCP layers/entities 310 may include header compression and decompression of IP data flows using the Robust Header Compression (ROHC) protocol; transfer of data (user plane or control plane); maintenance of PDCP SNs; in-sequence delivery of upper layer protocol data units (PDUs) at re-establishment of lower layers; duplicate elimination of lower layer service data units (SDUs) at re- establishment of lower layers for radio bearers mapped on the RLC layer; ciphering and deciphering of user plane data and control plane data; integrity protection and integrity verification of control plane data; integrity protection and integrity verification of user plane data for relay nodes (RNs); timer based discard; duplicate discarding; and or split bearers, routing and reordering. According to various embodiments, the PDCP functions may be performed on a per-flow basis as discussed herein. For example, a plurality of PDCP entities, 310 may be instantiated, where individual PDCP entities 310 of the plurality of PDCP entities 310 may process corresponding flows 210 of a plurality of flows 210 and the instantiated PDCP entities 310 may perform any of the aforementioned functions and/or functions specified by 3GPP technical specification (TS) 36.323 V14.1.0 (2016-12) and/or other like TSs.

The main functions of the RLC layers/entities 305 may include transfer of upper layer PDUs; error correction through automatic repeat request (ARQ); concatenation, segmentation and reassembly of RLC SDUs; re-segmentation of RLC data PDUs; reordering of RLC data PDUs; duplicate detection; RLC SDU discard; RLC re- establishment; and protocol error detection. In some embodiments, the RLC entities 305 may each have a single queue for all PDUs of individual flows obtain from corresponding PDCP entities 310. This queue may be a first-in first-out (FIFO) queue where all PDCP entities 310 connected to the same RLC entity 305 may place PDUs in the same queue following the FIFO concept. In other embodiments, the RLC layers/entities 305 may include individual queues for PDUs of individual flows obtained from corresponding PDCP entities 310. For example, the DRB1 RLC entity 305A may include a "default queue" or buffer to store RLC SDUs including PDCP PDUs obtained from the default PDCP entity 310Z, a first queue or buffer to store RLC SDUs including PDCP PDUs obtained from the flowl PDCP entity 31 OA, a second queue or buffer to store RLC SDUs including PDCP PDUs obtained from the flow2 PDCP entity 310B, and a third queue or buffer to store RLC SDUs including PDCP PDUs obtained from the flow3 PDCP entity 3 IOC. In some embodiments, the individual queues may be prioritized according to the data delivered to or contained in the individual queues. For example, PDUs of individual flows may be marked with a "priority" or "QoS" indication, and the RLC entity 305 may select data from an individual queue associated with a highest priority flow for transmission before individual queues associated with lower priority flows. The main functions of the MAC layer/entity 315 may include mapping between logical channels and transport channels; multiplexing of MAC SDUs from one or different logical channels onto transport blocks (TB) to be delivered to the physical layer on transport channels; demultiplexing of MAC SDUs from one or different logical channels from transport blocks (TB) delivered from the physical layer on transport channels; scheduling information reporting; error correction through Hybrid Automatic Repeat Request (HARQ); priority handling between UEs by means of dynamic scheduling; priority handling between logical channels of one MAC entity; Logical Channel prioritization; transport format selection; radio resource selection for sidelink connections. In embodiments, the MAC entity 315 may include individual queues for PDUs of individual flows obtain from a corresponding PDCP entity 310. For example, the MAC entity 315 may include a "default queue" or buffer to store MAC SDUs including PDCP PDUs obtained from the default PDCP entity 310Z, a first queue or buffer to store MAC SDUs including PDCP PDUs obtained from the flowl PDCP entity 31 OA, a second queue or buffer to store MAC SDUs including PDCP PDUs obtained from the flow2 PDCP entity 310B, and a third queue or buffer to store MAC SDUs including PDCP PDUs obtained from the flow3 PDCP entity 3 IOC.

Although not shown by FIG. 3, the protocol stack 300 may also include an RRC entity above the PDCP entities 310. The main functions of the RRC entity may include RRC connection control; Inter-RAT mobility including security activation and transfer of RRC context information; measurement configuration and reporting; transfer of dedicated NAS information and non-LTE dedicated information; transfer of UE radio access capability information; support for E-UTRAN sharing (multiple PLMN identities); generic protocol error handling; support of self-configuration and self-optimization; and support of measurement logging and reporting for network performance optimization. The broadcast of system information may include NAS common information; cell (re-)selection parameters, neighboring cell information and information, and common channel configuration information. RRC connection control may include establishment, modification, and release of RRC connections; initial security activation such as initial configuration of AS integrity protection (SRBs) and AS ciphering (for SRBs and DRBs); establishment, modification, and release of resource blocks (RBs) carrying user data (for example, DRBs); radio configuration control; RN-specific radio configuration control for the radio interface; cell management; QoS control; and recovery from radio link failures (RLFs). In addition to the these functions, in various embodiments the RRC layer may be responsible for configuring the UE 105 and/or the BS 110 for flow-based PDCP aggregation, which may include configuring flow-based PDCP aggregation for a particular DRB 205.

Although not shown by FIG. 3, the protocol stack 300 may also include a NAS layer/entity above the RRC layer/entity. The NAS layer/entity may be the highest stratum of the control plane between UE 105 and an MME at the radio interface. The main functions of the NAS layer may include mobility support for the UE 105; and support of session management procedures to establish and maintain IP connectivity between the UE 105 and a packet data network gateway (PDN GW) within the CN 140. The NAS layer may also provide NAS security services for the NAS protocols, which may include integrity protection and ciphering of NAS signalling messages. In addition to the these functions, in various embodiments the NAS layer may be responsible for configuring the UE 105 and/or the BS 110 for flow-based PDCP aggregation, which may include configuring flow-based PDCP aggregation for a particular DRB 205.

Although not shown by FIG. 3, the protocol stack 300 may also include a Physical layer (PHY) entity below the MAC entity 315. The main functions of the PHY layer may include carrying information from the MAC transport channels over the air interface. The PHY layer may also take care of the link adaptation (AMC), power control, cell search (for initial synchronization and handover purposes) and other measurements (inside the LTE and/or NR systems and between systems) for the RRC layer.

Although not shown by FIG. 3, in embodiments where LWA may be used, the protocol stack 300 may also include an LWAAP entity and a WLAN entity. The LWAAP entity may receive/deliver LWAAP SDUs from/to upper layers (for example, a corresponding PDCP entity 310), and may send/receive LWAAP PDUs to/from its peer LWAAP entity via the WLAN entity. At the BS 110, when an LWAAP entity receives an LWAAP SDU from upper layers, it constructs the corresponding LWAAP PDU and delivers it to lower layers. At the UE 105, when an LWAAP entity receives an LWAAP PDU from lower layers, it reassembles the corresponding LWAAP SDU and delivers it to upper layers. When receiving an LWAAP data PDU from lower layers (for example, downlink data), the LWAAP entity in the UE 105 may identify the upper layer entity to which the LWAAP SDU is destined based on the DRB ID included in the LWAAP header; reassemble the LWAAP SDU from the LWAAP data PDU by removing the LWAAP header from the LWAAP data PDU; and deliver the reassembled LWAAP SDU to the upper layer entity identified by the DRB ID. The WLAN entity may include its own MAC and PHY entities that operate in accordance with WiFi protocols.

Some of the functions listed above may be applicable to both the UE 105 and the BS 110, while some of the functions may only be applicable to only the UE 105 or the BS 110. Further, although FIG. 3 shows a single protocol stack 300, in various embodiments, the UE 105 and/or BSs 110 may generate or create multiple protocol stacks 300 for communicating with one another, wherein each protocol stack 300 may include a corresponding RRC, PDCP, RLC, MAC, PHY, LWAAP, and/or WLAN entities.

In a first example, the UE 105 may generate a first protocol stack 300 with first RRC, first PDCP, first RLC, first MAC, and first PHY entities for communicating with BSs 110 associated with a master cell group (MCG) including one or more MeNBs, and may generate a second protocol stack 300 with second RRC, second PDCP, second RLC, second MAC, and second PHY entities for communicating with BSs 110 associated with a secondary cell group (SCG) including one or more SeNBs. Such embodiments may be applicable to the UE 105 and/or BSs 110 operating in DC mode where one or more BSs 110 may operate as the MeNBs and the one or more other BSs 110 may operate as a SeNBs.

In a second example, the UE 105 and/or BSs 1 10 may generate a first protocol stack 300 with first RRC, first PDCP, first RLC, first MAC, and first PHY entities for communicating in an LTE network and may generate a second protocol stack 300 with second RRC, second PDCP, second RLC, second MAC, and second PHY entities for communicating in an NR network. Such embodiments may be applicable to the UE 105 and/or BSs 110 operating in DC mode where the LTE BS 110 may operate as an MeNB and the NR BS 110 may operate as a secondary gNB (SgNB), or where the LTE BS 110 may operate as an SeNB and the NR BS 110 may operate as a master gNB (MgNB).

In a third example the UE 105 and/or BSs 110 may generate a first protocol stack 300 with first RRC, first PDCP, first RLC, first MAC, and first PHY entities for communicating in an LTE network or an NR network and may generate a second protocol stack 300 with second RRC, second PDCP, second RLC, LWAAP, and WLAN entities for communicating in a WiFi network. Such embodiments may be applicable to the UE 105 and/or BSs 110 operating in LWA mode where the LTE or NR BS 110 may operate as a PCell and the WiFi BS 110 may operate as SCell.

FIG. 4 illustrates an example PDCP PDU 400A and an example PDCP PDU 400B, in accordance with various embodiments. The PDCP PDUs 400A-B may be a bit string that is byte aligned (for example, in multiples of 8 bits) in length. For each of the PDCP PDUs 400A-B and for each field discussed infra, the left most bit may be the first and most significant bit (MSB) and the right most bit may be the last and least significant bit (LSB), unless otherwise mentioned. Additionally, the bits of each field may be ordered and/or populated from MSB to LSB. Furthermore, the fields may include integers that are encoded according to standard binary encoding for unsigned integers.

PDU 400 A may include a flow ID field 405, PDCP SN fields 410A-B, a data field 415, reserved (R) fields 420 A-B, and a D/C field 425. The data field 415 may have a variable length and may include one or more uncompressed PDCP SDUs for user plane data or control plane data; or one or more compressed PDCP SDUs for user plane data only. The data field 415 may be a payload portion of the PDU 400A and may be referred to as a "data payload 415", "PDU payload 415", and the like. The other fields depicted by FIG. 4 may be part of a header portion of the PDU 400A. Each of the R fields 420A-B may be set to 0 and ignored by the receiver entity. The D/C field 425 may be a single bit having a value of 1 to indicate that the PDCP PDU 400A is a data PDU and a value of 0 to indicate that the PDCP PDCU 400 A is a control PDU.

The PDCP SN fields 410A-B may carry an SN. An SN for an SRB may be 5 bits in length, and an SN for DRBs may be 7, 12, 15, 16, or 18 bits in length depending on the configuration by higher layers. The size of the PDCP SN fields 410A-B may be based on an indicated SN size in a PDCP configuration message. For example, the SN size may be indicated by the pdcp-SN-Size field of the PDCP-Config IE in an RRC message. When the SN is 7 bits in length, the SN may be populated in the PDCP SN field 41 OA and the PDCP SN field 410B may be used by the data field 415, for example. When data for a new flow 210 is received by the receiver entity, the receiver entity may create a new flow-specific PDCP entity 310 for the new flow 210, and may start a re-ordering operation for the new flow 210. If the PDCP entity 310 for the flow 210 already exists, normal re-ordering operations may be performed. As the sequence numbering is based on individual flow 210, the data received for the flow 210 may be re-ordered immediately and delivered to an appropriate application. In this way, received data for one flow 210 is not delayed due to missing data from another flow 210.

To support flow-specific PDCP sequence numbering, the PDCP PDU 400A may include the flow ID field 405 as shown in FIG. 4. The flow ID may be used route packets to a flow-based PDCP entity at the receiver entity for separate and/or parallel processing (for example, in-order delivery). In other embodiments, the flow ID field 405 may be included in a payload portion of the PDCP PDU 400A (not shown by FIG. 4). In another embodiment, the flow ID may be part of another protocol layer, which may be received by the PDCP in the payload portion of the PDCP PDU 400A (not shown by FIG. 4). The other protocol layer may be an existing layer (for example, an RRC layer or RLC 305), or may be a new protocol layer introduced on top or below the PDCP layer. Each flow- specific PDCP entity 310 may maintain its own PDCP SN, as well as a split bearer and/or link selection decision in the case of DC or LWA implementations. The flow ID may be used by the receiver entity to identify an individual flow. For example, and with reference to FIG. 2, the flow ID field 405 for flowl 21 OA in DRBl 205 A may have a decimal value of 1 (or a binary value of 00001), the flow ID field 405 for flow2 210B in DRBl 205A may have a decimal value of 2 (or a binary value of 00010), and so forth.

Referring to PDU 400B, the PDU 400B may include the same or similar fields as previously discussed with regard to PDU 400A, except that the PDU 400B does not include a separate flow ID field 405. Instead, the MSB 406A and/or the LSB 406B bits of the existing SN fields 410A-B may be used to indicate the flow ID and the remaining bits may be used to indicate the SN. Although FIG. 4 shows that a single MSB 406A and a single LSB 406B may be used, in other embodiments, any number of MSBs 406A and/or LSBs 406B may be used to convey the flow ID.

In various embodiments, the sending/transmitter entity may mark or otherwise insert a flow ID into the flow ID field 405 of PDU 400 A or the SN fields 410 A-B of PDU 400B. Additionally, the receiver entity may extract or read the flow ID from the flow ID field 405 of PDU 400 A or the SN fields 410A-B of PDU 400B.

As an example, in the DL direction, a BS 110 may obtain data packets (for example, IP packets) from a CN element in the CN 140. The data packets may be included in tunneled packets (for example, General Packet Radio System (GPRS) Tunneling Protocol User Plane (GTP-U) packets). The BS 1 10 may extract or read a tag or other like identifier from a header portion of the tunneled packets and/or the data packets. The tag or other like identifier may be an IP tuple, QoS characteristic/requirement, etc. discussed infra. In embodiments, the BS 1 10 may translate this tag or other like identifier into a flow ID, or may re-use the tag or other like identifier as the flow ID. The BS 110 may map the data packets to a DRB using a DRB ID, and may map the data packets to a flow-based PDCP entity (when activated) or a default PDCP entity (when no flow-based PDCP entity is activated) using the flow ID. The BS 110 may then route the data packets to the corresponding PDCP entity based on the flow ID. Once the data packets are obtained by the corresponding PDCP entity, the corresponding PDCP entity may process individual data packets to produce individual PDCP PDUs 400 A or 400B. Processing the individual data packets may include inserting the flow ID into the flow ID field 405 or the SN field 410A-B. After receipt of the DL transmission by the UE 105, the PDCP PDUs 400A-B may be obtained by a PDCP layer from a lower layer entity (for example, an RLC entity 305) of the UE 105. The PDCP layer of the UE 105 may then identify the flow ID from the flow ID field 405 of PDU 400A or the SN fields 410A-B of PDU 400B to determine a corresponding flow-based PDCP entity to process the packets.

In another example, in the UL direction, the UE 105 may receive data packets (for example, IP packets) from a higher layer entity (for example, a TCP/IP entity). The UE 105 may extract or read a tag or other like identifier (for example, IP tuples, QoS information, etc.) from a header portion of the data packets. In embodiments, the UE 105 may translate this tag or other like identifier into a flow ID, or may re-use the tag or other like identifier as the flow ID. The UE 105 may map the data packets to a DRB using a DRB ID, and may map the data packets to a flow-based PDCP entity (when activated) or a default PDCP entity (when no flow-based PDCP entity is activated) using the flow ID. The UE 105 may then route the data packets to the corresponding PDCP entity based on the flow ID. Once the data packets are obtained by the corresponding PDCP entity, the corresponding PDCP entity may process individual data packets to produce individual PDCP PDUs 400 A or 400B. Processing the individual data packets may include inserting the flow ID into the flow ID field 405 or the SN field 410A-B. After receipt of the UL transmission by the BS 110, the PDCP PDUs 400A-B may be obtained by a PDCP layer from a lower layer entity (for example, an RLC entity 305) of the BS 110. The PDCP layer of the BS 110 may then identify the flow ID from the flow ID field 405 of PDU 400A or the SN fields 410 A-B of PDU 400B to determine a corresponding flow-based PDCP entity to process the packets. In embodiments, the BS 110 may encapsulate the packets in a tunneling protocol packet (for example, a GTP-U packet) and send the tunneling protocol packet to a CN element in the CN 140.

In some embodiments, the flow ID may be based on IP tuples, QoS characteristics/requirements, and/or other like flow parameters indicated by the data packets and/or tunneled packets discussed previously. Since space in the SN fields 410A- B or flow ID field 405 may be limited (for example, as shown by FIG. 4, the flow ID field 405 may be 5 bits in length), in some embodiments an algorithm may be used to generate a flow ID using one or more IP tuples, QoS characteristics, QCI values, etc. as inputs to the algorithm. Additionally or alternatively, in embodiments individual bits in the flow ID field 405 may indicate the IP tuples, QoS characteristics/requirements, etc. Additionally, in some embodiments a special value (for example, "0") may be reserved for the default PDCP entity 310Z of a DRB 205. In embodiments where the flow ID is based on a QoS characteristic or QCI value, the flow ID may be referred to as a "QoS flow ID" and the like.

In embodiments, packets for DL transmission over the Uu interface may be marked in band with a flow ID or QoS flow ID for the purposes of reflective QoS. In embodiments, packets for UL transmission over the Uu interface may be marked in band with a flow ID or QoS flow ID for the purposes of marking packets to be forwarded to the CN 140. In embodiments, the sender/transmitter entity may increment the value in the flow ID field 405 to indicate that the receiver entity should classify and process another flow. Since space in the SN fields 410A-B or flow ID field 405 may be limited, in the event that the sending/transmitter entity runs out of space in the SN fields 410A-B or flow ID field 405, a newly identified flow may be classified to be processed by the default PDCP entity 310Z (as "unclassified") or by an existing flow-specific PDCP that shares the similar QoS characteristics or QCI.

In some embodiments, the use of PDU 400A or PDU 400B may be configured semi-statically by higher layers. For example, a configuration message in an RRC message may indicate whether the flow ID field 405 should be used or not for an individual PDCP entity. This may be used in deployment scenarios where the PDCP PDU may not need to carry flow ID in certain situations, such as when a UE 105 and/or BS 110 is capable of connecting to both a EPC CN 140 and a NG CN 140, or for bearers that are used for signalling setup procedures (for example, SRBs and certain guaranteed bit-rate (GBR) bearers). In an alternative embodiment, where the PDU 400A is used, the flow ID field 405 may be set to a known value when flow IDs should not be used.

In other embodiments, rather than switching between PDU 400A and PDU 400B, the use of flow-based PDCP functionality may be dynamically configured by higher layers. In such embodiments, when flow-based PDCP functionality is configured then PDU 400A or PDU 400B may be used, and when flow-based PDCP functionality is not configured then conventional PDCP PDUs may be used. In one example, dynamic configuration may be used according to a type of CN 140 that the UE 105 is connected with, such as using convention PDUs when connected with an EPC CN or using the PDUs of the example embodiments when connected with an NG CN. In another example, the dynamic configuration may be used on a DRB basis where the particular PDCP functionality to be used may be based the type of traffic carried in a DRB, such as using convention PDUs when the DRB includes a GBR bearer and using PDU 400A or PDU 400B when the DRB includes non-GBR bearers.

FIG. 5 illustrates, for one embodiment, example components of an electronic device 500. In various embodiments, the electronic device 500 may implemented in or by UE 105 and/or a BS 110 as described previously with regard to FIG. 1. In some embodiments, the electronic device 500 may include application circuitry 502, communication circuitry 503 including WLAN circuitry 512 and baseband circuitry 504, radio frequency (RF) circuitry 506, front-end module (FEM) circuitry 508 and one or more antennas 510, coupled together at least as shown. In embodiments where the electronic device 500 is implemented in or by a BS 110, the electronic device 500 may also include network interface circuitry (not shown) for communicating over a wired interface (for example, an X2 interface, an SI interface, and the like).

The application circuitry 502 may include one or more application processors. For example, the application circuitry 502 may include circuitry such as, but not limited to, one or more single-core or multi-core processors 502a. The processor(s) 502a may include any combination of general -purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory/storage 502b (also referred to as "memory 502b" or "computer-readable medium 502b") and may be configured to execute instructions stored in the memory/storage 502b to enable various applications and/or operating systems to run on the system.

The baseband circuitry 504 (also be referred to a "processor circuitry 504" and the like) may include circuitry such as, but not limited to, one or more single-core or multi- core processors. The baseband circuitry 504 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 506 and to generate baseband signals for a transmit signal path of the RF circuitry 506. Baseband circuity 504 may interface with the application circuitry 502 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 506. For example, in some embodiments, the baseband circuitry 504 may include a second generation (2G) baseband processor 504a, third generation (3G) baseband processor 504b, fourth generation (4G) baseband processor 504c, and/or other baseband processor(s) 504d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 504 (e.g., one or more of baseband processors 504a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 506. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, and the like. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 504 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 504 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry 504 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (E-UTRAN) protocol including, for example, PHY, MAC, RLC, PDCP, and/or RRC elements. A central processing unit (CPU) 504e of the baseband circuitry 504 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 504f. The audio DSP(s) 504f may include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. The baseband circuitry 504 may further include memory/storage 504g (also referred to as "memory 504g" or "computer-readable medium 504g"). The memory/storage 504g may be used to load and store data and/or instructions for operations performed by the processors of the baseband circuitry 504. Memory/storage for one embodiment may include any combination of suitable volatile memory and/or non-volatile memory. The memory/storage 504g may include any combination of various levels of memory/storage including, but not limited to, read-only memory (ROM) having embedded software instructions (e.g., firmware), random access memory (e.g., dynamic random access memory (DRAM)), cache, buffers, etc. The memory/storage 504g may be shared among the various processors or dedicated to particular processors. Components of the baseband circuitry 504 may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 504 and the application circuitry 502 may be implemented together, such as, for example, on a system on a chip (SoC).

In some embodiments, the baseband circuitry 504 may be used for communicating over cellular networks and the WLAN circuitry 512 may be used for communicating over WLAN networks. The WLAN circuitry 512 may include processor circuitry 512a and CRM 512b. The processor circuitry 512a may be similar to process circuitry described with respect to other components and CRM 512b may be similar to CRM described with respect to other components.

In some embodiments, the baseband circuitry 504 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 504 may support communication with an E-UTRAN and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 504 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 506 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 506 may include switches, filters, amplifiers, etc., to facilitate the communication with the wireless network. RF circuitry 506 may include a receive signal path that may include circuitry to down-convert RF signals received from the FEM circuitry 508 and provide baseband signals to the baseband circuitry 504. RF circuitry 506 may also include a transmit signal path that may include circuitry to up- convert baseband signals provided by the baseband circuitry 504 and provide RF output signals to the FEM circuitry 508 for transmission.

In some embodiments, the RF circuitry 506 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 506 may include mixer circuitry 506a, amplifier circuitry 506b and filter circuitry 506c. The transmit signal path of the RF circuitry 506 may include filter circuitry 506c and mixer circuitry 506a. RF circuitry 506 may also include synthesizer circuitry 506d for synthesizing a frequency for use by the mixer circuitry 506a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 506a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 508 based on the synthesized frequency provided by synthesizer circuitry 506d. The amplifier circuitry 506b may be configured to amplify the down-converted signals and the filter circuitry 506c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 504 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 506a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 506a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 506d to generate RF output signals for the FEM circuitry 508. The baseband signals may be provided by the baseband circuitry 504 and may be filtered by filter circuitry 506c. The filter circuitry 506c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion, respectively. In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 506 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 504 may include a digital baseband interface to communicate with the RF circuitry 506.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect. In some embodiments, the synthesizer circuitry 506d may be a fractional-N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect, as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 506d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider. The synthesizer circuitry 506d may be configured to synthesize an output frequency for use by the mixer circuitry 506a of the RF circuitry 506 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 506d may be a fractional N/N+l synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 504 or the application circuitry 502 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the application circuitry 502.

Synthesizer circuitry 506d of the RF circuitry 506 may include a divider, a delay- locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 506d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 506 may include an IQ/polar converter. FEM circuitry 508 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 510, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 506 for further processing. FEM circuitry 508 may also include a transmit signal path that may include circuitry configured to amplify signals for transmission provided by the RF circuitry 506 for transmission by one or more of the one or more antennas 510. In some embodiments, the FEM circuitry 508 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry 508 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 506). The transmit signal path of the FEM circuitry 508 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 506), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 510).

In some embodiments, the electronic device 500 may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or interface circuitry (for example, input/output (I/O) interfaces or buses) (not shown). In embodiments where the electronic device is implemented in or by a BS 110, the electronic device may include network interface circuitry. The network interface circuitry may be one or more computer hardware components that connect electronic device 500 to one or more network elements, such as one or more servers within the CN 140 or another BS 110, via a wired connection. To this end, the network interface circuitry may include one or more dedicated processors and/or FPGAs to communicate using one or more wired communications protocol. The wired communications protocols may include a serial communications protocol (e.g., the Universal Serial Bus (USB), FireWire, Serial Digital Interface (SDI), and/or other like serial communications protocols), a parallel communications protocol (e.g., IEEE 1284, Computer Automated Measurement And Control (CAMAC), and/or other like parallel communications protocols), and/or a network communications protocol (e.g., Ethernet, token ring, Fiber Distributed Data Interface (FDDI), and/or other like network communications protocols). The network interface circuitry may also include one or more virtual network interfaces configured to operate with one or more applications.

In some embodiments, the processor circuitry of the electronic device 500 (for example, baseband circuitry 504 and/or processor circuitry 512a) may be to determine that a DRB is to be classified into individual flows of a plurality of flows; instantiate a plurality of PDCP entities, individual PDCP entities of the plurality of PDCP entities to process corresponding flows of the plurality of flows; classify received packets of the DRB into the corresponding flows; and provide, to the individual PDCP entities of the plurality of PDCP entities, the classified packets of the corresponding flows.

In some embodiments, the processor circuitry of the electronic device 500 (for example, baseband circuitry 504 and/or processor circuitry 512a) may determine that a data radio bearer ("DRB") has been established; create a first PDCP entity upon establishment of the DRB. The first PDCP entity may process all packets of the DRB. The processor circuitry of the electronic device 500 may detect activation of a flow classification rule. The flow classification rule may indicate that the DRB is to be classified into individual flows of a plurality of flows. The processor circuitry of the electronic device 500 may create a second PDCP entity to process packets of a flow of the plurality of flows corresponding to the second PDCP entity based on the flow classification rule. Upon creation of the second PDCP entity, the first PDCP entity may cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB. The processor circuitry of the electronic device 500 may classify received packets of the DRB as belonging to the flow corresponding to the second PDCP entity; and may provide, to the second PDCP entity, the classified packets belonging to the flow corresponding to the second PDCP entity.

In some embodiments, the electronic device 500 may be a UE 105 that is to perform the operations/procedures discussed previously. The PDCP entities may be created by components in the baseband circuitry 504, application circuitry 502, or WLAN circuitry 512. In some embodiments, the UE 105 may identify the flow classification rule based on an internal configuration of the UE 105; AS signaling; NAS signaling; or through an application program interface to the application circuitry 502.

In some embodiments, the electronic device 500 may be an eNB/gNB 110 that is to configure a UE 105 with a flow classification rule associated with a first flow; and transmit a plurality of flows of a DRB to the UE 105. The plurality of flows may include the first flow. In some embodiments, the baseband circuitry 504 of the eNB/gNB 110 may configure the UE 105 by transmitting RRC signaling to the UE 105 to configure the UE 105 with the flow classification rule. In some embodiments, the baseband circuitry 504 of the eNB/gNB 110 may transmit the first flow using a first header compression and PDCP encryption process and transmit a second flow of the plurality of flows using a second header compression and PDCP encryption process.

Furthermore, the electronic device 500 may be configured to perform the processes described herein (or parts thereof), such as process 600 described with respect to FIG. 6.

FIG. 6 illustrates an example flow-based PDCP process 600, in accordance with various embodiments. In embodiments, a computer device (for example, electronic device 500 discussed with regard to FIG. 5, which may be implemented in or by the UE 105 or the BS 110 discussed with regard to FIGS. 1-4) may include one or more non-transitory computer-readable media having instructions, stored thereon, that when executed by the computer device, cause the computer device to perform process 600. For illustrative purposes, the operations of process 600 are described as being performed by various elements of a computer device as described with respect to FIGS. 1-5. However, it should be noted that other similar devices/entities may operate process 600. While particular examples and orders of operations are illustrated in FIG. 6, in various embodiments, these operations may be re-ordered, broken into additional operations, combined, and/or omitted altogether. In some embodiments, the operations illustrated in one of FIG. 6 may be combined with operations described with regard to other example embodiments and/or one or more operations described with regard to the non-limiting examples provided herein.

Referring to FIG. 6, at operation 605, processor circuitry of the computer device may identify a PDCP configuration. In embodiments where the computer device is the UE 105, the RF circuitry 506 may receive RF signaling from a BS 110, and the RF circuitry 506 may pass data representative of the RF signaling (for example, a configuration message) to processor circuitry of the UE 105 via interface circuitry of the UE 105. In such embodiments, the RF signaling may include an RRC signaling message or NAS signaling message.

In embodiments where the computer device is the BS 110, network interface circuitry (NIC) of the BS 110 may receive a configuration message from a CN element within the CN 140 (for example, an MME, PGW, etc.), and the NIC may pass the configuration message to processor circuitry of the BS 110. In such embodiments, the configuration message may be included in a NAS signaling message, an Sl-AP message, or some other like message. In other embodiments where the computer device is the BS 110, the processor circuitry of the BS 110 may generate the configuration message based on information obtained from a CN element, and the NIC may pass the configuration message to processor circuitry of the BS 110, which may be obtained from an Sl-AP message.

At operation 610, the processor circuitry of the computer device may determine that a DRB is to be classified into individual flows. In embodiments, the PDCP configuration obtained at operation 605 may identify one or more DRBs (for example, using DRB IDs) and may indicate whether any of the identified DRBs are configured for flow-based PDCP functionality. As an example, and with reference to FIG. 2, the PDCP configuration may indicate that DRB1 205 A is to be classified into individual flows. In some embodiments, the PDCP configuration may indicate whether any PDCP PDUs should be sent via a secondary cell group (SCG), a master cell group (MCG), or split between the SCG and MCG in the UL or DL direction. This configuration may be used by a default PDCP entity 310Z to perform various PDCP functions. In addition, the PDCP configuration may include a routing rule for an individual flow, where the routing rule may indicate whether PDCP PDUs should be sent via the SCG over a dedicated link 120, the MCG over a dedicated link 120, or split between the SCG and MCG in the UL or DL direction.

At operation 615, the processor circuitry of the computer device may create a default PDCP entity 310Z, and at operation 620 the processor circuitry of the computer device may operate the default PDCP entity 310Z to process all received packets associated with the identified DRB. In various embodiments, to perform operations 615- 620, the processor circuitry may generate a new protocol stack 300 including a new PDCP entity 310Z, a new RLC entity 305, and a new MAC entity 315. In other embodiments, the processor circuitry may maintain and continue operating an already existing protocol stack 300.

At operation 625, the processor circuitry of the computer device may detect activation of a flow classification rule. As an example, and with reference to FIG. 2, the flow classification rule may indicate that flowl 21 OA of DRB 1 205 A should be classified as an individual flow. The flow classification rule may indicate various parameters for identifying and/or labeling packets belonging to an individual flow, and various parameters for processing packets of an individual flow as discussed previously.

In embodiments where the computer device is the UE 105, the flow classification rule(s) may be activated by the UE 105. This may be referred to as "local activation" of the flow classification rules. In such embodiments, the processor circuitry of the UE 105 may generate a DL flow classification rule indicating how to map packets of flowl 21 OA for DL packets and may generate a UL flow classification rule indicating how to map packets of flowl 210A for UL packets. Additionally, the communication circuitry of the UE 105 may control transmission of the DL flow classification rule to the BS 110 and/or a CN 140 element (for example, an MME, PGW, etc.) using, for example, higher layer signaling.

In embodiments where the computer device is the BS 110, the flow classification rule(s) may be activated by the BS 110. This may be referred to as "network-based activation" of the flow classification rules. In such embodiments, the processor circuitry of the BS 110 may generate a DL flow classification rule indicating how to map packets of flowl 21 OA for DL packets and may generate a UL flow classification rule indicating how to map packets of flowl 21 OA for UL packets. Additionally, the communication circuitry of the BS 110 may control transmission of the DL flow classification rule to the UE 105 using higher layer signaling (for example, RRC or NAS signaling) or using explicit signaling of a PDCP control packet that indicates the flow UL and/or DL classification rules to the UE 105. In some embodiments the NIC of the BS 110 may send the DL and/or UL flow classification rules to a CN 140 element (for example, an MME, PGW, etc.) and/or another BS 110 using backhaul links 125, 130. In embodiments where the CN 140 element (for example, an MME, PGW, etc.) determines the flow classification rule, the computer device is a CN 140 element (for example, an MME, PGW, etc.), processor circuitry of the CN element may generate and send the UL and DL flow classification rules to the BS 110, which may in turn provide the DL flow classification rule to the UE 105.

In other embodiments, the UL and DL flow classification rules may be activated by the UE 105 and the BS 110 or CN 140 element independently. This may be referred to as "independent activation" of the flow classification rules since each device may locally activate their own flow activation rules independent of one another. In such embodiments, the processor circuitry of the UE 105 may determine how to map packets of flowl 21 OA for UL transmissions, and the BS 110 or CN 140 element may determine how to map packets of flowl 21 OA for DL transmissions. In such embodiments, the flow classification rules may not be signaled OTA. In embodiments where the CN 140 element determines the flow classification rules, the CN 140 element may provide the DL flow classification rule to the BS 110.

Referring back to FIG. 6, at operation 630, the processor circuitry of the computer device may generate or create a flowX PDCP entity, where X is a number that is representative of a flow ID. In an example, X may be equal to 1 when the flow classification rule indicates that flowl 21 OA of DRB1 205 A is to be classified as an individual flow. In this example, at operation 630, the processor circuitry may generate the flowl PDCP entity 31 OA as shown by FIG. 3.

At operation 635 the processor circuitry of the computer device may classify received packets of the DRB (for example, DRB1 205 A of FIG. 2) as belonging to flowX (for example, flowl 21 OA of FIG. 2) or other flows. At operation 640, the processor circuitry of the computer device may provide classified packets belonging to flowX (for example, flowl 21 OA of FIG. 2) to the flowX PDCP entity (for example, flowl PDCP entity 31 OA of FIG. 3). At operation 645, the processor circuitry of the computer device may operate the to the flowX PDCP entity (for example, flowl PDCP entity 31 OA of FIG. 3) to process packets of flowX (for example, packets of flowl 210A of FIG. 2) and may operate the default PDCP entity 310Z to process all other received packets that do not belong to flowX.

At operation 650, the processor circuitry of the computer device may determine whether another flow classification rule has been activated. Operation 650 may be performed in a same or similar manner as discussed previously with regard to operation 625. If at operation 650 the processor circuitry determines that another flow classification rule has been activated, then the processor circuitry may proceed back to perform operations 630-645 as discussed previously for another identified flow (for example, flow2 210B of FIG. 2). If at operation 650 the processor circuitry determines that another flow classification rule has not been activated, then the processor circuitry may proceed to operation 655 to determine whether any more packet for flowX have been received or should be received.

If at operation 655 the processor circuitry determines that more packet for flowX have been received or should be received, then the processor circuitry may proceed back to perform operations 645-650 as discussed previously. If at operation 655 the processor circuitry determines that no more packet for flowX have been received or that packets for flowX will not be received, then the processor circuitry may proceed to operation 660 to terminate or pause the flowX PDCP entity. In embodiments, to perform operation 660, the processor circuitry may determine whether the EPS session, which resulted in the DRB being established, has ended. In embodiments, operation 660 may be based on expiration of a timer, or based on receipt of an indication from higher level layers. After completion of operation 660, process 600 may end or repeat as necessary. Some non-limiting examples are provided below.

Example 1 may include one or more computer-readable media including instructions, which when executed by one or more processors, causes a computer device to: determine that a data radio bearer ("DRB") is to be classified into individual flows of a plurality of flows; instantiate a plurality of packet data convergence protocol ("PDCP") entities, individual PDCP entities of the plurality of PDCP entities to process corresponding flows of the plurality of flows; classify obtained packets of the DRB into the corresponding flows; and provide, to the individual PDCP entities of the plurality of PDCP entities, the classified packets of the corresponding flows.

Example 2 may include the computer-readable media of example 1 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the computer device, in response to execution of the instructions, is to: identify the obtained packets of the corresponding flows according to one or more internet protocol ("IP") tuples, a combination of two or more IP tuples, one or more Quality of Service ("QoS") characteristics, or a flow identifier ("ID") marking in the classified packets.

Example 3 may include the computer-readable media of example 2 and/or some other examples herein, wherein: when identification of the obtained packets is according to one or more IP tuples or a combination of two or more IP tuples, the IP tuples comprise a source IP address, a source port, a destination IP address, a destination port, and a protocol type, when identification of the obtained packets is according to one or more QoS characteristics, the QoS characteristics comprise a QoS class ID ("QCI"), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level, and when identification of the obtained packets is according to the flow ID marking, wherein the flow ID is a value in a header portion of the obtained packets.

Example 4 may include the computer-readable media of examples 1-3 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the computer device, in response to execution of the instructions, is to: determine, based on a flow ID within individual packets of the obtained packets, an individual PDCP entity of the plurality of PDCP entities to which the obtained packets belong.

Example 5 may include the computer-readable media of example 4 and/or some other examples herein, wherein, to identify a flow ID within individual packets of the obtained packets, the computer device, in response to execution of the instructions, is to: extract a first flow ID from one of one or more most significant bits of a sequence number ("SN") field of a PDCP protocol data unit ("PDU") of a first packet of the obtained packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, a value in a flow ID field in a header portion of the PDCP PDU of the first packet, or a value in a flow ID field in a payload portion of the PDCP PDU of the first packet.

Example 6 may include the computer-readable media of example 1 and/or some other examples herein, wherein the computer device, in response to execution of the instructions, is to: operate the individual PDCP entities to insert a flow ID into the obtained packets when the flow ID is not present within individual packets of the obtained packets.

Example 7 may include the computer-readable media of any one of examples 1-6 and/or some other examples herein, wherein, to instantiate the plurality of PDCP entities, the computer device, in response to execution of the instructions, is to: create a first PDCP entity upon establishment of the DRB, wherein the first PDCP entity is to process all packets of the DRB; detect activation of a flow classification rule; and create a second PDCP entity to process packets of a flow corresponding to the second PDCP entity based on the flow classification rule, wherein upon activation of the flow classification rule, the first PDCP entity is to cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB.

Example 8 may include the computer-readable media of example 7 and/or some other examples herein, wherein the computer device, in response to execution of the instructions, is further to: upon establishment of the DRB, implement the first PDCP entity to cipher or decipher all packets of the DRB using a bearer ID of the DRB or the identified flow ID; and upon creation of the second PDCP entity, implement the second PDCP entity to cipher or decipher the flow corresponding to the second PDCP entity using at least the bearer ID of the DRB or a flow ID of the flow corresponding to the second PDCP entity.

Example 9 may include one or more computer-readable media including instructions, which when executed by one or more processors, causes a computer device to: determine that a data radio bearer ("DRB") has been established; create a first packet data convergence protocol ("PDCP") entity upon establishment of the DRB, wherein the first PDCP entity is to process all packets of the DRB; detect activation of a flow classification rule, wherein the flow classification rule is to indicate that the DRB is to be classified into individual flows of a plurality of flows; create a second PDCP entity to process packets of a flow of the plurality of flows corresponding to the second PDCP entity based on the flow classification rule, wherein upon creation of the second PDCP entity, the first PDCP entity is to cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB; classify obtained packets of the DRB as belonging to the flow corresponding to the second PDCP entity; and provide, to the second PDCP entity, the classified packets belonging to the flow corresponding to the second PDCP entity.

Example 10 may include the computer-readable media of example 9 and/or some other examples herein, wherein, to detect activation of a flow classification rule, the computer device, in response to execution of the instructions, is to: identify the flow classification rule based on an internal configuration of the computer device, information included in access stratum signaling, information included in non-access stratum ("NAS") signaling, or information obtained from an application of the computer device via an application programing interface.

Example 11 may include the computer-readable media of examples 9-10 and/or some other examples herein, wherein, to detect activation of the flow classification rule, the computer device, in response to execution of the instructions, is to: detect a local activation of the flow classification rule, wherein, to detect the local activation of the flow classification rule, the computer device, in response to execution of the instructions, is to: determine a downlink ("DL") flow classification rule to map a downlink flow; determine an uplink ("UL") flow classification rule to map an uplink flow; and control transmission of the DL flow classification rule or the UL flow classification rule to another computer device.

Example 12 may include the computer-readable media of examples 9-10 and/or some other examples herein, wherein, to detect activation of the flow classification rule, the computer device, in response to execution of the instructions, is to: identify an indication of the flow classification rule based on an obtained message, wherein, to identify the indication of the flow classification rule, the computer device, in response to execution of the instructions, is to: control receipt of one or more signals, wherein the one or more signals comprise radio resource control ("RRC") signaling or NAS signaling; and identify a DL flow classification rule to map a DL flow or a UL flow classification rule to map a UL flow.

Example 13 may include the computer-readable media of examples 9-10 and/or some other examples herein, wherein the computer device, in response to execution of the instructions, is to: select one or more links for each of the corresponding flows based on a routing rule associated with each of the corresponding flows; and control transmission of a message to indicate the selected one or more links and a flow identifier for each of the corresponding flows, wherein the message is an RRC message or a NAS message.

Example 14 may include the computer-readable media of example 13, wherein the routing rule is based on a QoS characteristic.

Example 15 may include the computer-readable media of examples 9-10 and/or some other examples herein, wherein the computer device, in response to execution of the instructions, is to: determine a first link over which a first flow of the plurality of flows is to be received and a second link over which a second flow of the plurality of flows is to be received; obtain packets of the first flow from first communication circuitry used to communicate over the first link; and obtain packets of the second flow from second communication circuitry used to communicate over the second link, wherein the first link is different than the second link.

Example 16 may include an apparatus to be implemented by base station ("BS"), the apparatus comprising: communication circuitry to: transmit a configuration message to establish a data radio bearer ("DRB"), and transmit and receive packets of the DRB after the DRB is established; and processor circuitry coupled with the communication circuitry, the processor circuitry to: instantiate one or more of packet data convergence protocol ("PDCP") entities in response to establishment of the DRB, wherein individual PDCP entities of the one or more of PDCP entities are to process corresponding flows of the one or more of flows; classify obtained packets of the DRB into the one or more flows; provide, to the individual PDCP entities of the one or more of PDCP entities, the classified packets of the corresponding flows; and operate the individual PDCP entities to re-order the classified packets according to information included in the classified packets.

Example 17 may include the apparatus of example 16 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the processor circuitry is to: identify the obtained packets of the corresponding flows according to one or more internet protocol ("IP") tuples or a combination of two or more IP tuples, wherein the IP tuples comprise a source IP address, a source port, a destination IP address, a destination port, and a protocol type; determine a flow identifier ("ID") for the obtained packets; and insert the flow ID into one of one or more most significant bits of a sequence number ("SN") field of a PDCP protocol data unit ("PDU") of a first packet of the received packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, or a value in a flow identifier field of the PDCP PDU or a PDCP body of the first packet. Example 18 may include the apparatus of example 16 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the processor circuitry is to: identify the obtained packets of the corresponding flows according to one or more Quality of Service ("QoS") characteristics, wherein the QoS characteristics comprise a QoS class identifier ("QCI"), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level; determine a flow ID for the obtained packets; and insert the flow ID into one of one or more most significant bits of an SN field of a PDCP PDU of a first packet of the received packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, or a value in a flow identifier field of the PDCP PDU or a PDCP body of the first packet.

Example 19 may include the apparatus of example 16 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the processor circuitry is to: identify a flow ID within individual packets of the obtained packets.

Example 20 may include the apparatus of examples 16-19 and/or some other examples herein, wherein, to instantiate the plurality of PDCP entities, the processor circuitry is to: create a default PDCP entity upon establishment of the DRB, wherein the default PDCP entity is to process all packets of the DRB; detect activation of a flow classification rule; and create a first flow PDCP entity to process packets of a first flow based on the flow classification rule, wherein upon creation of the first flow PDCP entity, the default PDCP entity is to cease processing the packets of the first flow and continue processing all other packets of the DRB.

Example 21 may include the apparatus of example 20 and/or some other examples herein, wherein the processor circuitry is to: upon establishment of the DRB, implement the first PDCP entity to cipher or decipher all packets of the DRB using a bearer identifier of the DRB or the identified flow identifier; and upon creation of the second PDCP entity, implement the second PDCP entity to cipher or decipher the flow corresponding to the second PDCP entity using at least the bearer identifier of the DRB or a flow identifier of the flow corresponding to the second PDCP entity.

Example 22 may include an apparatus to be implemented in a user equipment ("UE"), the apparatus comprising: communication circuitry to receive a configuration message to establish a data radio bearer ("DRB"), and receive packets of the DRB after the DRB is established; and processor circuitry coupled with the communication circuitry, the processor circuitry to: determine, based on information in the configuration message, that the DRB is to be classified into individual flows of a one or more of flows; create a default packet data convergence protocol ("PDCP") entity upon establishment of the DRB, wherein the default PDCP entity is to process all packets of the DRB; detect activation of a flow classification rule, wherein the flow classification rule is to indicate that the DRB is to be classified into individual flows of a plurality of flows; create a first flow PDCP entity to process packets of a first flow of the plurality of flows based on the flow classification rule, wherein upon creation of the first flow PDCP entity, the default PDCP entity is to cease processing the packets of the first flow and continue processing all other packets of the DRB; classify obtained packets of the DRB as belonging to the first flow or belonging to other flows of the plurality of flows; and provide the classified packets belonging to the first flow to the first flow PDCP entity and the classified packets belonging to the other flows to the default PDCP entity.

Example 23 may include the apparatus of example 22 and/or some other examples herein, wherein, to detect activation of the flow classification rule, the processor circuitry is to: detect a local activation of the flow classification rule, and wherein, to detect the local activation of the flow classification rule, the processor circuitry is to: determine a downlink ("DL") flow classification rule to map a downlink flow; or determine an uplink ("UL") flow classification rule to map an uplink flow.

Example 24 may include the apparatus of example 22 and/or some other examples herein, wherein the flow classification rule is a first flow classification rule that corresponds with the first flow, and wherein the processor circuitry is to: detect activation of a second flow classification rule corresponding to a second flow of the plurality of flows; create a second flow PDCP entity to process packets of the second flow based on the second flow classification rule, wherein upon creation of the second flow PDCP entity, the default PDCP entity is to cease processing the packets of the second flow and continue processing all other packets of the DRB that do not belong to the first flow or the second flow; classify packets of the DRB received after creation of the second flow PDCP entity as belonging to the first flow, belonging to the second flow, or belonging to the other flows of the plurality of flows; provide the classified packets belonging to the first flow to the first flow PDCP entity; provide the classified packets belonging to the second flow to the second flow PDCP entity; and provide the classified packets belonging to the other flows to the default PDCP entity.

Example 25 may include the apparatus of examples 22-24 and/or some other examples herein, wherein the communication circuitry comprises first communication circuitry and second communication circuitry, and the processor circuitry is to: identify a first link over which a first flow of the plurality of flows is to be received and a second link over which a second flow of the plurality of flows is to be received, wherein the first link is provided by a first BS and the second link is provided by a second BS, and wherein the identification is based on an indication in the configuration message or an indication in a received RRC message or a received NAS message; obtain packets of the first flow from the first communication circuitry used to communicate with the first BS over the first link; and obtain packets of the second flow from second communication circuitry used to communicate with the second BS over the second link, wherein the first flow is a different flow than the second flow, and the first link is different than the second link, wherein the first communication circuitry is cellular modem circuitry and the second communication circuitry is wireless local area network modem circuitry.

Example 26 may include an apparatus comprising: means for determining that a data radio bearer ("DRB") is to be classified into individual flows of a plurality of flows; means for instantiating a plurality of packet data convergence protocol ("PDCP") entities, individual PDCP entities of the plurality of PDCP entities to process corresponding flows of the plurality of flows; means for classifying obtained packets of the DRB into the corresponding flows; and means for providing, to the individual PDCP entities of the plurality of PDCP entities, the classified packets of the corresponding flows.

Example 27 may include the apparatus of example 26 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the apparatus comprises: means for identifying the obtained packets of the corresponding flows according to one or more internet protocol ("IP") tuples, a combination of two or more IP tuples, one or more Quality of Service ("QoS") characteristics, or a flow identifier ("ID") marking in the classified packets.

Example 28 may include the apparatus of example 27 and/or some other examples herein, wherein: when identification of the obtained packets is according to one or more IP tuples or a combination of two or more IP tuples, the IP tuples comprise a source IP address, a source port, a destination IP address, a destination port, and a protocol type, when identification of the obtained packets is according to one or more QoS characteristics, the QoS characteristics comprise a QoS class ID ("QCI"), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level, and when identification of the obtained packets is according to the flow ID marking, wherein the flow ID is a value in a header portion of the obtained packets. Example 29 may include the apparatus of examples 26-28 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the apparatus comprises: means for determining, based on a flow ID within individual packets of the obtained packets, an individual PDCP entity of the plurality of PDCP entities to which the obtained packets belong.

Example 30 may include the apparatus of example 29 and/or some other examples herein, wherein, to identify a flow ID within individual packets of the obtained packets, the apparatus comprises: means for extracting a first flow ID from one of one or more most significant bits of a sequence number ("SN") field of a PDCP protocol data unit ("PDU") of a first packet of the obtained packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, a value in a flow ID field in a header portion of the PDCP PDU of the first packet, or a value in a flow ID field in a payload portion of the PDCP PDU of the first packet.

Example 31 may include the apparatus of example 26 and/or some other examples herein, further comprising: means for operating the individual PDCP entities to insert a flow ID into the obtained packets when the flow ID is not present within individual packets of the obtained packets.

Example 32 may include the apparatus of examples 26-31 and/or some other examples herein, wherein, to instantiate the plurality of PDCP entities, the apparatus comprises: means for creating a first PDCP entity upon establishment of the DRB, wherein the first PDCP entity is to process all packets of the DRB; means for detecting activation of a flow classification rule; and means for creating a second PDCP entity to process packets of a flow corresponding to the second PDCP entity based on the flow classification rule, wherein upon activation of the flow classification rule, the first PDCP entity is to cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB.

Example 33 may include the apparatus of example 32 and/or some other examples herein, further comprising: means for implementing, upon establishment of the DRB, the first PDCP entity to cipher or decipher all packets of the DRB using a bearer ID of the DRB or the identified flow ID; and means for implement, upon creation of the second PDCP entity, the second PDCP entity to cipher or decipher the flow corresponding to the second PDCP entity using at least the bearer ID of the DRB or a flow ID of the flow corresponding to the second PDCP entity. Example 34 may include an apparatus comprising: means for determining that a data radio bearer ("DRB") has been established; create a first packet data convergence protocol ("PDCP") entity upon establishment of the DRB, wherein the first PDCP entity is to process all packets of the DRB; means for detecting activation of a flow classification rule, wherein the flow classification rule is to indicate that the DRB is to be classified into individual flows of a plurality of flows; means for creating a second PDCP entity to process packets of a flow of the plurality of flows corresponding to the second PDCP entity based on the flow classification rule, wherein upon creation of the second PDCP entity, the first PDCP entity is to cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB; means for classifying obtained packets of the DRB as belonging to the flow corresponding to the second PDCP entity; and means for providing, to the second PDCP entity, the classified packets belonging to the flow corresponding to the second PDCP entity.

Example 35 may include the apparatus of example 34 and/or some other examples herein, wherein, to detect activation of a flow classification rule, the apparatus comprises: means for identifying the flow classification rule based on an internal configuration of the computer device, information included in access stratum signaling, information included in non-access stratum ("NAS") signaling, or information obtained from an application of the computer device via an application programing interface.

Example 36 may include the apparatus of examples 34-35 and/or some other examples herein, wherein, to detect activation of the flow classification rule, the apparatus comprises: means for detecting a local activation of the flow classification rule; means for determining a downlink ("DL") flow classification rule to map a downlink flow; means for determining an uplink ("UL") flow classification rule to map an uplink flow; and means for transmitting the DL flow classification rule or the UL flow classification rule to another computer device.

Example 37 may include the apparatus of examples 34-35 and/or some other examples herein, wherein, to detect activation of the flow classification rule, the apparatus comprises: means for identifying an indication of the flow classification rule based on an obtained message; means for receiving of one or more signals, wherein the one or more signals comprise radio resource control ("RRC") signaling or NAS signaling; and means for identifying a DL flow classification rule to map a DL flow or a UL flow classification rule to map a UL flow. Example 38 may include the apparatus of examples 34-35 and/or some other examples herein, wherein the apparatus comprises: means for selecting one or more links for each of the corresponding flows based on a routing rule associated with each of the corresponding flows; and means for transmitting a message to indicate the selected one or more links and a flow identifier for each of the corresponding flows, wherein the message is an RRC message or a NAS message.

Example 39 may include the apparatus of example 38 and/or some other examples herein, wherein the routing rule is based on a QoS characteristic.

Example 40 may include the apparatus of examples 34-35 and/or some other examples herein, further comprising: means for determining a first link over which a first flow of the plurality of flows is to be received and a second link over which a second flow of the plurality of flows is to be received; means for obtaining packets of the first flow from first communication circuitry used to communicate over the first link; and means for obtaining packets of the second flow from second communication circuitry used to communicate over the second link, wherein the first link is different than the second link.

Example 41 may include an apparatus to be implemented by base station ("BS"), the apparatus comprising: communication means for transmitting a configuration message to establish a data radio bearer ("DRB"), and transmitting and receive packets of the DRB after the DRB is established; and processor means for: instantiating one or more of packet data convergence protocol ("PDCP") entities in response to establishment of the DRB, wherein individual PDCP entities of the one or more of PDCP entities are to process corresponding flows of the one or more of flows; classifying obtained packets of the DRB into the one or more flows; providing, to the individual PDCP entities of the one or more of PDCP entities, the classified packets of the corresponding flows; and operating the individual PDCP entities to re-order the classified packets according to information included in the classified packets.

Example 42 may include the apparatus of example 41 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the processor means is for: identifying the obtained packets of the corresponding flows according to one or more internet protocol ("IP") tuples or a combination of two or more IP tuples, wherein the IP tuples comprise a source IP address, a source port, a destination IP address, a destination port, and a protocol type; determining a flow identifier ("ID") for the obtained packets; and inserting the flow ID into one of one or more most significant bits of a sequence number ("SN") field of a PDCP protocol data unit ("PDU") of a first packet of the received packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, or a value in a flow identifier field of the PDCP PDU or a PDCP body of the first packet.

Example 43 may include the apparatus of example 41 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the processor means is for: identifying the obtained packets of the corresponding flows according to one or more Quality of Service ("QoS") characteristics, wherein the QoS characteristics comprise a QoS class identifier ("QCI"), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level; determining a flow ID for the obtained packets; and inserting the flow ID into one of one or more most significant bits of an SN field of a PDCP PDU of a first packet of the received packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, or a value in a flow identifier field of the PDCP PDU or a PDCP body of the first packet.

Example 44 may include the apparatus of example 41 and/or some other examples herein, wherein, to classify the obtained packets of the DRB, the processor means is for: identifying a flow ID within individual packets of the obtained packets.

Example 45 may include the apparatus of examples 41-44 and/or some other examples herein, wherein, to instantiate the plurality of PDCP entities, the processor means is for: creating a default PDCP entity upon establishment of the DRB, wherein the default PDCP entity is to process all packets of the DRB; detecting activation of a flow classification rule; and creating a first flow PDCP entity to process packets of a first flow based on the flow classification rule, and wherein upon creation of the first flow PDCP entity, the default PDCP entity is to cease processing the packets of the first flow and continue processing all other packets of the DRB.

Example 46 may include the apparatus of example 45 and/or some other examples herein, wherein the processor means is for: implementing, upon establishment of the DRB, the first PDCP entity to cipher or decipher all packets of the DRB using a bearer identifier of the DRB or the identified flow identifier; and implementing, upon creation of the second PDCP entity, the second PDCP entity to cipher or decipher the flow corresponding to the second PDCP entity using at least the bearer identifier of the DRB or a flow identifier of the flow corresponding to the second PDCP entity.

Example 47 may include an apparatus to be implemented in a user equipment ("UE"), the apparatus comprising: means for receiving a configuration message to establish a data radio bearer ("DRB"); means for determining, based on information in the configuration message, that the DRB is to be classified into individual flows of a one or more of flows; means for creating a default packet data convergence protocol ("PDCP") entity upon establishment of the DRB, wherein the default PDCP entity is to process all packets of the DRB; means for receiving packets of the DRB after the DRB is established; means for detecting activation of a flow classification rule, wherein the flow classification rule is to indicate that the DRB is to be classified into individual flows of a plurality of flows; means for creating a first flow PDCP entity to process packets of a first flow of the plurality of flows based on the flow classification rule, wherein upon creation of the first flow PDCP entity, the default PDCP entity is to cease processing the packets of the first flow and continue processing all other packets of the DRB; means for classifying obtained packets of the DRB as belonging to the first flow or belonging to other flows of the plurality of flows; and means for providing the classified packets belonging to the first flow to the first flow PDCP entity and the classified packets belonging to the other flows to the default PDCP entity.

Example 48 may include the apparatus of example 47 and/or some other examples herein, wherein the means for detecting the activation of the flow classification rule is for: detecting a local activation of the flow classification rule, and wherein, to detect the local activation of the flow classification rule, the processor circuitry is to: determining a downlink ("DL") flow classification rule to map a downlink flow; or determining an uplink ("UL") flow classification rule to map an uplink flow.

Example 49 may include the apparatus of example 47 and/or some other examples herein, wherein the flow classification rule is a first flow classification rule that corresponds with the first flow, and wherein the apparatus comprises: means for detecting activation of a second flow classification rule corresponding to a second flow of the plurality of flows; means for creating a second flow PDCP entity to process packets of the second flow based on the second flow classification rule, wherein upon creation of the second flow PDCP entity, the default PDCP entity is to cease processing the packets of the second flow and continue processing all other packets of the DRB that do not belong to the first flow or the second flow; means for classifying packets of the DRB received after creation of the second flow PDCP entity as belonging to the first flow, belonging to the second flow, or belonging to the other flows of the plurality of flows; means for providing the classified packets belonging to the first flow to the first flow PDCP entity; means for providing the classified packets belonging to the second flow to the second flow PDCP entity; and means for providing the classified packets belonging to the other flows to the default PDCP entity.

Example 50 may include the apparatus of examples 47-49 and/or some other examples herein, further comprising: means for identifying a first link over which a first flow of the plurality of flows is to be received and a second link over which a second flow of the plurality of flows is to be received, wherein the first link is provided by a first BS and the second link is provided by a second BS, and wherein the identification is based on an indication in the configuration message or an indication in a received RRC message or a received NAS message; means for obtaining packets of the first flow from the first communication circuitry used to communicate with the first BS over the first link; and means for obtaining packets of the second flow from second communication circuitry used to communicate with the second BS over the second link, wherein the first flow is a different flow than the second flow, and the first link is different than the second link.

Example 51 may include a method comprising: determining that a data radio bearer ("DRB") is to be classified into individual flows of a plurality of flows; instantiating a plurality of packet data convergence protocol ("PDCP") entities, individual PDCP entities of the plurality of PDCP entities to process corresponding flows of the plurality of flows; classifying obtained packets of the DRB into the corresponding flows; and providing, to the individual PDCP entities of the plurality of PDCP entities, the classified packets of the corresponding flows.

Example 52 may include the method of example 51 and/or some other examples herein, wherein classifying the obtained packets of the DRB comprises: identifying the obtained packets of the corresponding flows according to one or more internet protocol ("IP") tuples, a combination of two or more IP tuples, one or more Quality of Service ("QoS") characteristics, or a flow identifier ("ID") marking in the classified packets.

Example 53 may include the method of example 52 and/or some other examples herein, wherein: when identification of the obtained packets is according to one or more IP tuples or a combination of two or more IP tuples, the IP tuples comprise a source IP address, a source port, a destination IP address, a destination port, and a protocol type, when identification of the obtained packets is according to one or more QoS characteristics, the QoS characteristics comprise a QoS class ID ("QCI"), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level, and when identification of the obtained packets is according to the flow ID marking, wherein the flow ID is a value in a header portion of the obtained packets. Example 54 may include the method of examples 51-53 and/or some other examples herein, wherein classifying the obtained packets of the DRB comprises: determining, based on a flow ID within individual packets of the obtained packets, an individual PDCP entity of the plurality of PDCP entities to which the obtained packets belong.

Example 55 may include the method of example 54 and/or some other examples herein, wherein identifying a flow ID within individual packets of the obtained packets comprises: extracting a first flow ID from one of one or more most significant bits of a sequence number ("SN") field of a PDCP protocol data unit ("PDU") of a first packet of the obtained packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, a value in a flow ID field in a header portion of the PDCP PDU of the first packet, or a value in a flow ID field in a payload portion of the PDCP PDU of the first packet.

Example 56 may include the method of example 51 and/or some other examples herein, further comprising: operating the individual PDCP entities to insert a flow ID into the obtained packets when the flow ID is not present within individual packets of the obtained packets.

Example 57 may include the method of examples 51-56 and/or some other examples herein, wherein instantiating the plurality of PDCP entities comprises: creating a first PDCP entity upon establishment of the DRB, wherein the first PDCP entity is to process all packets of the DRB; detecting activation of a flow classification rule; and creating a second PDCP entity to process packets of a flow corresponding to the second PDCP entity based on the flow classification rule, and wherein upon activation of the flow classification rule, the first PDCP entity is to cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB.

Example 58 may include the method of example 57 and/or some other examples herein, further comprising: implementing, upon establishment of the DRB, the first PDCP entity to cipher or decipher all packets of the DRB using a bearer ID of the DRB or the identified flow ID; and implement, upon creation of the second PDCP entity, the second PDCP entity to cipher or decipher the flow corresponding to the second PDCP entity using at least the bearer ID of the DRB or a flow ID of the flow corresponding to the second PDCP entity. Example 59 may include a method comprising: determining that a data radio bearer ("DRB") has been established; create a first packet data convergence protocol ("PDCP") entity upon establishment of the DRB, wherein the first PDCP entity is to process all packets of the DRB; detecting activation of a flow classification rule, wherein the flow classification rule is to indicate that the DRB is to be classified into individual flows of a plurality of flows; creating a second PDCP entity to process packets of a flow of the plurality of flows corresponding to the second PDCP entity based on the flow classification rule, wherein upon creation of the second PDCP entity, the first PDCP entity is to cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB; classifying obtained packets of the DRB as belonging to the flow corresponding to the second PDCP entity; and providing, to the second PDCP entity, the classified packets belonging to the flow corresponding to the second PDCP entity.

Example 60 may include the method of example 59 and/or some other examples herein, wherein detecting activation of a flow classification rule comprises: means for identifying the flow classification rule based on an internal configuration of the computer device, information included in access stratum signaling, information included in non- access stratum ("NAS") signaling, or information obtained from an application of the computer device via an application programing interface.

Example 61 may include the method of examples 59-60 and/or some other examples herein, wherein detecting activation of a flow classification rule comprises: detecting a local activation of the flow classification rule, wherein detecting the local activation of the flow classification rule comprises: determining a downlink ("DL") flow classification rule to map a downlink flow; determining an uplink ("UL") flow classification rule to map an uplink flow; and transmitting the DL flow classification rule or the UL flow classification rule to another computer device.

Example 62 may include the method of examples 59-60 and/or some other examples herein, wherein detecting activation of a flow classification rule comprises: identifying an indication of the flow classification rule based on an obtained message, wherein identifying the indication of the flow classification rule comprises: receiving of one or more signals, wherein the one or more signals comprise radio resource control ("RRC") signaling or NAS signaling; and identifying a DL flow classification rule to map a DL flow or a UL flow classification rule to map a UL flow. Example 63 may include the method of examples 59-60 and/or some other examples herein, further comprising: selecting one or more links for each of the corresponding flows based on a routing rule associated with each of the corresponding flows; and transmitting a message to indicate the selected one or more links and a flow identifier for each of the corresponding flows, wherein the message is an RRC message or a NAS message.

Example 64 may include the method of example 63 and/or some other examples herein, wherein the routing rule is based on a QoS characteristic.

Example 65 may include the method of examples 59-60 and/or some other examples herein, further comprising: determining a first link over which a first flow of the plurality of flows is to be received and a second link over which a second flow of the plurality of flows is to be received; obtaining packets of the first flow from first communication circuitry used to communicate over the first link; and obtaining packets of the second flow from second communication circuitry used to communicate over the second link, wherein the first link is different than the second link.

Example 66 may include a method to be performed by base station ("BS"), the method comprising: transmitting a configuration message to establish a data radio bearer ("DRB"); instantiating one or more of packet data convergence protocol ("PDCP") entities in response to establishment of the DRB, wherein individual PDCP entities of the one or more of PDCP entities are to process corresponding flows of the one or more of flows; obtaining packets of the DRB after the DRB is established; classifying the obtained packets of the DRB into the one or more flows; providing, to the individual PDCP entities of the one or more of PDCP entities, the classified packets of the corresponding flows; and operating the individual PDCP entities to re-order the classified packets according to information included in the classified packets; and transmitting the re-ordered packets of the DRB to a destination device.

Example 67 may include the method of example 66 and/or some other examples herein, wherein classifying the obtained packets of the DRB comprises: identifying the obtained packets of the corresponding flows according to one or more internet protocol ("IP") tuples or a combination of two or more IP tuples, wherein the IP tuples comprise a source IP address, a source port, a destination IP address, a destination port, and a protocol type; determining a flow identifier ("ID") for the obtained packets; and inserting the flow ID into one of one or more most significant bits of a sequence number ("SN") field of a PDCP protocol data unit ("PDU") of a first packet of the received packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, or a value in a flow identifier field of the PDCP PDU or a PDCP body of the first packet.

Example 68 may include the method of example 66 and/or some other examples herein, wherein classifying the obtained packets of the DRB comprises: identifying the obtained packets of the corresponding flows according to one or more Quality of Service ("QoS") characteristics, wherein the QoS characteristics comprise a QoS class identifier ("QCI"), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level; determining a flow ID for the obtained packets; and inserting the flow ID into one of one or more most significant bits of an SN field of a PDCP PDU of a first packet of the received packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, or a value in a flow identifier field of the PDCP PDU or a PDCP body of the first packet.

Example 69 may include the method of example 66 and/or some other examples herein, wherein classifying the obtained packets of the DRB comprises: identifying a flow ID within individual packets of the obtained packets.

Example 70 may include the method of examples 66-69 and/or some other examples herein, wherein instantiating the plurality of PDCP entities comprises: creating a default PDCP entity upon establishment of the DRB, wherein the default PDCP entity is to process all packets of the DRB; detecting activation of a flow classification rule; and creating a first flow PDCP entity to process packets of a first flow based on the flow classification rule, and wherein upon creation of the first flow PDCP entity, the default PDCP entity is to cease processing the packets of the first flow and continue processing all other packets of the DRB.

Example 71 may include the method of example 70 and/or some other examples herein, further comprising: implementing, upon establishment of the DRB, the first PDCP entity to cipher or decipher all packets of the DRB using a bearer identifier of the DRB or the identified flow identifier; and implementing, upon creation of the second PDCP entity, the second PDCP entity to cipher or decipher the flow corresponding to the second PDCP entity using at least the bearer identifier of the DRB or a flow identifier of the flow corresponding to the second PDCP entity.

Example 72 may include a method to be performed by user equipment ("UE"), the method comprising: receiving a configuration message to establish a data radio bearer ("DRB"); determining, based on information in the configuration message, that the DRB is to be classified into individual flows of a one or more of flows; creating a default packet data convergence protocol ("PDCP") entity upon establishment of the DRB, wherein the default PDCP entity is to process all packets of the DRB; receiving packets of the DRB after the DRB is established; detecting activation of a flow classification rule, wherein the flow classification rule is to indicate that the DRB is to be classified into individual flows of a plurality of flows; creating a first flow PDCP entity to process packets of a first flow of the plurality of flows based on the flow classification rule, wherein upon creation of the first flow PDCP entity, the default PDCP entity is to cease processing the packets of the first flow and continue processing all other packets of the DRB; classifying obtained packets of the DRB as belonging to the first flow or belonging to other flows of the plurality of flows; and providing the classified packets belonging to the first flow to the first flow PDCP entity and the classified packets belonging to the other flows to the default PDCP entity.

Example 73 may include the method of example 72 and/or some other examples herein, wherein detecting the activation of the flow classification rule comprises: detecting a local activation of the flow classification rule, and wherein, to detect the local activation of the flow classification rule, the processor circuitry is to: determining a downlink ("DL") flow classification rule to map a downlink flow; or determining an uplink ("UL") flow classification rule to map an uplink flow.

Example 74 may include the method of example 72 and/or some other examples herein, wherein the flow classification rule is a first flow classification rule that corresponds with the first flow, and wherein the method comprises: detecting activation of a second flow classification rule corresponding to a second flow of the plurality of flows; creating a second flow PDCP entity to process packets of the second flow based on the second flow classification rule, wherein upon creation of the second flow PDCP entity, the default PDCP entity is to cease processing the packets of the second flow and continue processing all other packets of the DRB that do not belong to the first flow or the second flow; classifying packets of the DRB received after creation of the second flow PDCP entity as belonging to the first flow, belonging to the second flow, or belonging to the other flows of the plurality of flows; providing the classified packets belonging to the first flow to the first flow PDCP entity; providing the classified packets belonging to the second flow to the second flow PDCP entity; and providing the classified packets belonging to the other flows to the default PDCP entity.

Example 75 may include the method of examples 72-74 and/or some other examples herein, further comprising: identifying a first link over which a first flow of the plurality of flows is to be received and a second link over which a second flow of the plurality of flows is to be received, wherein the first link is provided by a first BS and the second link is provided by a second BS, and wherein the identification is based on an indication in the configuration message or an indication in a received RRC message or a received NAS message; obtaining packets of the first flow from the first communication circuitry used to communicate with the first BS over the first link; and obtaining packets of the second flow from second communication circuitry used to communicate with the second BS over the second link, wherein the first flow is a different flow than the second flow, and the first link is different than the second link.

The foregoing description of the above Examples provides illustration and description for the example embodiments disclosed herein, but the above Examples are not intended to be exhaustive or to limit the scope of the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings and/or may be acquired from practice of various implementations of the invention.

Claims

1. One or more computer-readable media including instructions, which when executed by one or more processors, causes a computer device to:

determine that a data radio bearer ("DRB") is to be classified into individual flows of a plurality of flows;

instantiate a plurality of packet data convergence protocol ("PDCP") entities, individual PDCP entities of the plurality of PDCP entities to process corresponding flows of the plurality of flows;

classify obtained packets of the DRB into the corresponding flows; and

provide, to the individual PDCP entities of the plurality of PDCP entities, the classified packets of the corresponding flows.

2. The one or more computer-readable media of claim 1, wherein, to classify the obtained packets of the DRB, the computer device, in response to execution of the instructions, is to:

identify the obtained packets of the corresponding flows according to one or more internet protocol ("IP") tuples, a combination of two or more IP tuples, one or more Quality of Service ("QoS") characteristics, or a flow identifier ("ID") marking in the classified packets.

3. The one or more computer-readable media of claim 2, wherein:

when identification of the obtained packets is according to one or more IP tuples or a combination of two or more IP tuples, the IP tuples comprise a source IP address, a source port, a destination IP address, a destination port, and a protocol type,

when identification of the obtained packets is according to one or more QoS characteristics, the QoS characteristics comprise a QoS class ID ("QCI"), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level, and

when identification of the obtained packets is according to the flow ID marking, wherein the flow ID is a value in a header portion of the obtained packets.

4. The one or more computer-readable media of claim 1 or 3, wherein, to classify the obtained packets of the DRB, the computer device, in response to execution of the instructions, is to: determine, based on a flow ID within individual packets of the obtained packets, an individual PDCP entity of the plurality of PDCP entities to which the obtained packets belong.

5. The one or more computer-readable media of claim 4, wherein, to identify a flow ID within individual packets of the obtained packets, the computer device, in response to execution of the instructions, is to:

extract a first flow ID from one of one or more most significant bits of a sequence number ("SN") field of a PDCP protocol data unit ("PDU") of a first packet of the obtained packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, a value in a flow ID field in a header portion of the PDCP PDU of the first packet, or a value in a flow ID field in a payload portion of the PDCP PDU of the first packet.

6. The one or more computer-readable media of claim 1, wherein the computer device, in response to execution of the instructions, is to:

operate the individual PDCP entities to insert a flow ID into the obtained packets when the flow ID is not present within individual packets of the obtained packets.

7. The one or more computer-readable media of any one of claims 1-6, wherein, to instantiate the plurality of PDCP entities, the computer device, in response to execution of the instructions, is to:

create a first PDCP entity upon establishment of the DRB, wherein the first PDCP entity is to process all packets of the DRB;

detect activation of a flow classification rule; and

create a second PDCP entity to process packets of a flow corresponding to the second PDCP entity based on the flow classification rule,

wherein upon activation of the flow classification rule, the first PDCP entity is to cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB.

8. The one or more computer-readable media of claim 7, wherein the computer device, in response to execution of the instructions, is further to: upon establishment of the DRB, implement the first PDCP entity to cipher or decipher all packets of the DRB using a bearer ID of the DRB or the identified flow ID; and

upon creation of the second PDCP entity, implement the second PDCP entity to cipher or decipher the flow corresponding to the second PDCP entity using at least the bearer ID of the DRB or a flow ID of the flow corresponding to the second PDCP entity.

9. One or more computer-readable media including instructions, which when executed by one or more processors, causes a computer device to:

determine that a data radio bearer ("DRB") has been established;

create a first packet data convergence protocol ("PDCP") entity upon establishment of the DRB, wherein the first PDCP entity is to process all packets of the DRB;

detect activation of a flow classification rule, wherein the flow classification rule is to indicate that the DRB is to be classified into individual flows of a plurality of flows; create a second PDCP entity to process packets of a flow of the plurality of flows corresponding to the second PDCP entity based on the flow classification rule, wherein upon creation of the second PDCP entity, the first PDCP entity is to cease processing the packets of the flow corresponding to the second PDCP entity and continue processing all other packets of the DRB;

classify obtained packets of the DRB as belonging to the flow corresponding to the second PDCP entity; and

provide, to the second PDCP entity, the classified packets belonging to the flow corresponding to the second PDCP entity.

10. The one or more computer-readable media of claim 9, wherein, to detect activation of a flow classification rule, the computer device, in response to execution of the instructions, is to:

identify the flow classification rule based on an internal configuration of the computer device, information included in access stratum signaling, information included in non-access stratum ("NAS") signaling, or information obtained from an application of the computer device via an application programing interface.

11. The one or more computer-readable media of claim 9 or 10, wherein, to detect activation of the flow classification rule, the computer device, in response to execution of the instructions, is to:

detect a local activation of the flow classification rule, wherein, to detect the local activation of the flow classification rule, the computer device, in response to execution of the instructions, is to:

determine a downlink ("DL") flow classification rule to map a downlink flow; determine an uplink ("UL") flow classification rule to map an uplink flow; and control transmission of the DL flow classification rule or the UL flow classification rule to another computer device.

12. The one or more computer-readable media of claim 9 or 10, wherein, to detect activation of the flow classification rule, the computer device, in response to execution of the instructions, is to:

identify an indication of the flow classification rule based on an obtained message, wherein, to identify the indication of the flow classification rule, the computer device, in response to execution of the instructions, is to:

control receipt of one or more signals, wherein the one or more signals comprise radio resource control ("RRC") signaling or NAS signaling; and

identify a DL flow classification rule to map a DL flow or a UL flow classification rule to map a UL flow.

13. The one or more computer-readable media of claim 9 or 10, wherein the computer device, in response to execution of the instructions, is to:

select one or more links for each of the corresponding flows based on a routing rule associated with each of the corresponding flows; and

control transmission of a message to indicate the selected one or more links and a flow identifier for each of the corresponding flows, wherein the message is an RRC message or a NAS message.

14. The one or more computer-readable media of claim 13, wherein the routing rule is based on a QoS characteristic.

15. The one or more computer-readable media of claim 9 or 10, wherein the computer device, in response to execution of the instructions, is to:

determine a first link over which a first flow of the plurality of flows is to be received and a second link over which a second flow of the plurality of flows is to be received;

obtain packets of the first flow from first communication circuitry used to communicate over the first link; and

obtain packets of the second flow from second communication circuitry used to communicate over the second link, wherein the first link is different than the second link.

16. An apparatus to be implemented by base station ("BS"), the apparatus comprising: communication circuitry to:

transmit a configuration message to establish a data radio bearer ("DRB"), and

transmit and receive packets of the DRB after the DRB is established; and processor circuitry coupled with the communication circuitry, the processor circuitry to:

instantiate one or more of packet data convergence protocol ("PDCP") entities in response to establishment of the DRB, wherein individual PDCP entities of the one or more of PDCP entities are to process corresponding flows of the one or more of flows;

classify obtained packets of the DRB into the one or more flows;

provide, to the individual PDCP entities of the one or more of PDCP entities, the classified packets of the corresponding flows; and

operate the individual PDCP entities to re-order the classified packets according to information included in the classified packets.

17. The apparatus of claim 16, wherein, to classify the obtained packets of the DRB, the processor circuitry is to:

identify the obtained packets of the corresponding flows according to one or more internet protocol ("IP") tuples or a combination of two or more IP tuples, wherein the IP tuples comprise a source IP address, a source port, a destination IP address, a destination port, and a protocol type;

determine a flow identifier ("ID") for the obtained packets; and insert the flow ID into one of one or more most significant bits of a sequence number ("SN") field of a PDCP protocol data unit ("PDU") of a first packet of the received packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, or a value in a flow identifier field of the PDCP PDU or a PDCP body of the first packet.

18. The apparatus of claim 16, wherein, to classify the obtained packets of the DRB, the processor circuitry is to:

identify the obtained packets of the corresponding flows according to one or more Quality of Service ("QoS") characteristics, wherein the QoS characteristics comprise a QoS class identifier ("QCI"), a bit rate, a delivery order, a reliability indication, a delay characteristic, and a priority level;

determine a flow ID for the obtained packets; and

insert the flow ID into one of one or more most significant bits of an SN field of a PDCP PDU of a first packet of the received packets, one or more least significant bits of the SN field of the PDCP PDU of the first packet, or a value in a flow identifier field of the PDCP PDU or a PDCP body of the first packet.

19. The apparatus of claim 16, wherein, to classify the obtained packets of the DRB, the processor circuitry is to:

identify a flow ID within individual packets of the obtained packets.

20. The apparatus of any one of claims 16-19, wherein, to instantiate the plurality of PDCP entities, the processor circuitry is to:

create a default PDCP entity upon establishment of the DRB, wherein the default

PDCP entity is to process all packets of the DRB;

detect activation of a flow classification rule; and

create a first flow PDCP entity to process packets of a first flow based on the flow classification rule,

wherein upon creation of the first flow PDCP entity, the default PDCP entity is to cease processing the packets of the first flow and continue processing all other packets of the DRB.

21. The apparatus of claim 20, wherein the processor circuitry is to: upon establishment of the DRB, implement the first PDCP entity to cipher or decipher all packets of the DRB using a bearer identifier of the DRB or the identified flow identifier; and

upon creation of the second PDCP entity, implement the second PDCP entity to cipher or decipher the flow corresponding to the second PDCP entity using at least the bearer identifier of the DRB or a flow identifier of the flow corresponding to the second PDCP entity.

22. An apparatus to be implemented in a user equipment ("UE"), the apparatus comprising:

communication circuitry to receive a configuration message to establish a data radio bearer ("DRB"), and receive packets of the DRB after the DRB is established; and processor circuitry coupled with the communication circuitry, the processor circuitry to:

determine, based on information in the configuration message, that the

DRB is to be classified into individual flows of a one or more of flows;

create a default packet data convergence protocol ("PDCP") entity upon establishment of the DRB, wherein the default PDCP entity is to process all packets of the DRB;

detect activation of a flow classification rule, wherein the flow classification rule is to indicate that the DRB is to be classified into individual flows of a plurality of flows;

create a first flow PDCP entity to process packets of a first flow of the plurality of flows based on the flow classification rule, wherein upon creation of the first flow PDCP entity, the default PDCP entity is to cease processing the packets of the first flow and continue processing all other packets of the DRB; classify obtained packets of the DRB as belonging to the first flow or belonging to other flows of the plurality of flows; and

provide the classified packets belonging to the first flow to the first flow PDCP entity and the classified packets belonging to the other flows to the default

PDCP entity.

23. The apparatus of claim 22, wherein, to detect activation of the flow classification rule, the processor circuitry is to: detect a local activation of the flow classification rule, and wherein, to detect the local activation of the flow classification rule, the processor circuitry is to:

determine a downlink ("DL") flow classification rule to map a downlink flow; or determine an uplink ("UL") flow classification rule to map an uplink flow.

24. The apparatus of claim 22, wherein the flow classification rule is a first flow classification rule that corresponds with the first flow, and wherein the processor circuitry is to:

detect activation of a second flow classification rule corresponding to a second flow of the plurality of flows;

create a second flow PDCP entity to process packets of the second flow based on the second flow classification rule, wherein upon creation of the second flow PDCP entity, the default PDCP entity is to cease processing the packets of the second flow and continue processing all other packets of the DRB that do not belong to the first flow or the second flow;

classify packets of the DRB received after creation of the second flow PDCP entity as belonging to the first flow, belonging to the second flow, or belonging to the other flows of the plurality of flows;

provide the classified packets belonging to the first flow to the first flow PDCP entity;

provide the classified packets belonging to the second flow to the second flow PDCP entity; and

provide the classified packets belonging to the other flows to the default PDCP entity.

25. The apparatus of any one of claims 22-24, wherein the communication circuitry comprises first communication circuitry and second communication circuitry, and the processor circuitry is to:

identify a first link over which a first flow of the plurality of flows is to be received and a second link over which a second flow of the plurality of flows is to be received, wherein the first link is provided by a first BS and the second link is provided by a second BS, and wherein the identification is based on an indication in the configuration message or an indication in a received RRC message or a received NAS message; obtain packets of the first flow from the first communication circuitry used to communicate with the first BS over the first link; and

obtain packets of the second flow from second communication circuitry used to communicate with the second BS over the second link, wherein the first flow is a different flow than the second flow, and the first link is different than the second link.