WO2020036928A1

WO2020036928A1 - Service data flow awareness for latency reduction

Info

Publication number: WO2020036928A1
Application number: PCT/US2019/046299
Authority: WO
Inventors: Jerome Parron; Alexandre Saso STOJANOVSKI; Ahmed Soud Salem; Sudeep Palat
Original assignee: Intel Corporation
Priority date: 2018-08-14
Filing date: 2019-08-13
Publication date: 2020-02-20

Abstract

Systems, apparatuses, methods, and computer-readable media are provided for mechanisms to prevent the split of packet flows and/or service data flows (SDFs) over multiple radio links thereby reducing jitter and latency for such flows, as well as mechanisms that enable faster packet delivery as compared to conventional solutions without layer 2 re-ordering. Other embodiments may be described and/or claimed.

Description

SERVICE DATA FLOW AWARENESS FOR LATENCY REDUCTION

RELATED APPLICATIONS

The present application claims priority to U.S. Provisional App. No. 62/718,834 filed August 14, 2018, the contents of 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 user equipment idle mode operations.

BACKGROUND

Fifth Generation (5G)/New Radio (NR) cellular communication networks, user equipment (UEs) and next generation NodeBs (gNBs) implement a user plane (UP) protocol stack to transfer user data/traffic to one another. Layer 2 of NR of the UP protocol stack is split into a Packet Data Convergence Protocol (PDCP) layer and Service Data Adaptation Protocol (SDAP) layer, among others. The PDCP layer receives PDCP Service Data Units (SDUs) from higher layers (e.g., SDAP), performs header compression and ciphering of the PDCP SDUs to obtain PDCP Protocol Data Units (PDUs), and submits the PDCP PDUs to lower layers. The PDCP layer performs deciphering of PDCP PDUs received from lower layers, re-orders the resulting PDCP SDUs according to their sequence numbers, and delivers the re-ordered PDCP SDUs to upper layers (e.g., SDAP). The re-ordering process performed by the PDCP layer introduces significant delays in dual connectivity (DC) scenarios because the two links may have significantly different latency and throughput characteristics. The PDCP layer can be configured for out-of-order-delivery, where the PDCP layer delivers PDCP SDUs to upper layers without re-ordering. Even when the PDCP layer is configured for out-of-order-delivery, some applications will have to wait for all the data to be received before delivering the SDUs to the upper layers. This leads to a performance degradation as the receiver entity will wait for all packets to be received over the link with higher latency leading to a bursty delivery to the application. This will degrade overall throughput, especially for delay and/or jitter sensitive applications.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 depicts an example system architecture according to various embodiments. Figure 2 shows example PDUs according to various embodiments. Figure 3 depicts an example processes for practicing the various embodiments discussed herein. DETAILED DESCRIPTION

Embodiments herein provide mechanisms to prevent the split of service data flows (SDFs) over multiple radio links thereby reducing jitter and latency for such SDFs, as well as mechanisms that enable faster packet delivery (as compared to conventional solutions) without layer 2 (L2) re-ordering. Referring now to Figure 1, in which an example system architecture 100 of a network according to various embodiments, is illustrated. The following description is provided for an example system architecture 100 that operates in conjunction with the Fifth Generation (5G) or NR system standards or LTE system standards as provided by the 3GPP technical specifications. 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 future 3GPP systems (e.g., Sixth Generation (6G)) systems, IEEE 802.16 protocols, or the like.

The system architecture 100 is shown to include a user equipment (UE) 101, (Radio) Access Network ((R)AN) 110 including (R)AN node 111, a 5G Core Network (5GC) 120 including a User Plane Function (UPF) 123, and a Data Network (DN) 130. As shown, the UE 101 is communicatively coupled with the (R)AN node 111 via a radio or air interface (Uu), the (R)AN 110 (or the (R)AN node 111) is communicatively coupled with the UPF 123 via the NG user plane interface (NG-U), and the UPF 123 is communicatively coupled with the DN 130 via the N6 reference point/interface.

The UE 101 is any device with radio communication capabilities, such as a wireless communications interface, and describes a remote user of network resources in a communications network. The UE 101 may be a smartphone, tablet, wearable device, desktop, laptop, head-up display (HUD) device, Internet of Things (IoT) device, networked or“smart” appliances, or the like. As discussed in more detail infra, the UE 101 may tag selected packets with a service tag and/or a“deliver with no delay” tag, and/or provide UE capability indicators to notify support for out of order PDCP delivery.

The (R)AN 110 is a set of (R)AN nodes 111 that implement a Radio Access Technology (RAT); the term“RAT” refers to a type of technology used for radio access such as NR, LTE/ Evolved Universal Terrestrial Radio Access (E-UTRA), WiFi/Wireless Local Area Network (WLAN), and/or the like. In Figure 1, the (R)AN 110 is a next generation RAN (NG-RAN) or a 5G access network (5G-AN), which supports standalone NR, standalone E-UTRA, and/or dual connectivity (DC) where NR is an anchor network with E-UTRA extensions and/or where E-UTRA is an anchor network with NR extensions. (R)AN 110 may also represent a UTRAN/GERAN, E-UTRAN, or some other suitable RAN of some other suitable RAT. The UE 101 utilizes a radio link comprising a physical communications interface or layer, which may be any tangible or intangible transmission medium used to communicate data. The radio link is an air/radio interface (Uu) to enable communicative coupling with the (R)AN 110.

The (R)AN 110 includes one or more (R)AN nodes 111 that enable the connections with the UE 101. The (R)AN node 111 is infrastructure equipment that provides the radio baseband functions and/or radio network controller functions (e.g., bearer management, uplink (UL) and downlink (DL) dynamic radio resource management, data packet (packet flow 145) scheduling, etc.). There may be multiple (R)AN nodes 111 present in the (R)AN 110, where each (R)AN node 111 is communicatively coupled with one another via respective Xn interfaces (not shown). The (R)AN node 111 may be a next generation NodeBs (gNB), evolved NodeB (eNB) next generation eNBs (ng-eNB), a Node, or the like. The (R)AN node 111 comprises ground stations (e.g., terrestrial access points) and/or satellite stations providing coverage within a geographic area (e.g., a cell). The (R)AN node 111 may be implemented as a dedicated physical device (e.g., macrocell, femtocell, picocell, or other like base station). Alternatively, the (R)AN nodes 111 may be implemented as a centralized unit (CU)/distributed unit (DU) split.

The UE 101 and the (R)AN node 111 communicate using Orthogonal Frequency Division Multiplexing (OFDM) and/or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication techniques. The UE 101 and the (R)AN node 111 implement various user plane (UP) protocol layers/entities including L2 entities such as Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptation Protocol (SDAP) layers. A physical layer (PHY) offers transport channels to the MAC; the MAC offers logical channels to the RLC; the RLC offers RLC channels to the PDCP; the PDCP offers radio bearers (including DRBs 154) to the SDAP; and the SDAP offers Quality of Service (QoS) flows 154 to upper layers. SDAP performs mapping between QoS flows 151 and Data Radio Bearers (DRBs) 154, and marks both DL and UL packets associated with the QoS flow 151 with a QoS flow ID (QFI). PDCP maintains PDCP sequence numbers, performs reordering and in-order delivery of PDCP PDUs/SDUs, performs out-of-order delivery of PDCP PDUs/SDUs, and performs routing for split bearers. A single SDAP entity and one or more PDCP entities may be configured for each individual PDU session 150. In embodiments, the PDCP entities of the UE 101 and (R)AN node 111 may deliver PDCP PDUs to upper or lower layers based on a “no delay” tag included in a packet flow regardless of a current out-of-order delivery configuration.

The (R)AN 110 is connected with the 5GC 120 via an NG interface which includes the NG-U and an NG control plane interface (NG-C) (not shown). The NG-C interface is a signaling interface between the (R)AN node 111 and an AMF in the 5GC 120 (e.g., the N2 reference point), and the NG-U carries user traffic/data between the (R)AN node 111 and the UPF 123 (e.g., the N3 and/or N9 reference points).

The UPF 123 acts as an anchor point for intra/inter-RAT mobility, and is an external Protocol Data Unit (PDU) session point of interconnect to DN 130. The UPF 123 includes various capabilities controlled by an SMF, which include a traffic detection capability (e.g., classifying traffic types of each packet flow), traffic usage reporting capability, QoS enforcement capability including QoS handling for UP (e.g., packet filtering, gating, UL/DL rate enforcement, etc.), and packet/traffic routing and forwarding capability. The UPF 123 also performs packet inspection, performs UL traffic verification (e.g., SDF to QoS flow 151 mapping), and performs transport level packet marking in the UL and DL, among others. UPF 123 may include an UL classifier to support routing traffic flows to the DN 130. The UPF 123 performs transport level packet marking for UL and DL traffic (e.g., packet flows 145) using corresponding packet marking information obtained from the SMF. The (R)AN 110 may also perform transport level packet marking in the UL on a per QoS flow 151 basis with a transport level packet marking value. The packet marking information includes, for example, the QFI and a transport level packet marking value. As examples, the transport level packet marking value may be the QFI associated with the QoS flows 151; a value calculated from a 5QI, priority level, and/or an ARP priority level; or a differentiated services code point (DSCP) value in an IP header. In embodiments, the UPF 123 performs service-based tagging of DL packets with flow IDs (e.g., SDF IDs and/or QFIs), and/or tagging of selected critical packet flows 145 with a“deliver with no delay” tag/flag.

The 5GC 120 may include network functions (NFs) in addition to the UPF 123. For example, the 5GC 120 may include one or more instances of an Access and Mobility Management Function (AMF), Authentication Server Function (AUSF) 122, Session Management Function (SMF) , Network Exposure Function (NEF), Policy Control Function (PCF), Unified Data Management (UDM), Unified Data Repository (UDR), AF(s), Network Slice Selection Function (NSSF), Network Function Repository Function (NRF), Short Message Service Function (SMSF), Non-3GPP Interworking Function (N3IWF), UE radio Capability Management Function (UCMF), and/or other like NR NFs.

The DN 130 may offer applications or services that use IP/network resources, and may represent various network operator services, Internet access, or third party services. The DN 130 may also represent one or more Local Area DNs (LADNs), a private packet DN (PDN) (e.g., an enterprise network, cloud computing service, etc.), Authentication, Authorization and Accounting (AAA) server(s), external Dynamic Host Configuration Protocol (DHCP) servers, an edge computing network/system (e.g., Multi-Access Edge Computing (MEC) host), content delivery network (CDN), and/or an intra-operator PDN (e.g., for provision of IMS and/or IP-CAN services). TheNF(s)/AF(s) of the 5GC 120 and/or the DN 130 comprise one or more physical and/or virtualized systems for providing functionality/services to UE 101. Such servers may include various computer devices with rack computing architecture component(s), tower computing architecture component(s), blade computing architecture component(s), and/or the like.

The UE 101 may operate one or more applications that communicate data with the DN 130. The UE 101 establishes a PDU session 150 with the DN 130 over which user traffic/data is to be communicated with the DN 130. Each application interaction requires one or more end-to-end (e2e) packet flows 145-1 to 145 -M (w here AT is a number). A packet flow 145 (also referred to as a“traffic flow,”“network flow,”“data flow,” or the like) refers to a flow, stream, or sequence of packets from a source node to a destination node (e.g., from the UE 101 to the DN 130 in the UL direction, and from the DN 130 to the UE 101 in the DL direction). As examples, the packets in a packet flow 145 may be IP packets, Ethernet packets, VLAN or IEEE 802.1Q packets, or the like. Some applications/packet flows 145 are“delay sensitive,”or otherwise sensitive to latency and/or packet delay variation (PDV) (“jitter”). Latency is the time between a packet being transmitted by a source node and received at the destination node, and PDV is the variation in latency as measured in the variance of e2e delay over time. Examples of such delay sensitive applications/data include voice, video, virtual reality (VR)/augmented reality (AR), applications involving tactile feedback, industrial IoT applications, and the like.

The UPF 123 performs application detection (e.g., within a packet flow 145) using filters, rules, etc. (e.g., SDF traffic filter(s)/templates or Packet Flow Description (PFD)) received from another NF (e.g., the SMF). A PFD is a set of information enabling the detection of application traffic provided by a 3rd party service provider (e.g., DN 130), and includes a PFD ID and one or more of 3-tuple(s) including protocol, server side IP address, and port number; significant parts of a URL to be matched (e.g., host name); and/or a domain name matching criteria and information about applicable protocol(s). In some cases, SDF traffic filter(s)\templates can be made from a PFD or some other parameters/criteria. An SDF is a packet flow 145 or an aggregate set of packet flows 145 carried through an NF that matches an SDF template. An SDF template is a set of SDF filters in a policy rule, or an application ID (app ID) in a policy rule referring to an application detection filter, required for defining an SDF. An SDF filter is a set of packet flow header parameter values/ranges used to identify one or more packet flows 145 constituting an SDF. As examples, the packet flow header parameter values/ranges may include a 5-tuple (source IP address, destination IP address, source port, destination port, protocol type), or a tag in the header provided by an application server or application function (AF). A specific SDF filter may be identified by a unique SDF filter ID (or an SDF ID). SDF filter(s) may be provided to the UPF 123 by the SMF, and the UPF 123 uses the SDF filter(s) as traffic detection filters (or packet filters). Each SDF can be associated with a QoS Flow 151 with a specific QoS definition and/or specific QoS class (e.g., a QoS forwarding treatment). Each SDF serves as a unit by which QoS rules can be applied to a QoS flow 151. Each SDF may correspond to an application interaction within the PDU session 150, and each SDF may be associated with a QoS flow 151. Each packet flow 145 heading to a UE 101 is classified into different SDFs according to their service type by using an SDF template. Then, appropriate QoS policies (or forwarding treatment) are applied to the SDFs before they are delivered to the UE 101.

The PDN session 150 includes a plurality of QoS flows 151-1 to 151-/V (where N is a number). The PDU Session 150 is an association between the UE 101 and the DN 130 that provides a PDU connectivity service. The PDU connectivity service is a service that provides exchange of PDUs (or packets) between the UE 101 and the DN 130. As examples, the PDU session 150 can be an IP session (e.g., IPv4, IPv6, IPv4v6, Internet Protocol Security (IPsec) with Encapsulating Security Payload (ESP), etc.), an Internet Control Message Protocol (ICMP) session, a Transport Control Protocol (TCP) session, a User Datagram Protocol (UDP session), a QUIC session, an Ethernet session, an‘Unstructured’ session type, among many others.

A QoS flow 151 is the finest granularity of QoS differentiation in a PDU session 150. Each of the QoS flows 151 are mapped in the (R)AN 110 to a respective DRB 154. All traffic (e.g., packet flows 145) mapped to the same QoS flow 151 receive the same forwarding treatment. Providing different QoS forwarding treatment to different packet flows 145 requires a separate QoS flow 151. The QoS forwarding treatment/behavior include aspects/parameters used to forward packets toward a destination node such as, for example, scheduling policy, scheduling weights (or priorities), queue management policy, queue management thresholds, rate shaping policy, RLC configuration, link layer protocol configuration, packet loss rate, packet delay budget, admission thresholds, bandwidth control, and the like. The QoS flows 151 are controlled by the SMF and may be preconfigured, established via the PDU Session Establishment procedure, or the PDU Session Modification procedure.

A QoS flow 151 is identified within a PDU session 150 by a QFI carried in an encapsulation header over the NG-U (e.g., N3 or N9 reference points).“Encapsulation” refers to the inclusion of one data structure within another data structure, such as by adding a packet header or adding data to the packet header. Packets are classified and marked using a QFI, which is a scalar that is used as a reference to a specific QoS forwarding treatment/behavior to be provided to a packet flow 145. This may be implemented in the (R)AN 110 using a 5G QoS ID (5QI) that references node-specific parameters that control the QoS forwarding treatment. According to various embodiments, packets may also be classified and marked using a service tag and/or a“no delay” tag/flag.

The (R)AN 110 and 5GC 120 ensure QoS by mapping packets to appropriate QoS flows 151 and DRBs 154. The (R)AN 110 maps on or more packet flows 145 belonging to the PDU session 150 to a DRB 154. This involves a first step (e.g., NAS level) of mapping packet flows 145 to QoS flows 151, and a second step (e.g., Access Stratum (AS) level) of mapping QoS flows 151 to DRBs 154. NAS level packet filters in the UE 101 and in the 5GC 120 associate UL and DL packets with QoS Flows 151, and AS level mapping rules in the UE 101 and in the (R)AN 110 associate UL and DL QoS Flows 151 with DRBs 154.

At the NAS level, each of the QoS flows 151 are characterized by a QoS profile, one or more QoS rule(s) and optionally QoS Flow level QoS parameters associated with the QoS rule(s), and one or more UL and DL Packet Detection Rules (PDRs). The QoS profile is used by the (R)AN 110 to determine the treatment on the radio interface (Uu) while the QoS rules dictate the mapping between UL UP traffic and QoS flows 151 to the UE 101. A QoS rule contains the QFI of the associated QoS flow 151, a packet filter set (PFS), and a precedence value. The UPF 123 uses the PFS in the QoS rule and the PDR to identify one or more packet flows 145. Each PFS corresponds to a PDU session 150 type. The PFS may contain one or more packet filter(s) where each packet filter is applicable for the DL direction, the UL direction, or both directions. The PDR(s) are used by the UPF 123 to identify packets belonging to a session or SDF, and include parameters describing how the UPF 123 is to treat packets that match the detection information.

At the AS level, the DRBs 154 define the packet treatment on the radio interface (Uu). Each DRB 154 serves packets with the same packet forwarding treatment. Several QoS flows 151 belonging to the same PDU session 150, and that are to receive the same packet forwarding treatment, can be multiplexed in the same DRB 154. Separate DRBs 154 may be established for QoS flows 151 requiring different packet forwarding treatment. The QoS flow 151 to DRB 154 mapping by the (R)AN 110 is based on the QFI and the associated QoS profiles (e.g., the QoS parameters and QoS characteristics). In embodiments, the QoS flow 151 to DRB 154 mapping by the (R)AN 110 is also based on service type of SDF ID. The mapping of QoS flows 151 to DRBs 154 in the UL is controlled by“QoS flow to DRB mapping rules” (e.g., QoS rules), which may be signaled/determined using reflective mapping or explicit configuration via Radio Resource Control (RRC) signaling.

The PDU session 150 may be a split PDU session 150, where one or more of the QoS flows 151 are served by more than one SDAP entities in the (R)AN 110. Split PDU sessions 150 are used for Dual Connectivity (DC) or Multi-Radio Dual Connectivity (MR- DC) scenarios, where the UE 101 is configured to utilize resources provided by two different access nodes connected via a non-ideal backhaul, one node providing NR/5G access and the other one providing either E-UTRA or NR/5G access. The UE 101 access these resources from each access node via respective Uu interfaces. One node acts as a master node (MN) and one or more other access nodes act as secondary node(s) (SN). The MN and SN are connected via a network interface (e.g., X2 or Xn interface) and at least the MN is connected to a core network. A split PDU session 150 includes at least one split bearer (or split DRB 154) and zero or more non-split bearers (or non-split DRBs 154). Split bearers used in DC are bearers (DRBs 154) whose radio protocols are located in both the MN and the SN to use both MN and SN resources, and non-split bearers are bearers (DRBs 154) whose radio protocols are located in either an MN or an SN to use MN or SN resource, respectively. The embodiments herein are also applicable to other split radio link implementations (e.g., LTE- WLAN Aggregation (LWA) and/or LTE/WLAN Radio Level Integration with IPsec Tunnels (LWIP)).

When using split bearers (or split DRBs 154), packets belonging to a corresponding traffic flow are split over two or more radio links. One problem with using split bearers (or split DRBs 154) is that the receiver (Rx) side PDCP entity needs to perform re-ordering because the split of the bearer takes place below the PDCP layer. However, when a SDF/packet flow 145 is split over multiple radio links (e.g., DC links), the transmitter (Tx) device (e.g., the UE 101 in the UL or the (R)AN node 111 in the DL) sends data on both radio links (respective Uu interfaces) leading to a split of packets belonging to a same SDF. The Rx PDCP layer re-orders the PDU(s) received on both radio links before delivery to the upper layers. The re-ordering process can introduce significant delays if the two radio links have significantly different latency and throughput characteristics. Even if the Rx PDCP entity is configured for out-of-order delivery, some applications will have to wait for all data to be received before delivering that data to upper layers. This means that such applications will wait for PDUs to be received over the link with higher latency before delivering the corresponding SDUs to upper layers. This leads to bursty delivery to the end applications and degrades overall throughput, especially for bursty and/or delay sensitive applications.

The UE 101 and/or UPF 123 may tag packets belonging to the same QoS flow 151 with a common QFI. However, each QoS flow 151 aggregates multiple SDFs, and individual SDFs within a QoS flow 151 are not distinguished by the RAN 110, which may result in the RAN 110 splitting the packet flows 145 for individual SDFs across different DC radio links. This introduces jitter and delay at the SDF level, which can degrade overall throughput. Additionally, the Rx PDCP entity can be configured with out-of-order delivery to deliver SDUs out of sequence to upper layers. However, some may support out-of-order delivery while other applications may not support out-of-order delivery. If the SDFs for both types of applications share the same DRB 154, then the PDCP layer cannot be configured to deliver out of sequence because some of the applications expect to receive data in sequence.

Various embodiments herein prevent splitting of SDFs that are associated with latency /jitter sensitive applications (“critical SDFs”), as well as enable the Rx to deliver packets to such applications without L2 re-ordering. Here, the two or more radio links of split DRBs 154 may still remain active, but critical packet flows 145 will be sent on the same, single radio link. In a first embodiment, the UPF 123 performs tags DL packets with a packet flow ID or SDF ID. In a second embodiment, the UPF 123 and/or the UE 101 tag selected packets as“delay sensitive.”“critical,” or as“deliver with no delay”. In a third embodiment, the UE 101 provides a capability indicator to the (R)AN 110 to indicate support of out of order delivery. These embodiments allow the Rx PDCP layer to deliver delay sensitive or otherwise critical packets to the upper layers even if the packets are not in sequence, even when the PDCP layer is configured for in-sequence delivery. These embodiments also allow information to gNB to determine whether or not it can configure NR PDCP to deliver out of sequence.

In the first embodiment, the UPF 123 identifies SDFs (or packet flows 145) that carry critical data, and tags these SDFs (or packet flows 145) with a unique SDF ID (SDF ID). The SDF ID is a scalar used as a reference to a specific service, service type, SDF, and/or specific type of application data carried by a packet flow 145. The (R)AN node 111 (or MN) identifies the SDF tag in packets of a packet flow 145, and prevents packets carrying a specific SDF ID from being split over multiple radio links of a split DRB 154. The SDF ID is used by the MN in case of split bearers/DRBs 154 to steer all packets from the same SDF or having a same SDF ID towards the same radio link for Tx to the UE 101. Some SDF IDs may be used to steer those packets towards one radio link, and other (non- critical) SDF IDs may be used to steer packets towards multiple radio link. In some embodiments, multiple SDFs with different SDF IDs can be tagged with the same QFI so that these SDFs can be mapped to a same QoS flow 151.

As an example, three packet flows 145 may be associated with each of QoS flows 151-1 and 151-2 running on the DRB 154-1, where a first packet flow 145-1 is to be sent only on an LTE radio link, a second packet flow 145-2 is to be sent only on an NR radio link, and a third packet flow 145-3 may be split between the LTE and NR radio links. The MN avoids splitting the traffic of the first packet flow 145-1 and the second packet flow 145-2 by detecting the SDF tags (e.g., SDF ID) in the first and second packet flows 145-1, 145-2, and directing all packets belonging to the first and second packet flows 145-1, 145- 2 to their respective radio links. The PDCP layer in the (R)AN 110 (or MN) may be used to enforce the traffic steering between the UE 101 and UPF 123 (e.g., preventing the SDF tagged packets from being split) since the PDCP layer in the (R)AN 110 (or MN) may be used to allocated traffic over the split DRBs 154. In these ways, the SDF ID may provide a further level of granularity for classifying packet flows within a DRB 154 according to service type in addition to QoS. This may be beneficial in that, although individual DRBs 154 are associated with one or more QoS flows 151 different applications/services receiving the same QoS treatment may have different sensitivities to delay and/or jitter.

Additionally, the UPF 123 may identify different packet flows 145 using packet inspection functionality to inspect the contents of the packet headers of one or more packets in the packet flows 145. For example, the UPF 123 may use SDF filter(s) or an app ID in an SDF template to detect a particular packet flow 145. In another example, the UPF 123 may obtain application data (including PFDs) from a UDR or NEF for application detection, and may use the PFD and/or app ID included in the application data for packet detection. An app ID is an identifier that can be mapped to a specific application traffic detection rule or PDR. The app ID is also an index to a set of application detection rules configured in the UPF 123. In another example, the UPF 123 may determine to group a number of the packet flows 145 together, and then add the same SDF ID to each packet flow 145 in the group of packet flows 145.

The UPF 123 makes a decision as to which packet flows 145 to tag and the particular SDF IDs to use to tag the packet flows 145 based on a configuration or information provided by another core network NF (e.g., the SMF). In one example, the UPF 123 configuration may indicate to tag all packet flows 145 belonging to a certain transport protocol (e.g., TCP, UDP, QUIC, etc.) with a particular SDF ID. This is because some types of transport protocols (e.g., TCP) may tend to carry more data of more sensitive applications than other types of transport protocols (e.g., UDP).

The UPF 123 appends the SDF_ID tag in the NG-U header (e.g., N3/N9 encapsulation header) and also in the SDAP or PDCP PDU header (see e.g., Figure 2). Adding the SDF ID to the SDAP or PDCP header may allow the UE 101 to avoid packet inspection, and may also ease internal packet routing within the UE 101. Furthermore, adding the SDF ID to the SDAP or PDCP headers may allow PDCP layer to deliver packets for the SDF tagged packet flows 145 out of sequence while continuing to deliver packets of other packet flows 145 on the same DRB 154 in-sequence. This may also indirectly reduce RRC signaling overhead as no additional PDCP configuration would be needed to reconfigure the PDCP entity for out-of-order delivery.

Alternatively, instead of tagging each individual packet flow 145 within the same DRB 154, the UPF 123 (or SMF) may create a new QFI and associated routing rules to identify an SDF or group of SDFs, and may add a tag to notify that this QFI shall be sent on only one DC radio link. In some embodiments, the network (e.g., UPF 123 or SMF) may create one QFI for each SDF, and in such cases, the extra SDF tagging is not required. The new QFI may be mapped to an individual DRB 154 in the same or similar manner as disused previously. The corresponding QFI and associated filter rule is provided to the UE 101 to instruct the UE 101 to use one radio link for this QFI when sending data in the UL. In this way, individual packet flows 154 may be identified from the split DRBs 154 as being critical flows for transmission over a single radio link. Alternatively, a new DRB 154 is created for critical flows 145, wherein a new QFI is created for the critical flow(s) 145, associating the critical flow(s) 145 with the new QFI, and creating a new DRB 145 for the critical flow(s) 145 to flow through.

The UE 101 may use Reflective QoS (RQoS) mechanisms to identify the QFI and/or SDF ID tags in DL packets and use the same QFI or SDF ID in UL packets of the same packet flow 145. Additionally, the UPF 123 may determine whether to use SDF ID tagging or new QFI tagging based on signaling or resource usage, and/or based on the amount of signaling/resources needed for a particular packet flow 145. For example, the UPF 123 may determine to tag a packet flow 145 with the new QFI when that packet flow 145 is used for a more long-term session and may determine to tag packets with the SDF ID when the flow 145 is use for a more short-term session (e.g., critical industrial IoT applications) since creating the new QFI and establishing a new DRB 154 may require more resources than simply tagging packets with the SDF ID.

In addition to using the PFDs and/or packet filters discussed previously to perform packet detection, the UPF 123 may obtain UE 101 assistance to identify critical flows 145. The UE 101 may detect that a particular flow 145 is latency sensitive, and send a request to the network (e.g., to the UPF 123 or the (R)AN 110) to associate the detected flow 145 to a new SDF ID or a new QFI and establish a new DRB 154 for communicating that packet flow 145. In this way, the UE 101 may request to have a particular packet flow 145 be exempted from being split over multiple radio links. Such a request may be sent to the (R)AN 110 over the Uu interface and then forwarded to the UPF 123 over the NG-U interface, or a new interface between the UE 101 and UPF 123 may be defined for this purpose.

In the second embodiment, the UPF 123 tags packets of a particular packet flow 145 with a specific tag to indicate that those packets should be delivered with little or no delay. A“no delay” tag is appended in the NG-U header (e.g., N3/N9 encapsulation header) and/or in the SDAP and/or PDCP header, along with the SDF ID or the new QFI discussed previously. The second embodiment may be used for special packets such as ICMP Router Advertisements, critical IoT applications (e.g., sensor data), etc. The second embodiment may apply to any type of split or non-split DRB 154.

The SMF can configure filters for the UE 101, (R)AN 110, and/or UPF 123 to identify which packets should be tagged with the“no delay” indicator/tag. Additionally or alternatively, the UE 101 can apply RQoS to derive the UL packet filter/rules to reflectively tag UL packets in the packet flow 145 with the“no delay” tag corresponding to DL packets of that packet flow 145 that were tagged with the“no delay” tag. When the UE 101 receives packets with the“no delay” tag, the UE 101 can determine the corresponding app ID or traffic filtering information (e.g., one or more 5-tuples that identify the destination node of the packet flow 145) and sets the corresponding UL filter. When UL packets match the filter, then the UE 101 sets the“no delay” tag/flag for such UL packets. The“No delay” tag is used by the Tx (e.g., the (R)AN node 111 in the DL or the UE 101 in the UL) to also tag PDCP PDU headers of such packets with a“deliver with no delay” tag or flag. The Rx PDCP entity should immediately deliver the packets/PDUs with such “no delay” tag/flag to the upper layers even if the PDCP sequence number (SN) of this packet is not in sequence. Additionally, the Rx PDCP still performs in-sequence delivery for other PDCP PDUs that do not include the“delivery with no delay” tag/flag. This allows the Rx PDCP layer to deliver the PDCP PDUs to upper layers without re-ordering and without requiring extra signaling to configure the PDCP entity for out-of-sequence delivery.

Additionally or alternatively, the (R)AN node 111 can establish a new DRB 154 for packet flows 145 tagged with the“no delay” tag. When the (R)AN node 111 receives packets with the“no delay” tag/flag, the (R)AN node 111 sets up a new DRB 154, configures PDCP layer with“out of order delivery” for this DRB 154, and then sends packets with the“no delay” tag/flag on this DRB 154. The UE 101 may use the RQoS mechanisms to perform the same functionality for UL packets. This may allow the (R)AN 110 to prevent or avoid splitting this DRB 154 over multiple radio links, and the (R)AN 110 can map this DRB 154 to a fastest link of the multiple radio links.

The third embodiment includes a UE capability indicator, which is used to notify UE 101 support of out of order PDCP delivery. The UE 101 is enabled or configured to inform the (R)AN 110/(R)AN node 111 that it is able (or capable) to re-order packets above the PDCP layer (e.g., at SDAP level), or that applications operated by the UE 101 are robust or can otherwise can handle PDCP out-of-order delivery. The third embodiments may be used by the (R)AN 1 l0/(R)AN node 111 to determine if it can configure the UE’s 101 PDCP layer to deliver packets out of order to the upper layers. The UE 101 may generate an RRC UE Capability information message to include UE Capability information, which includes the out-of-order delivery UE capability indicator (e.g., in an appropriate information element (IE) or the like). The UE 101 may generate and send the RRC UE Capability information message to the (R)AN node 111 in response to receipt of an RRC UE Capability Enquiry message sent to the UE 101 by the (R)AN node 111. This UE capability may be stored by the AMF along with other UE capability information.

Figure 2 shows example PDUs according to various embodiments. The example PDUs in Figure 2 include PDCP PDU 201, PDCP PDU 202, and SDAP PDU 203, which is an SDAP Data PDU format with SDAP header. Each of the PDUs 201-203 are bit strings that are byte aligned (e.g., in. multiples of 8 bits) in length. The most significant bit of the bit strings of each PDU 201-203 is the leftmost bit of the first line and the least significant bit is the rightmost bit on the last line. The bit order of each parameter field within each PDU 201-203 is represented with the first and most significant bit and the last and least significant bit. Additionally, the SDUs produced using the PDUs 201-203 may have a same or similar representation as the PDUs 201-203. The depicted fields may include data encoded in standard binary encoding.

Each of the PDUs 201-203 include an SDF ID field, an F field, and a no-reordering (NR) field. The SDF ID field carriers SDF identifier (ID) discussed previously. In the examples of Figure 2, the PDCP PDUs 201-202 include an 8 bit SDF ID field, and the SDAP PDU 203 includes a 7 bit SDF ID field. The F field is 1 bit in length (e.g., a flag field) and is used to indicate whether the SDF ID is present or not. For example, a value of 0 in the F field may indicate that the SDF ID not present, and a value of 1 in the F field may indicate that the SDF ID is present. Alternatively, the SDAP PDU 203 may include an extension bit to indicate the presence (or not) of the SDF ID. The NR field is 1 bit in length (e.g., a flag field) and is used to indicate whether PDU reordering is to take place. For example, a value of 1 in the NR field may set the no re-ordering flag and indicate that no reordering (or out-of-order delivery) is configured, and a value of 0 in the NR may indicate that the no re-ordering flag is not set and indicate that PDU reordering is configured.

The PDUs 201-203 also include a 1 bit D/C field indicating whether the PDU is a Data PDU or a Control PDU (e.g., 0 indicating a Control PDU, and 1 indicating a Data PDU), and a 1 bit Reserved (R) field(s), which are set to 0 and are ignored by the Rx. The data fields are of variable length and carry the data of the packet (e.g., the PDCP SDU or SDAP SDU). PDCP PDU 201 is a PDCP Data PDU format used for a 12 bit PDCP SN. PDCP PDU 202 is a PDCP Data PDU format for DRBs with 18 bits PDCP SN. The length of the PDCP SN is configured by upper layers. The MAC-I field carries a message authentication code.

The SDAP Data PDU 203 with SDAP header includes a 6 bit QFI field indicating the QFI to which the SDAP SDU belongs. The 1 bit RQoS flow to DRB mapping Indication (RDI) field indicates whether a QoS flow to DRB mapping rule should be updated (e.g., 0 indicating no action, and 1 indicating to store QoS flow to DRB mapping rule). The 1 bit Reflective QoS Indication (RQI) field indicates whether the NAS layer should be informed of the updated SDF to QoS flow mapping rules (e.g., 0 indicating no action, and 1 indicating to inform NAS that the RQI bit is set to 1). The D/C field may be present when the PDU 203 is an UL SDAP Data PDU 203 (e.g., used for UL data), and the RDI field may be present when the PDU 203 is an DL SDAP Data PDU 203 (e.g., used for DL data). Additionally or alternatively, there may be another bit simialar to the RDI or RQI fields, which may be referred to as a Reflective SDF mapping Indication (RFI) field to enable reflective SDF ID mapping. When the RFI is set in a DL packet/SDAP PDU 203, the UE 101 creates a new SDF filter based on a 5-tuple of the DL packet received with the RFI set, and when sending UL packets the UE 101 shall add the same SDF ID matching the newly created SDF filter.

Figure 3 shows an example packet handling process 300 in accordance with various embodiments. For illustrative purposes, process 300 is described as being performed by a computing system, which may correspond to one of the UE 101, (R)AN node 111, or UPF 123 of Figure 1. The process 300 may be embodied as one or more CRSM comprising program code, instructions, or other like a computer program product, which is to cause the computing system to perform electronic operations and/or to perform the specific sequence or flow of actions described with respect to Figure 3.

Process 300 begins at operation 305 where the computing system receives and/or identifies packets of a packet flow 145. At operation 310, the computing system performs a mapping procedure, which may involve mapping the packet flow 145 to a QoS flow 151 when the computing system is the UPF 123, or may involve mapping the packet flow 145 to a DRB 154 when the computing system is the (R)AN node 111. At operation 315, the computing system determines a service tag based on an identified service type of the packet flow. As alluded to previously, the service tag may be the SDF ID, anew QFI, a“no delay” tag/flag, or the like. At operation 320, the computing system tags the packets with the identified/determined service tag, which may include appending the SDF ID or QFI to an N3/N9 encapsulation header when the computing system is the UPF 123, and/or may involve adding or setting the“no delay” flag in PDCP or SDAP PDUs when the computing system is the (R)AN node 111. At operation 325, the computing system sends the packets of the packet flow towards a destination (e.g., the DN 130 for DL packets or the UE 101 for UL packets). After operation 325, process 200 ends or may repeat as necessary.

As an example operation of process 300 at each of the UE 101, (R)AN node 111, and UPF 123, DL traffic may be processed/handled as follows: At operations 305-310, the UPF 123 maps DL UP traffic to one or more QoS flows 151 based on PDR(s) associated with those QoS flows 151. Next, the UPF 123 performs transport level packet marking in DL packets on a per-QoS flow 151 basis using the transport level packet marking value provided by the SMF. Then, the UPF 123 encapsulates the DL packets for transmission over the NG-U interface (e.g., N3 encapsulation), and includes the QFI and an indication for RQoS activation (if applicable) in the encapsulation header (e.g., N3 encapsulation header). The transport level packet marking of the DL packets includes tagging the DL packets with the service tag at operations 315-320 (e.g., the SDF_ID). Alternatively, the encapsulation of the DL packets for transmission over the NG-U interface (e.g., N3 encapsulation) includes tagging the DL packets with the service tag at operations 315-320 (e.g., the new QFI). At operation 325, the UPF 123 transmits the PDUs of the PDU session 150 in a single tunnel between 5GC 120 and (R)AN 110 (e.g., the NG-U tunnel of Figure 1).

At operation 305, the (R)AN 1 l0/(R)AN node 111 receives the DL packets from the UPF 123, and at operation 310 the (R)AN H0/(R)AN node 111 maps PDUs from QoS flows 151 to access-specific resources (e.g., DRB(s) 154) based on the QFI and the associated 5G QoS profile taking into account the NG-U (N3) tunnel associated with the DL packet(s). At operation 315, the (R)AN H0/(R)AN node 111 determines/identifies the service tag in the DL packets/PDUs, and steers the DL packets for transmission to the UE 101 over one radio link among at least two radio links when the mapped DRB 154 is a split DRB 154 and when the service tag is associated with critical data/packet flows. At operation 320, the (R)AN H0/(R)AN node 111 tags SDAP/PDCP PDU headers with the “no delay” flag. Alternatively, operation 320 is skipped. At operation 325, the (R)AN H0/(R)AN node 111 transmits the DL packets/PDUs to the UE 101 over the access-specific resources (e.g., DRB(s) 154). In response to receipt of the DL packets/PDUs, the UE 101 creates a new derived QoS rule if RQoS applies, which includes tagging corresponding UL packets with the service tag and/or the“no delay” tag/flag. Additionally, when the“no delay” tag/flag is set, the PDCP entities in both the UE 101 and the (R)AN 1 l0/(R)AN node 111, the PDCP entities deliver the PDUs to upper layers without re-ordering the PDUs.

As another example operation of process 300 at each of the UE 101, (R)AN node 111, and UPF 123, UL traffic may be processed/handled as follows: At operations 305-310, the UE 101 uses stored QoS rules and/or UL packet filters (e.g., SDF filters/templates, etc.) to determine a mapping between UL UP traffic and one or more QoS flows 151. The QoS rules/filters may be a reflectively derived UL packet filter(s) when RQoS is used. Then, at operations 315-320 the UE 101 marks the UL PDU(s) with the QFI of the QoS rule containing the matching packet filter, and at operation 325 the UE 101 transmits the UL PDU(s) using the corresponding access specific resource (e.g., a DRB 154) for the QoS flow(s) 151 based on the mapping provided by (R)AN 1 l0/(R)AN node 111. The QFI used to mark the UL PDU(s) may be the aforementioned new QFI service tag. Alternatively, the UE 101 marks the UL PDU(s) with the SDF ID in addition to the QFI. Additionally or alternatively, the UE 101 at operation 320 tags SDAP/PDCP PDU headers with the“no delay” flag based on the QoS rules, packet filters, etc.

On receipt of the PDU(s)/packets from the UE 101 at operation 305, the (R)AN 1 lO/(R)AN node 111 performs transport level packet marking in the UL on a per-QoS flow 151 basis with a transport level packet marking value that is determined based on the 5QI, the Priority Level (if explicitly signalled), and/or the ARP priority level of the associated QoS flow 151. The (R)AN H0/(R)AN node 111 encapsulates the PDU(s) for a selected NG-U tunnel, and includes the QFI value in an encapsulation header of the UL PDU(s). Then, at operation 325 (R)AN 110 transmits the PDU(s) over the NG-U tunnel (e.g., an N3 tunnel) towards the UPF 123. The transport level packet marking of the UL packets includes tagging the UL packets with the service tag at operations 315-320 (e.g., the SDF_ID). Alternatively, the encapsulation of the UL packets for transmission over the NG-U interface (e.g., N3 encapsulation) includes tagging the UL packets with the service tag at operations 315-320 (e.g., the new QFI). Additionally, when the“no delay” tag/flag is set, the PDCP entities in both the UE 101 and the (R)AN 1 l0/(R)AN node 111, the PDCP entities deliver the PDUs to upper layers without re-ordering the PDUs.

Upon receipt of the packets/PDU(s), the UPF 123 verifies whether the QFIs in the UL PDU(s) are aligned with the QoS rules provided to the UE 101 or implicitly derived by the UE 101 (in the case of RQoS). Alternatively, this may also involve the UPF 123 verifying whether the service tags in the UL PDU(s) are aligned with the corresponding service type (e.g., critical vs. non-critical traffic handling parameters). The UPF 123 applies NG-U (e.g., N3/N9) tunnel related handling (e.g., encapsulation), and forwards UL UP traffic to the DN 130 based on forwarding operation information and forwarding targeting information obtain from the SMF. The details of the forwarding target and operation depend on the scenario and traffic type of the packet flow 145.

Details related to various aspects discussed herein are discussed in 3GPP TS 23.501 V15.2.0 (2018-06), 3 GPP TS 23.502 vl5.2.0 (2018-06), 3 GPP TS 24.501 vl5.0.0 (2018- 06), 3 GPP TS 37.324 vl5.0.0 (2018-06), 3 GPP TS 38.323 vl5.2.0 (2018-06), 3 GPP TS 38.300 vl5.2.0 (2018-06), and 3 GPP TS 38.331 vl5.2. l (2018-06). The following non- limiting examples pertain to further embodiments. Specifics in the examples may be used anywhere in one or more embodiments discussed previously. Any of the examples may be combined with any other example or combination of examples, unless explicitly stated otherwise.

Example A01 includes a method to be performed by a User Plane Function (UPF), the method comprising: identifying a service type of a packet flow in response to receipt of packets of the packet flow; tagging one or more packets of the packet flow with a service tag based on the identified service type, the service tag to indicate a traffic steering behavior for the packet flow; and sending the tagged packets to a destination node. Example A02 includes the method of example A01, further comprising: mapping the packet flow to a Quality of Service (QoS) flow. Example A03 includes the method of examples A01-A02, wherein the source node is a data network (DN) and the destination node is a user equipment (UE) when the packet flow is a downlink (DL) packet flow, and wherein the method comprises: sending the tagged packets to a Radio Access Network (RAN) node over an NG user plane interface between the RAN node and the UPF for delivery to the UE. Example A04 includes the method of example A03, further comprising: encapsulating the packets for transmission over the NG user plane interface including appending the service tag in an NG header added to the packets. Example A05 includes the method of examples A01-A02, wherein the destination node is a DN and the source node is a UE when the packet flow is an uplink (UL) packet flow, and the method comprises: forwarding the tagged packets to the DN over an N6 interface between the DN and the UPF. Example A06 includes the method of examples A01-A05, wherein the service type is one of a critical service type or a non-critical service type, and wherein the traffic steering behavior of the service tag for the critical service type is to indicate that the packet flow should only be conveyed over a single radio link of a split data radio bearer,“DRB”, and the traffic steering behavior of the service tag for the non-critical service type is to indicate that the packet flow can be conveyed over multiple radio links a split DRB. Example A06.2 includes the method of examples A01- A06, wherein the service tag is to further indicate whether an out-of-order delivery capability should be used for delivering the packets of the packet flow. Example A07 includes the method of examples A01-A06.2, wherein the packet tagging means is further for tagging packets based on a transport protocol of the packet flow. Example A08 includes the method of examples A01 -A07, wherein the identifying comprises identifying the service type by performing packet inspection on headers of one or more packets of the packet flow. Example A09 includes the method of example A08, wherein the packet flow is a SDF and the service tag is an SDF identifier (SDF ID) and the identifying comprises: identifying the service type by matching one or more header parameter values in one or more packets of the SDF with one or more corresponding header parameter values in one or more SDF filters; or identifying the service type by identifying an app ID in a header of one or more packets of the SDF with an app ID in a stored PFD. Example A10 includes the method of example A09, wherein the packet flow is an SDF, and the service tag is a QFI, wherein the identifying comprises using QoS routing rules associated with the QFI to identify the SDF, and the mapping comprises mapping the QFI to the DRB, wherein the DRB is established for SDFs carrying critical data. Example Al l includes the method of examples A01-A11, wherein the service tag is a“deliver with no delay” tag, and wherein the tagging comprises tagging a PDCP PDU header or a SDAP PDU header with the“deliver with no delay” tag when the out-of-order delivery capability should be used for delivering the packets of the packet flow.

Example B01 includes a method to be performed by a Radio Access Network (RAN) node, comprising: identifying a service tag in one or more packets of a packet flow in response to receipt of the one or more packets of the packet flow from a User Plane Function (UPF) the service tag to indicate that the packet flow is a critical packet flow or a non-critical packet flow; mapping the packet flow to a data radio bearer (DRB) based on the identified service tag; sending the one or more packets of the packet flow to a user equipment (UE) over at least two radio links when the DRB is a split SRB and when the packet flow is the non-critical packet flow; and sending the one or more packets of the packet flow to the UE over one radio link of the at least two radio links when the DRB is the split SRB and when the packet flow is the critical packet flow. Example B02 includes the method of example B01, wherein the packet flow is a service dataflow (SDF) the service tag is an SDF identifier (SDF ID), and the method comprises: mapping the one or more packets of the packet flow from a Quality of Service (QoS) flow to the DRB, wherein the DRB is established for the identified service type. Example B03 includes the method of example B01, wherein the packet flow is a service data flow (SDF) the service tag is a QFI and the method comprises: establishing the DRB for critical packet flows in response to identification of the service tag in the one or more packets; and mapping the QFI to the DRB. Example B04 includes the method of examples B02- B03, further comprising: operating a Packet Data Convergence Protocol (PDCP) layer to steer the one or more packets of the packet flow to be sent to the UE over the one radio link when the packet flow is the critical packet flow; or steer the one or more packets of the packet flow to be sent to the UE over the at least two radio links when the packet flow is the non-critical packet flow. Example B05 includes the method of example B04, further comprising: operating the PDCP layer to identify a“deliver with no delay” tag in a PDCP PDU header of PDCP PDUs included in the one or more packets; and deliver the PDCP PDUs to an SDAP when the“deliver with no delay” tag is set in the PDCP PDU header is set regardless of an out-of-order delivery configuration of the PDCP layer. Example C01 includes a method to be performed by a UE, comprising: operating a PDCP layer to, in response to detecting a“no delay” flag in a PDCP header of one or more PDCP PDUs deliver the PDCP PDUs to a SDAP without reordering the PDCP PDUs regardless of an out-of-order delivery configuration of the PDCP layer. Example C02 includes the method of example C01, wherein the one or more PDCP PDUs are included in DL packets of a packet flow, and the method comprises: identifying a service tag in the DL packets in response to receipt of the DL packets from a RAN node, the service tag to indicate that the packet flow is a critical packet flow or a non-critical packet flow; and using a UL packet filter to tag UL packets of the packet flow with the identified service tag and corresponding PDCP PDU headers with the“no delay” flag. Example C03 includes the method of example C01, wherein the one or more PDCP PDUs are included in received DL packets of a packet flow, and the method comprises: deriving a UL packet filter to reflectively tag UL packets in a packet flow corresponding to the PDCP PDUs with the“no delay” tag corresponding to the received DL packets of the packet flow that were tagged with the“no delay” tag; identifying a service tag in the DL packets of the packet flow in response to receipt of the DL packets from a RAN node, the service tag to indicate that the packet flow is a critical packet flow or a non-critical packet flow; and using the derived UL packet filter to reflectively tag the UL packets with the identified service tag and corresponding PDCP PDU headers with the“no delay” flag. Example C04 includes the method of examples C01-C03 further comprising: generating a message to include a UE capability indicator to indicate support for an out-of-order delivery capability; and transmitting the message to the RAN node.

Example Z01 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples A01-C04, or any other method or process described herein. Example Z02 may include one or more non-transitory CRSM comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples A01-C04, or any other method or process described herein. Example Z03 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples A01-C04, or any other method or process described herein. Example Z04 may include an apparatus comprising: one or more processors and one or more CRSM comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples A01-C04, or portions thereof. Example Z05 may include a signal as described in or related to any of examples A01-C04, or portions or parts thereof. Example Z06 may include a datagram, packet, frame, segment, PDU, or message as described in or related to any of examples A01-C04, or portions or parts thereof, or otherwise described in the present disclosure. Example Z07 may include a signal encoded with data a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples A01-C04, or portions or parts thereof, or otherwise described in the present disclosure. Example Z08 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples A01-C04, or portions thereof.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a,”“an” and“the” are intended to include plural forms as well, unless the context clearly indicates otherwise. The terms“comprises” and/or“comprising” specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operation, elements, components, and/or groups thereof. For the purposes of the present disclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C). The phrases“in an embodiment,” or“in some embodiments,” refer to one or more of the same or different embodiments. The terms“comprising,”“including,”“having,” and the like, may be synonymous. The term“circuitry” as used herein refers to a circuit or system of multiple circuits (e.g., ICs, ASICs, FPGAs, DSPs, etc.) configured to perform a particular function in an electronic device.

The foregoing description provides illustration and description of various example embodiments, but is not intended to be exhaustive or to limit the scope of embodiments to the precise forms disclosed. Modifications, equivalents, variations, and alternatives consistent with the present disclosure and the appended claims are possible in light of the above teachings or may be acquired from practice of various embodiments.

Claims

1. An apparatus to be implemented in a User Plane Function,“UPF”, the apparatus comprising:

service identification means for identifying a service type of a packet flow in response to receipt of packets of the packet flow;

packet tagging means for tagging one or more packets of the packet flow with a service tag based on the identified service type, the service tag to indicate a traffic steering behavior for the packet flow; and

communication means for receiving the packets of the packet flow from a source node, and for sending the tagged packets to a destination node.

2. The apparatus of claim 1, further comprising: mapping means for mapping the packet flow to a Quality of Service,“QoS”, flow.

3. The apparatus of claim 1, wherein the source node is a data network,“DN”, and the destination node is a user equipment,“UE”, when the packet flow is a downlink,“DL”, packet flow, and wherein the communication means is further for sending the tagged packets to a Radio Access Network,“RAN”, node over an NG user plane interface between the RAN node and the UPF for delivery to the UE.

4. The apparatus of claim 3, wherein the packet tagging means comprises: encapsulation means for encapsulating the packets for transmission over the NG user plane interface including appending the service tag in an NG header added to the packets.

5. The apparatus of claim 1, wherein the destination node is a DN and the source node is a UE when the packet flow is an uplink,“UL”, packet flow, and wherein the communication means is further for forwarding the tagged packets to the DN over an N6 interface between the DN and the UPF.

6. The apparatus of claim 1, wherein the service type is one of a critical service type or a non-critical service type, and wherein the traffic steering behavior of the service tag for the critical service type is to indicate that the packet flow should only be conveyed over a single radio link of a split data radio bearer,“DRB”, and the traffic steering behavior of the service tag for the non-critical service type is to indicate that the packet flow can be conveyed over multiple radio links a split DRB.

7. The apparatus of claim 1, wherein the packet tagging means is further for tagging packets based on a transport protocol of the packet flow.

8. The apparatus of any one of claims 1-7, wherein the service identification means is for identifying the service type by performing packet inspection on headers of one or more packets of the packet flow.

9. The apparatus of claim 8, wherein the packet flow is a service data flow,“SDF”, and the service tag is an SDF identifier,“SDF ID”, and the service identification means is for:

identifying the service type by matching one or more header parameter values in one or more packets of the SDF with one or more corresponding header parameter values in one or more SDF filters; or

identifying the service type by identifying an application identifier,“app ID”, in a header of one or more packets of the SDF with an app ID in a stored Packet Flow Description,“PFD”.

10. The apparatus of claim 9, wherein the packet flow is an SDF, and the service tag is a Quality of Service flow identifier,“QFI”, and wherein the service identification means is for using QoS routing rules associated with the QFI to identify the SDF, and the mapping means is for mapping the QFI to the DRB, wherein the DRB is established for SDFs carrying critical data.

11. The apparatus of claim 10, wherein the service tag is a“deliver with no delay” tag, and wherein the packet tagging means is for tagging a Packet Data Convergence Protocol,“PDCP”, Protocol Data Unit,“PDU”, header or a Service Data Adaptation Protocol,“SDAP”, PDU header with the“deliver with no delay” tag when the out-of-order delivery capability should be used for delivering the packets of the packet flow.

12. One or more computer-readable storage media (CRSM) comprising instructions, wherein execution of the instructions by one or more processors of a Radio Access Network, “RAN”, node is to cause the RAN node to:

identify a service tag in one or more packets of a packet flow in response to receipt of the one or more packets of the packet flow from a User Plane Function,“UPF”, the service tag to indicate that the packet flow is a critical packet flow or a non-critical packet flow; map the packet flow to a data radio bearer,“DRB”, based on the identified service tag;

send the one or more packets of the packet flow to a user equipment,“UE”, over at least two radio links when the DRB is a split SRB and when the packet flow is the non- critical packet flow; and

send the one or more packets of the packet flow to the UE over one radio link of the at least two radio links when the DRB is the split SRB and when the packet flow is the critical packet flow.

13. The one or more CRSM of claim 12, wherein the packet flow is a service data flow, “SDF”, the service tag is an SDF identifier, “SDF ID”, and execution of the instructions is to cause the RAN node to: map the one or more packets of the packet flow from a Quality of Service,“QoS”, flow to the DRB, wherein the DRB is established for the identified service type.

14. The one or more CRSM of claim 12, wherein the packet flow is a service data flow,“SDF”, the service tag is an QoS flow identifier,“QFI”, and execution of the instructions is to cause the RAN node to: establish the DRB for critical packet flows in response to identification of the service tag in the one or more packets; and map the QFI to the DRB.

15. The one or more CRSM of claim 13 or 14, wherein execution of the instructions is to cause the RAN node to operate a Packet Data Convergence Protocol,“PDCP”, layer to: steer the one or more packets of the packet flow to be sent to the UE over the one radio link when the packet flow is the critical packet flow; or steer the one or more packets of the packet flow to be sent to the UE over the at least two radio links when the packet flow is the non-critical packet flow.

16. The one or more CRSM of claim 15, wherein execution of the instructions is to cause the RAN node to operate the PDCP layer to:

identify a“deliver with no delay” tag in a PDCP Protocol Data Unit,“PDU”, header of PDCP PDUs included in the one or more packets; and

deliver the PDCP PDUs to a Service Data Adaptation Protocol,“SDAP”, when the “deliver with no delay” tag is set in the PDCP PDU header is set regardless of an out-of- order delivery configuration of the PDCP layer.

17. A System-on-Chip,“SoC”, to be implemented in a user equipment,“UE”, the SoC comprising:

interface circuitry; and

baseband circuitry coupled with the interface circuitry, the baseband circuitry to operate a Packet Data Convergence Protocol,“PDCP”, layer to: in response to detecting a “no delay” flag in a PDCP header of one or more PDCP Protocol Data Units,“PDUs”, deliver the PDCP PDUs to a Service Data Adaptation Protocol,“SDAP”, without reordering the PDCP PDUs regardless of an out-of-order delivery configuration of the PDCP layer.

18. The SoC of claim 17, wherein the one or more PDCP PDUs are included in downlink,“DL”, packets of a packet flow, and the baseband circuitry is to: identify a service tag in the DL packets in response to receipt of the DL packets from a Radio Access Network, “RAN”, node, the service tag to indicate that the packet flow is a critical packet flow or anon- critical packet flow; and use an uplink,“UL”, packet filter to tag UL packets of the packet flow with the identified service tag and corresponding PDCP PDU headers with the“no delay” flag.

19. The SoC of claim 17, wherein the one or more PDCP PDUs are included in received DL packets of a packet flow, and the baseband circuitry is to:

derive a UL packet filter to reflectively tag UL packets in a packet flow corresponding to the PDCP PDUs with the“no delay” tag corresponding to the received DL packets of the packet flow that were tagged with the“no delay” tag;

identify a service tag in the DL packets of the packet flow in response to receipt of the DL packets from a RAN node, the service tag to indicate that the packet flow is a critical packet flow or a non-critical packet flow; and

use the derived UL packet filter to reflectively tag the UL packets with the identified service tag and corresponding PDCP PDU headers with the“no delay” flag.

20. The SoC of any one of claims 17-18, wherein the interface circuitry is to communicatively couple the baseband circuitry with radiofrequency circuitry, and the baseband circuitry is further to: generate a message to include a UE capability indicator to indicate support for an out-of-order delivery capability; and provide the message to the radiofrequency circuitry for transmission to the RAN node.