Allocation of data radio bearers for quality of service flows

An example method can include receiving information identifying a quality of service (QoS) flow for a communication session involving a user equipment (UE). The information can include a QoS profile and a QoS flow identifier (QFI). The method can include identifying, from a QoS profile, a QoS configuration identifier associated with the QoS flow and selecting a data radio bearer (DRB) for the communications associated with the QoS flow. The DRB can be selected based on a mapping of a plurality of DRBs to a plurality of QoS flows, and the mapping can be based on corresponding QoS configuration identifiers of the plurality of QoS flows. The method can include assigning the QoS flow to the selected DRB by adding the QFI of the QoS flow to the mapping relative to the selected DRB and causing the communications associated with the QoS flow to be transmitted using the selected DRB.

BACKGROUND

5G/New Radio (5G/NR) is a next generation global wireless standard. 5G/NR provides various enhancements to wireless communications, such as flexible bandwidth allocation, improved spectral efficiency, ultra-reliable low-latency communications (URLLC), beamforming, high-frequency communication (e.g., millimeter wave (mmWave)), and/or the like.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings can identify the same or similar elements.

In a wireless telecommunications system (which can be referred to herein as “the system”), a particular quality of service (QoS) can be provided for a data flow. Such a data flow, that is to receive a particular QoS can be referred to as a QoS flow. A QoS flow can be identified by a particular identifier, such as a QoS flow identifier (QFI). A QFI for a QoS flow can be communicated, within QoS information, to one or more devices (e.g., a user equipment (UE), a base station, a user plane function (UPF) and/or the like) of the wireless telecommunications system to indicate that communications associated with that QoS flow are to receive a QoS as described in the QoS information. In such cases, the QFI can be identified in a field of a communication that includes the QoS information. Furthermore, that field can have a limited number of bits (e.g., six bits, seven bits, eight bits, and/or the like), as defined by a standard. In some instances, the wireless telecommunications system maps QoS flows, at a one-to-one ratio, to resources (e.g., data radio bearers (DRBs)) of an access network. In such cases, the QFI of the QoS flows can be used within a mapping of the QoS flows to the resources. However, in the wireless telecommunications system, there can be fewer resources that can be used than the number of different possible QFIs (or the number of different types of data flows). For example, while there can be more than 250 possible QFIs, there might be only 20 or fewer resources to which the QoS flows can be mapped. Accordingly, in such cases, the number of different QoS flows can be limited to the number of resources. For example, if the size of the QFI field allows for 256 different QFIs (or different QFI values), rather than a possible 256 different QFIs being available for mapping to resources, previous techniques are limited to, for example, 16 different QoS flows if there are 16 resources, 29 different QoS flows if there are 29 resources, and so on.

According to some implementations described herein, QoS flows can be mapped to resources of an access network using a plurality of different QoS parameters, other than a QFI of the QoS flow. The QoS parameters can be indicated in a QoS profile of the QoS information. Using the plurality of different parameters permits a more granular mapping of QoS flows to the resources of the access network, relative to previous techniques, thus providing for a more efficient use of the resources and a wider variety of different possible types of QoS flows that can be mapped to the resources. As described herein, a wireless communication system, such as a 5G wireless telecommunications network, can permit the QoS profile to include a QoS configuration identifier and/or one or more QoS parameters that can be used to map QoS flows to resources of an access network. In this way, the QoS configuration identifier (e.g., a 5G QoS identifier (5QI)) can permit QoS flows that have a same QoS configuration identifier to be mapped to a same resource.

Accordingly, some implementations described herein can permit a more efficient mapping of QoS flows to resources, which can be referred to herein as DRBs, of an access network relative to previous techniques, by allowing for a greater variety of different types of QoS flows to be communicated through the access network at a particular time. In this way, computing resources associated with frequently replacing QoS flow mappings to add a new QoS flow to the mapping can be conserved. Furthermore, enabling more types of QoS flows to be mapped to an access network at a given time reduces the likelihood of dropping communications and enables more efficient use of radio resources. For example, communications involving QoS flows that are removed from the mapping due to the limited number of possible mappings of QoS flows, are less likely to be dropped, thus conserving computing resources and/or network resources associated with retransmitting data associated with the dropped communications or errors caused by the dropped communications.

FIGS. 1A-1Dare diagrams of one or more example implementations100described herein. Example implementation(s)100, inFIG. 1A, includes a wireless communication system with a core network that includes a policy and control function (PCF), a session mobility function (SMF), and a UPF, a user equipment (UE), and an access network (shown as a radio access network (RAN)). As further shown inFIG. 1A, a plurality of resources (DRB1through DRBM, wherein M>1) enable communication between the UE and the RAN (or a base station of the RAN) and a communication session (e.g., a protocol data unit (PDU) session) is established, via an N3 interface, between the RAN and the UPF of the core network. As shown in the example mappings ofFIGS. 1B-1D, one or more mappings of QoS flows to the plurality of resources can be maintained using one or more QoS parameters included within a QoS profile of a QoS flow.

As further shown inFIG. 1A, and by reference number110, the UE is permitted to communicate data (e.g., transmit data and/or receive data) associated with QoS flows according to QFIs and/or corresponding QoS rules. The QFIs and/or QoS rules can be provided to the UE by the SMF of the core network via an N1 interface based on the UE requesting to communicate according to one or more QoS corresponding to the QFIs. The QFIs and/or QoS rules can be defined and/or enabled for the UE according to policies associated with the QoS flows and/or the UE (e.g., as maintained by the PCF). For example, the SMF (e.g., along with an access and mobility management function (AMF)) can perform one or more verifications and/or authentication processes of the UE in association with the requested QoS. Accordingly, the QFIs and/or QoS rules provided by the SMF to the UE can correspond to the QoS that is to be provided for QoS flows of the UE.

In this way, the UE can be authorized to transmit QoS flows through the RAN to transmit data via a PDU session associated with the core network.

As further shown inFIG. 1A, and by reference120, the RAN receives information identifying the QoS flows. The RAN can receive the information, via the N2 interface, from the SMF and/or an AMF of the core network. In some implementations, the SMF can provide the QFIs and/or packet filter sets to the UPF to permit the UPF to apply corresponding QoS to the QoS flows of the PDU session.

As described herein, the information identifying the QoS flows can include a QFI and a QoS profile. Further, the QoS profile can include one or more of a QoS configuration identifier (shown as an 8 bit “5QI” inFIG. 1A), an allocation and retention priority (ARP), and one or more bitrate parameters (shown as “BR parameters”), which can indicate whether the QoS flow requires a guaranteed bit rate (GBR). In some implementations, one or more preemption indicators (e.g., a preemption capability indication (PCI), a preemption vulnerability indication (PVI), and/or the like) associated with the ARP can be included within the QoS profile. In some implementations, for non-GBR QoS flows, the bitrate parameters can include a reflective QoS attribute (RQA). In some implementations, for GBR QoS flows, the bitrate parameters can include one or more of a guaranteed flow bit rate (GFBR) (e.g., for uplink and/or for downlink), a maximum flow bitrate (MFBR) (e.g., for uplink and/or for downlink), a notification control, a maximum packet loss rate (MPLR) (e.g., for uplink and/or for downlink), and/or the like.

In this way, the RAN can obtain QoS profiles associated with QoS flows of communications involving the UE, to permit the UE to communicate with the RAN using one or more resources that are to be allocated for the QoS flows according to the QoS profiles.

As further shown inFIG. 1A, and by reference number130, the RAN maps QoS flows to DRBs based on the QoS profiles. The RAN can include a QoS flow allocator that is configured to identify the QoS parameters of the QoS flow and map the QoS flows to DRBs of the RAN accordingly. In some implementations, the QoS flow allocator can be a component of a base station, a RAN scheduler, or another device of the RAN.

As described herein, the QoS flow allocator can maintain a mapping of QoS flows to DRBs of the RAN. The mapping can be maintained by the QoS flow allocator to permit the RAN to select a data radio bearer (DRB) for the communications associated with the QoS flow. For example, upon receipt of information identifying the QoS flow (or QFI and corresponding QoS profile), the QoS flow allocator can look up (e.g., search for, refer to, and/or the like), in the mapping, one or more QoS parameters of the QoS profile to determine which DRB is allocated for the one or more QoS parameters. Based on the mapping indicating that a DRB is allocated for the one or more QoS parameters, the QoS flow allocator can map the QoS flow to the DRB to assign the QoS flow to the DRB. In other words, the QoS flow allocator can assign the QoS flow to the DRB by adding the QFI of the QoS flow to the mapping relative to the selected DRB for the QoS flow. In this way, when a communication, associated with the QoS flow, is to be transmitted or received by the RAN, the communication can be assigned to that DRB to cause the data of QoS flow to be transmitted and/or received using that DRB.

As described herein, the QoS flow allocator can generate and/or maintain the mapping according to one or more settings that indicate which QoS parameters of a QoS profile are to be used to map QoS flows to the resources of the RAN. For example, as described below in connection withFIGS. 1B-1D, the QoS flow allocator can map the QoS flows according to one or more different sets of QoS parameters of the QoS flows.

In this way, the RAN can configure a mapping of QoS flows to resources of the RAN based on QoS profiles of the QoS flows, to cause the UE to communicate with the RAN using resources defined by the mapping.

As further shown inFIG. 1A, and by reference number140, communications between the UE and the RAN use the designated DRBs according to the corresponding QoS flows of the communications. Accordingly, for a communication involving a first QoS flow (shown as QoS flow1), the UE can be assigned, by the RAN, to use a first DRB (e.g., DRB1). Furthermore, for a communication involving a second QoS flow (shown as QoS flow2), the UE can be assigned, by the RAN, to use a second DRB (e.g., a DRB other than DRB1, such as one of DRB2to DRBM).

In some implementations, a plurality of UEs can be configured to communicate with the UE according to the mapping of QoS flows to the DRBs. Accordingly, several UEs, associated with sending and/or receiving QoS flows having a same QoS configuration identifier and/or one or more other QoS parameters (e.g., QoS parameters that are the same or similar in that QoS parameters have a same or similar value (e.g., with a threshold range), have a same or similar setting (e.g., both enabled or disabled), and/or the like), can use a same DRB to communicate with the RAN when the communication involves those QoS flows.

In this way, the core network and/or the RAN can be configured to permit one or more UEs to communicate via designated resources of the RAN according to one or more QoS parameters of a QoS profile. Therefore, the core network and/or the RAN can be configured to map a greater variety of QoS flows to resources of the RAN to permit the one or more UEs to receive a greater variety of QoS from a wireless communication system.

As shown inFIG. 1B, and by reference number130a, a mapping can provide that each DRB of a plurality of DRBs can be allocated for QoS flows that have a same QoS configuration identifier (shown as “5QI”). As shown inFIG. 1B, the mapping indicates that each DRB of the plurality of DRBs can be allocated for QoS flows that have a single, same QoS configuration identifier. Accordingly, multiple QoS flows that have a different QFI can be mapped to a same DRB if the multiple QoS flows are associated with and/or include a same QoS configuration identifier. As described herein, the QoS configuration identifier can be included within the QoS profile provided by the SMF.

As described herein, the QoS configuration identifier can be representative of one or more characteristics of the QoS that is to be provided for QoS flows associated with the QoS configuration identifier. Such characteristics can include one or more of: resource type (e.g., GBR or non-GBR), priority level (e.g., which can be any suitable range, such as 0-100) scheduling, packet delay budget (PDB), packet error rate (PER), and/or the like. As described herein, the one or more characteristics can correspond to one or more QoS parameters that are included in the QoS profile of the information identifying the QoS. The QoS configuration identifier can be configured for one or more types of services associated with the QoS flows. For example, a first QoS configuration identifier can be used to identify a QoS flow involving conversational voice, a second QoS configuration identifier can be used to identify real-time gaming and/or V2X messages, a third QoS configuration identifier can be used to one or more of voice service, live-streaming video, and/or interactive gaming, and so on. A standardized mapping of QoS configuration identifiers to corresponding characteristics of the QoS for the QoS configuration identifier and/or example services can be used by the UE, the RAN, and/or the core network to identify the characteristics of a QoS for a particular QoS configuration identifier.

In the example mapping ofFIG. 1B, a first set of QoS flows j, k, l, x, y, z are associated with 5QI “4E,” a second set of QoS flows a, b, c, d, e are associated with 5QI “1F,” a third set of QoS flows f, g, h, i, s are associated with 5QI “3A,” and a fourth set of QoS flows m, n, o, p, q are associated with 5QI “89.” As further shown in the mapping, based on the 5QIs of the above QoS flows, the first set of QoS flows can be mapped to DRB 0, the second set of QoS flows can be mapped to DRB 1, the third set of QoS flows can be mapped to DRB 2, and the fourth set of QoS flows can be mapped to DRB 3.

As further shown by the mapping ofFIG. 1B, the mapping can indicate a minimum ARP (e.g., a minimum ARP priority level) for QoS flows mapped to a corresponding DRB. For example, because one or more of the QoS flows, that are mapped to a particular DRB based on having the same 5QI, can have different ARPs, the RAN can set an ARP for each of the DRBs that corresponds to a minimum ARP of the QoS flows that are assigned to that DRB. In some implementations, for each DRB, the RAN can determine the minimum ARP based on analyzing (and/or comparing) the QoS profiles for each of the corresponding QoS flows mapped to the DRB and comparing the corresponding ARPs to identify the minimum ARP. As a specific example, assume that QoS flow j has the minimum ARP relative to the QoS flows of the first set of QoS flows. Accordingly, the RAN can set the ARP for the first set of QoS flows (and/or DRB 0) to be the ARP of QoS flow j (shown as “ARPj”). In this way, the first set of QoS flows, which are mapped to DRB 0, can receive a QoS with an ARP that is different from an ARP that is identified in respective QoS profiles of the first set of QoS flows.

As further shown by the mapping ofFIG. 1B, the mapping can indicate whether preemption capability and/or preemption vulnerability for QoS flows of the respective DRBs are to be enabled and/or disabled. For example, because one or more of the QoS flows, that are mapped to a particular DRB based on the 5QI, can have different settings for preemption capability and/or preemption vulnerability, the RAN can enable preemption capability and/or preemption vulnerability for each of the DRBs based on whether any of the QoS flows that are mapped to a particular DRB are to have preemption capability and/or preemption vulnerability enabled. In some implementations, for each DRB, the RAN can determine whether preemption capability and/or preemption vulnerability is to be enabled based on analyzing the QoS profiles for each of the corresponding QoS flows mapped the DRB. As a specific example, assume that one or more QoS flows of the first set of QoS flows has preemption vulnerability enabled, but none of the QoS flows of the first set of QoS flows has preemption capability enabled. Accordingly, preemption vulnerability can be enabled for the QoS flows mapped to DRB 0 (as shown by the “0”), and preemption capability is not to be enabled for the QoS flows mapped to DRB 0 (as shown by the “1”). As another specific example, assume that one or more of the QoS flows of the second set of QoS flows has preemption capability enabled, but none of the QoS flows of the second set of QoS flows has preemption vulnerability enabled. Accordingly, preemption capability can be enabled for QoS flows mapped to DRB 1 (as shown by the “0”) and preemption vulnerability is not to be enabled for the QoS flows mapped to DRB 1 (as shown by the “1”). In this way, if a PCI of a QoS profile for a QoS flow indicates that preemption capability is to be enabled for the QoS flow, the mapping allows for the RAN to cause the DRB to provide a QoS that provides preemption capability (e.g., by enabling the preemption capability for that DRB). Furthermore, if a PVI of a QoS profile for a QoS flow indicates that preemption vulnerability is to be enabled for the QoS flow, the mapping allows for the RAN to cause the DRB to provide a QoS that provides preemption vulnerability (e.g., by enabling the preemption vulnerability for that DRB).

As further shown by the mapping ofFIG. 1B, the mapping can indicate a GFBR and/or a MFBR for QoS flows of the respective DRBs. For example, because one or more of the QoS flows, that are mapped to a particular DRB based on having the same 5QI, can have different GFBRs and/or different MFBRs, the RAN can set GFBR and/or MFBR for each of the DRBs that corresponds to a sum of the GFBRs and/or a sum of the MFBRs of the QoS flows that are assigned to that DRB. In some implementations, for each DRB, the RAN can determine the GFBR sum and/or the MFBR sum based on analyzing (and/or comparing) the QoS profiles for each of the corresponding QoS flows mapped to the DRB and summing the corresponding GFBRs and/or MFBRs to identify the GFBR sum and/or MFBR sum. As a specific example, assume that QoS flows x, y, z have a GFBR and QoS flows k,1have an MFBR. Accordingly, the RAN can set the GFBR for the first set of QoS flows (and/or DRB 0) to be the sum of GFBRs of QoS flows x, y, z and the MFBR for the first set of QoS flows (and/or DRB 0) to be the MFBR of QoS flows k, l. In this way, the first set of QoS flows, which are mapped to DRB 0, can receive a QoS with GFBR and/or MFBR that is different from a GFBR that is identified in respective QoS profiles of the first set of QoS flows. As another example, assume that none of the QoS flows of the second set of QoS flows have a GFBR and/or an MFBR set. Accordingly, as shown, a GFBR and/or MFBR is not set for DRB 1.

As further shown by the mapping ofFIG. 1B, the mapping can indicate a minimum MPLR for QoS flows mapped to corresponding DRBs. For example, because one or more of the QoS flows, that are mapped to a particular DRB based on having the same 5QI, can have different MPLRs, the RAN can set an MPLR for each of the DRBs that corresponds to a minimum MPLR of the QoS flows that are assigned to that DRB. In some implementations, for each DRB, the RAN can determine the minimum MPLR based on analyzing (and/or comparing) the QoS profiles for each of the corresponding QoS flows mapped to the DRB and comparing the corresponding MPLRs to identify the minimum MPLR. As a specific example, assume that QoS flow f has the minimum MPLR relative to the QoS flows of the third set of QoS flows. Accordingly, the RAN can set the MPLR for the first set of QoS flows to be the MPLR of QoS flow f (shown as “MPLRf”). In this way, the third set of QoS flows, which are mapped to DRB 2, can receive a QoS with an MPLR that is different from an MPLR that is identified in respective QoS profiles of the third set of QoS flows.

In some implementations, the mapping can map QoS flows that have a same 5QI and one or more of the other parameters of the QoS profile (e.g., ARP, GFBR, MFBR, MPLR, and/or the like). For example, QoS flows with a first 5QI and a first ARP can be mapped to a first DRB and QoS flows with the first 5QI and a second ARP (that is different from the first ARP) can be mapped to a second DRB (that is different from the first DRB). Although example implementations are described above in connection with determining an ARP, a PCI, a PVI, a GFBR/MFBR, and/or an MPLR, one or more other techniques or implementations can be used.

In this way, the example mapping ofFIG. 1Bcan permit a RAN to map QoS flows based on QoS configuration identifiers associated with the QoS flows. While mapping the QoS flows according to the QoS configuration identifier can limit a number of different QoS configuration identifiers for QoS flows (e.g., to the number of resources, if mapped in a one-to-one manner), using the QoS configuration identifier can permit more QoS flows to be mapped, relative to using the QFI, because different QFIs can be associated with a same QoS configuration identifier. Furthermore, the example mapping ofFIG. 1Bprovides a relatively simple analysis and/or process for mapping QoS flows that would conserve resources (e.g., computing resources, such as processing resources and/or memory resources) associated with analyzing the QoS profiles to map the QoS flows based on a plurality of other QoS parameters.

InFIG. 1C, as shown by reference number130b, a mapping can provide that a first set of DRBs are to be used to allocate QoS flows in a first particular manner and a second set of DRBs that are to be used to allocate QoS flows in a second particular manner. As shown inFIG. 1C, the RAN can use 16 DRBs (DRB 0 through DRB 15), although, in some implementations, the RAN may be able to use more or fewer DRBs. In the example ofFIG. 1C, the first 13 DRBs (DRB 0 through DRB 12) can map QoS flows according to one or more of the examples described above in connection withFIG. 1B. For example, once the first 13 DRBs are mapped according to 5QIs of received QoS profiles, the RAN can begin mapping QoS flows based on one or more other types of QoS parameters of the QoS profiles. For example, any subsequently received QoS flows that have 5QIs that are different from the 5QIs of QoS flows mapped to DRBs 0-12, can be mapped to one or more of the remaining DRBs 13-15 based on one or more other QoS parameters of the QoS profile for those QoS flows.

In the example mapping ofFIG. 1C, the RAN can map QoS flows that have a 5QI that is different from the 5QIs of the QoS flows mapped to DRBs 0-12 (which can be referred to in this example as an “unmapped 5QI”) based on whether the QoS profile indicates that the QoS flow is configured with a GBR, whether the QoS flow has a priority level, and whether the QoS flow has a delay critical GBR. Therefore, for each QoS flow that is received with an unmapped 5QI, the RAN can inspect the QoS profile to identify any GBR, any priority level, and/or any delay critical GBR to map the QoS flow to a DRB accordingly. A priority level can include a range and/or a set of ranges of the range (e.g., high, medium, low, and/or the like).

In the example mapping ofFIG. 1C, a fifth set of QoS flows xy, zt, tb can be mapped to DRB 13, a sixth set of QoS flows cc, dc, ed can be mapped to DRB 14, and a seventh set of QoS flows ac, dy can be mapped to DRB 15. As described above, each of the fifth set of QoS flows can have a different QoS configuration identifier from one another, each of the sixth set of QoS flows can have a different QoS configuration identifier from one another, and each of the seventh set of QoS flows can have a different QoS configuration identifier from one another.

As shown inFIG. 1C, the fifth set of QoS flows are to have a GBR, a delay critical GBR, and a high (H) priority (e.g., greater than a threshold priority level). Further, the QoS flows of the sixth set of QoS flows do not involve a GBR or delay critical GBR and have a low (L) priority level (e.g., less than a threshold priority level). The QoS flows of the seventh set of QoS flows are to have a GBR, might not have a delay critical GBR, and have a high priority level. Accordingly, for any QoS flow with an unmapped QoS configuration identifier, the RAN can map those QoS flows to DRBs 13-15 according to the QoS parameters of the QoS flows of DRBs 13-15.

Furthermore, because QoS flows of DRBs 13-15 can be associated with different QoS configuration identifiers, the RAN can set a minimum PDB and/or a minimum PER for each of DRBs 13-15 that corresponds to a minimum PDB and/or a minimum PER of the respective QoS flows that are correspondingly mapped to each of DRBs 13-15. For example, for each of DRBs 13-15, the RAN can determine whether any of the QoS configuration identifiers of each of DRBs 13-15 are associated with a PDB, and/or a PER (e.g., by referring to a standardized mapping of QoS configuration identifiers to PDB and/or PER for the QoS configuration identifiers, as described above). In such a case, if any of the QoS flows have a PDB and/or PER, the RAN can be configured to select the minimum PDB and/or minimum PER associated with the respective QoS flows that are correspondingly mapped to each of DRBs 13-15. As a specific example, assume the QoS configuration identifier for QoS flow xy has a PDB and a PER and that the PDB and the PER for QoS flow xy is the minimum of the QoS flows of the fifth set of QoS flows. Accordingly, the RAN can set the PDB and/or the PER for the fifth set of QoS flows (and/or DRB 13) to be the PDB for QoS flow xy and the PER for QoS flow xy, respectively.

In this way, for one or more DRBs (shown as DRBs for unmapped 5QIs), the RAN can map QoS flows according to one or more other QoS parameters other than the QoS configuration identifier of the QoS flows. Accordingly, the QoS flows can be mapped to a DRB regardless the QoS configuration identifier for a QoS flow. Accordingly, the mapping ofFIG. 1Ccan permit a relatively simplistic mapping for a first set of DRBs (which can conserve computing resources associated with analyzing QoS parameters of the QoS profiles to map the QoS flows) without limiting the different number of QoS flows to the number of resources of the RAN by using a second set of DRBs that can be mapped regardless of the QoS configuration. In this way, the second set of DRBs does not limit the number of different QoS configuration identifiers for QoS flows to the number of resources of the RAN, thus allowing for greater variety of QoS flows and efficient use of DRBs 0-15.

As shown inFIG. 1D, and by reference number130c, a mapping can provide that each DRB of the plurality of DRBs of the RAN can be allocated for QoS flows based on one or more QoS parameters of the QoS flows. As shown inFIG. 1D, the mapping indicates that each DRB of the plurality of DRBs can be allocated for QoS flows that have the same or similar QoS parameters. In the example mapping ofFIG. 1D, the example set of QoS parameters used to map QoS flows to DRBs include ARP, resource type (e.g., associated with GBR, non-GBR, MFBR, delay critical GBR (shown as DC GBR), and/or the like), priority, PDB, and PER. Additionally, or alternatively, the mapping can map QoS flows to DRBs based on a GBR parameter (e.g., the value of the GBR), a default maximum data burst volume, a default averaging window, an RQA (for non-GBR), a PCI, a PVI, and/or the like. According to the mapping ofFIG. 1D, the RAN can analyze and/or consider any or all QoS parameters of QoS flows.

To generate the mapping ofFIG. 1D, the RAN can analyze the QoS parameters of QoS flows that are received in the QoS profile and/or represented by the QoS configuration identifier. The RAN can compare the QoS parameters to the groups of QoS parameters in the mapping to determine which DRB is to be mapped to the QoS flow, and, thus, which DRB is to be used for communications involving the QoS flow. To determine the similarity between the QoS parameters of a QoS flow and one or more sets of QoS parameters of the mapping, the RAN can apply one or more scores to the QoS parameters based on the similarities between corresponding QoS parameters and/or based on discrete ranges of corresponding QoS parameters. In some implementations, when applying the scores to the QoS parameters, the RAN can apply a weight to the QoS parameters according to one or more preferences and/or settings. Accordingly, the RAN can determine, for each received QoS flow and based on any number of QoS parameters of the QoS flow, which DRB is to be mapped to the QoS flow, and thus which DRB is to be used for communication involving the QoS flow.

In this way, the RAN can map QoS flows to DRBs based on one or more QoS parameters of the QoS flow. Accordingly, the RAN can allow for mapping of QoS flows to DRBs without being limited by the number of DRBs of the RAN. Therefore, a greater number of different QoS flows that provide a greater variety of QoS can be mapped to DRBs, thus allowing for efficient use of the DRBs and/or a greater number of services relative to other techniques.

Accordingly, as described herein in connection with example implementation(s)100, the RAN can use a mapping of QoS flows to DRBs using a QoS configuration identifier and/or one or more other QoS parameters. In this way, a greater variety of QoS and/or corresponding services, can be offered by a wireless communication system, thus allowing for more efficient use of resources (e.g., DRBs), relative to previous techniques, by enabling a more granular allocation of resources the wireless communication system. Such granularity prevents wasting resources on communications and/or QoS flows that do not require one or more QoS parameters of a QoS that must be assigned to those communications and/or QoS flows because of the limited number of different QoS flows offered by the previous techniques.

As indicated above,FIGS. 1A-1Dare provided as examples. Other examples can differ from what is described with regard toFIGS. 1A-1D.

FIG. 2is a diagram of an example environment200in which systems and/or methods, described herein, can be implemented. As shown inFIG. 2, environment200can include a UE210, a RAN220, a base station222, a core network230, and/or a data network240. Devices of environment200can interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

UE210can include one or more devices capable of communicating with base station222and/or a network (e.g., RAN220, core network230, data network240, and/or the like). For example, UE210can include a wireless communication device, a radiotelephone, a personal communications system (PCS) terminal (e.g., that can combine a cellular radiotelephone with data processing and data communications capabilities), a smart phone, a laptop computer, a tablet computer, and/or a similar device. UE210can be capable of communicating using uplink (e.g., UE to base station) communications, downlink (e.g., base station to UE) communications, and/or sidelink (e.g., UE-to-UE) communications. In some implementations, UE210can include a machine-type communication (MTC) UE, such as an evolved or enhanced MTC (eMTC) UE. In some implementations, UE210can include an Internet of Things (IoT) UE, such as a narrowband IoT (NB-IoT) UE and/or the like. UE210can correspond to the UE of example implementation100.

RAN220can include a base station and be operatively connected, via a wired and/or wireless connection, to the core network230. RAN220can facilitate communication sessions between UEs and data network240by communicating application-specific data between RAN220and core network230. Data network240can include various types of data networks, such as the Internet, a third-party services network, an operator services network, a private network, a wide area network, and/or the like. RAN220can correspond to the RAN of example implementation100.

Base station222includes one or more devices capable of communicating with UE210using a cellular radio access technology (RAT). For example, base station222can include a base transceiver station, a radio base station, a node B, an evolved node B (eNB), a gNB, a base station subsystem, a cellular site, a cellular tower (e.g., a cell phone tower, a mobile phone tower, etc.), an access point, a transmit receive point (TRP), a radio access node, a macrocell base station, a microcell base station, a picocell base station, a femtocell base station, or a similar type of device. Base station222can transfer traffic between UE210(e.g., using a cellular RAT), other base stations222(e.g., using a wireless interface or a backhaul interface, such as a wired backhaul interface), and/or data network240. Base station222can provide one or more cells that cover geographic areas. Some base stations222can be mobile base stations. Some base stations222can be capable of communicating using multiple RATs.

In some implementations, base station222can perform scheduling and/or resource management for UEs210covered by base station222(e.g., UEs210covered by a cell provided by base station222). In some implementations, base stations222can be controlled or coordinated by a network controller, which can perform load balancing, network-level configuration, and/or the like. The network controller can communicate with base stations222via a wireless or wireline backhaul. In some implementations, base station222can include a network controller, a self-organizing network (SON) module or component, or a similar module or component. In other words, a base station222can perform network control, scheduling, and/or network management functions (e.g., for other base stations222and/or for uplink, downlink, and/or sidelink communications of UEs210covered by the base station222). In some implementations, base station222can include a central unit and multiple distributed units. The central unit can coordinate access control and communication with regard to the multiple distributed units. The multiple distributed units can provide UEs210and/or other base stations222with access to data network240. Base station222can be a base station of the RAN of example implementation100and/or can be capable of performing one or more of the processes (e.g., mapping QoS flows to DRBs) described above in connection with example implementation100.

Core network230can include various types of core network architectures, such as a 5G next generation (NG) Core (e.g., a core network ofFIG. 3), a Long-Term Evolution (LTE) Evolved Packet Core (EPC), and/or the like. In some implementations, core network230can be implemented on physical devices, such as a gateway, a mobility management entity, and/or the like. In some implementations, the hardware and/or software implementing core network230can be virtualized (e.g., through use of network function virtualization and/or software-defined networking), thereby allowing for the use of composable infrastructure when implementing core network230. In this way, networking, storage, and compute resources can be allocated to implement the functions of core network230in a flexible manner as opposed to relying on dedicated hardware and software to implement these functions. Core network230can correspond to the core network of example implementation100.

Data network240includes one or more wired and/or wireless data networks. For example, data network240can include an IP Multimedia Subsystem (IMS), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a private network such as a corporate intranet, an ad hoc network, the Internet, a fiber optic-based network, a cloud computing network, a third party services network, an operator services network, and/or the like, and/or a combination of these or other types of networks.

The number and arrangement of devices and networks shown inFIG. 2are provided as one or more examples. In practice, there can be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown inFIG. 2. Furthermore, two or more devices shown inFIG. 2can be implemented within a single device, or a single device shown inFIG. 2can be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment200can perform one or more functions described as being performed by another set of devices of environment200.

FIG. 3is a diagram of an example functional architecture of a core network300in which systems and/or methods, described herein, can be implemented. For example,FIG. 3can show an example functional architecture of a 5G NG core network included in a 5G wireless telecommunications system. In some implementations, the example functional architecture can be implemented by a core network (e.g., core network230ofFIG. 2) and/or one or more of devices (e.g., a device described with respect toFIG. 4). While the example functional architecture of core network300shown inFIG. 3can be an example of a service-based architecture, in some implementations, core network300can be implemented as a reference-point architecture.

As shown inFIG. 3, core network300can include a number of functional elements. The functional elements can include, for example, a network slice selection function (NSSF)302, a network exposure function (NEF)304, an authentication server function (AUSF)306, a unified data management (UDM) component308, a PCF310, an application function (AF)312, an AMF314, a SMF316, and a UPF318. These functional elements can be communicatively connected via a message bus320, which can be comprised of one or more physical communication channels and/or one or more virtual communication channels. Each of the functional elements shown inFIG. 3is implemented on one or more devices associated with a wireless telecommunications system. In some implementations, one or more of the functional elements can be implemented on physical devices, such as an access point, a base station, a gateway, a server, and/or the like. In some implementations, one or more of the functional elements can be implemented on one or more computing devices of a cloud computing environment associated with the wireless telecommunications system. In some implementations, the core network300can be operatively connected to a RAN220, a data network240, and/or the like, via wired and/or wireless connections with UPF318.

NSSF302can select network slice instances for UE's, where NSSF302can determine a set of network slice policies to be applied at the RAN220. By providing network slicing, NSSF302allows an operator to deploy multiple substantially independent end-to-end networks potentially with the same infrastructure. In some implementations, each slice can be customized for different services. NEF304can support the exposure of capabilities and/or events in the wireless telecommunications system to help other entities in the wireless telecommunications system discover network services and/or utilize network resources efficiently.

AUSF306can act as an authentication server and support the process of authenticating UEs in the wireless telecommunications system. UDM308can store subscriber data and profiles in the wireless telecommunications system. UDM308can be used for fixed access, mobile access, and/or the like, in core network300. PCF310can provide a policy framework that incorporates network slicing, roaming, packet processing, mobility management, and/or the like.

AF312can determine whether UEs provide preferences for a set of network slice policies and support application influence on traffic routing, access to NEF304, policy control, and/or the like. AMF314can provide registration and mobility management of UEs.

SMF316can support the establishment, modification, and release of communications sessions in the wireless telecommunications system. For example, SMF316can configure traffic steering policies at UPF318, enforce UE IP address allocation and policies, and/or the like. AMF314and SMF316can act as a termination point for non-access stratum (NAS) signaling, mobility management, and/or the like. SMF316can act as a termination point for session management related to NAS. RAN220can send information (e.g. the information that identifies the UE) to AMF314and/or SMF316via PCF310. As described herein, SMF316can communicate information identifying a QoS flow to UE210, RAN220, UPF318, and/or the like.

UPF318can serve as an anchor point for intra/inter radio access technology (RAT) mobility. UPF318can apply rules to packets, such as rules pertaining to packet routing, traffic reporting, handling user plane QoS, and/or the like. UPF318can determine an attribute of application-specific data that is communicated in a communications session. UPF318can receive information (e.g., the information that identifies the communications attribute of the application) from RAN220via SMF316or an application programming interface (API). Message bus320represents a communication structure for communication among the functional elements. In other words, message bus320can permit communication between two or more functional elements. Message bus320can be a message bus, a hypertext transfer protocol 2 (HTTP/2) proxy server, and/or the like.

RAN220can include a base station and be operatively connected, via a wired and/or wireless connection, to the core network300through UPF318. RAN220can facilitate communications sessions between UEs and data network240by communicating application-specific data between RAN220and core network300. Data network240can include various types of data networks, such as the Internet, a third-party services network, an operator services network, a private network, a wide area network, and/or the like.

The number and arrangement of functional elements shown inFIG. 3are provided as an example. In practice, there can be additional functional elements, fewer functional elements, different functional elements, or differently arranged functional elements than those shown inFIG. 3. Furthermore, two or more functional elements shown inFIG. 3can be implemented within a single device, or a single functional element shown inFIG. 3can be implemented as multiple, distributed devices. Additionally, or alternatively, a set of functional elements (e.g., one or more functional elements) of core network300can perform one or more functions described as being performed by another set of functional elements of core network300.

Storage component440stores information and/or software related to the operation and use of device400. For example, storage component440can include a hard disk (e.g., a magnetic disk, an optical disk, and/or a magneto-optic disk), a solid-state drive (SSD), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and/or another type of non-transitory computer-readable medium, along with a corresponding drive.

Input component450includes a component that permits device400to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and/or a microphone). Additionally, or alternatively, input component450can include a component for determining location (e.g., a global positioning system (GPS) component) and/or a sensor (e.g., an accelerometer, a gyroscope, an actuator, another type of positional or environmental sensor, and/or the like). Output component460includes a component that provides output information from device400(via, e.g., a display, a speaker, a haptic feedback component, an audio or visual indicator, and/or the like).

Communication interface470includes a transceiver-like component (e.g., a transceiver, a separate receiver, a separate transmitter, and/or the like) that enables device400to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface470can permit device400to receive information from another device and/or provide information to another device. For example, communication interface470can include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a wireless local area network interface, a cellular network interface, and/or the like.

Device400can perform one or more processes described herein. Device400can perform these processes based on processor420executing software instructions stored by a non-transitory computer-readable medium, such as memory430and/or storage component440. As used herein, the term “computer-readable medium” refers to a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

Software instructions can be read into memory430and/or storage component440from another computer-readable medium or from another device via communication interface470. When executed, software instructions stored in memory430and/or storage component440can cause processor420to perform one or more processes described herein. Additionally, or alternatively, hardware circuitry can be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

The number and arrangement of components shown inFIG. 4are provided as an example. In practice, device400can include additional components, fewer components, different components, or differently arranged components than those shown inFIG. 4. Additionally, or alternatively, a set of components (e.g., one or more components) of device400can perform one or more functions described as being performed by another set of components of device400.

FIG. 5is a flowchart of an example process500associated with allocation of DRBs for quality of service flows. In some implementations, one or more process blocks ofFIG. 5can be performed by a base station (e.g., base station222) of a RAN (e.g., RAN220). In some implementations, one or more process blocks ofFIG. 5can be performed by another device or a group of devices separate from or including the base station, such as such as one or more components of a RAN (e.g., RAN220), one or more components or functions (e.g., NSSF302, NEF304, AUSF306, UDM308, PCF310, AF312, AMF314, SMF316, UPF318) of a core network (e.g., core network300), and/or the like.

As shown inFIG. 5, process500can include receiving information identifying a QoS flow for a communication session involving a UE, wherein the information includes a QoS profile and a QFI (block510). For example, the base station (e.g., using a processor420, a memory430, a storage component440, an input component450, and a communication interface470, and/or the like) can receive information identifying a QoS flow for a communication session involving a UE, as described above. In some implementations, the information includes a QoS profile and a QFI.

As further shown inFIG. 5, process500can include identifying, by the device and from the QoS profile, a QoS configuration identifier associated with the QoS flow, wherein the QoS configuration identifier is associated with a QoS that is to be provided for communications associated with the QoS flow (block520). For example, the base station (e.g., using a processor420, a memory430, a storage component440, an input component450, and a communication interface470, and/or the like) can identify, by the device and from the QoS profile, a QoS configuration identifier associated with the QoS flow, as described above. In some implementations, the QoS configuration identifier is associated with a QoS that is to be provided for communications associated with the QoS flow.

As further shown inFIG. 5, process500can include selecting a DRB for the communications associated with the QoS flow, wherein the DRB is selected based on a mapping of a plurality of DRBs to a plurality of QoS flows, wherein the mapping is based on corresponding QoS configuration identifiers of the plurality of QoS flows, and wherein the plurality of DRBs are DRBs of a RAN associated with the device (block530). For example, the base station (e.g., using a processor420, a memory430, a storage component440, an input component450, and a communication interface470, and/or the like) can select a DRB for the communications associated with the QoS flow, as described above. In some implementations, the DRB is selected based on a mapping of a plurality of DRBs to a plurality of QoS flows. In some implementations, the mapping is based on corresponding QoS configuration identifiers of the plurality of QoS flows. In some implementations, wherein the plurality of DRBs are DRBs of a RAN associated with the device.

As further shown inFIG. 5, process500can include assigning the QoS flow to the selected DRB by adding the QFI of the QoS flow to the mapping relative to the selected DRB (block540). For example, the base station (e.g., using a processor420, a memory430, a storage component440, an output component460, and a communication interface470, and/or the like) can assign the QoS flow to the selected DRB by adding the QFI of the QoS flow to the mapping relative to the selected DRB, as described above.

As further shown inFIG. 5, process500can include causing the communications associated with the QoS flow to be transmitted using the selected DRB (block550). For example, the base station (e.g., using a processor420, a memory430, a storage component440, an output component460, and a communication interface470, and/or the like) can cause the communications associated with the QoS flow to be transmitted using the selected DRB, as described above.

In some implementations, the mapping provides that each DRB of the plurality of DRBs is to be allocated for QoS flows that have a same QoS configuration identifier. In some implementations, the mapping provides that each DRB of the plurality of DRBs is to be allocated for QoS flows that have a single, same QoS configuration identifier. In some implementations, the mapping provides a first set of DRBs of the plurality of DRBs and a second set of DRBs of the plurality of DRBs. In some implementations, each DRB of the first set of DRBs is to be allocated to QoS flows that have a single, same QoS configuration identifier. In some implementations, at least one DRB of the second set of DRBs is to be allocated to QoS flows that have different QoS configuration identifiers relative to QoS flows assigned to each respective DRB.

In some implementations, the QoS profile includes an allocation and retention priority (ARP) for the QoS flow. In some implementations, the mapping provides that each DRB, of the plurality of DRBs, is to be configured to provide the QoS based on a minimum ARP. In some implementations, the minimum ARP comprises an ARP, of a plurality of ARPs corresponding to the QoS flows that are assigned to the respective DRB, associated with a lowest priority level.

In some implementations, the QoS profile includes a PCI that indicates whether preemption capability is enabled or disabled for the QoS flow. In some implementations, if the PCI indicates that preemption capability is enabled for the QoS flow, the mapping provides that the selected DRB is to provide a QoS that provides preemption capability. In some implementations, the QoS profile includes a PVI that indicates whether preemption vulnerability is enabled or disabled for the QoS flow. In some implementations, if the PVI indicates that preemption vulnerability is enabled for the QoS flow, the mapping provides that the selected DRB is to provide a QoS that provides preemption vulnerability.

In some implementations, the mapping of the plurality of DRBs to the plurality of QoS flows is based on at least one of a guaranteed bitrate (GBR) parameter, a priority level, a packet delay budget, a resource type, a priority level, a default maximum data burst volume, a default averaging window, or a packet error rate.

AlthoughFIG. 5shows example blocks of process500, in some implementations, process500can include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG. 5. Additionally, or alternatively, two or more of the blocks of process500can be performed in parallel.

The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations can be made in light of the above disclosure or can be acquired from practice of the implementations.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features can be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below can directly depend on only one claim, the disclosure of various implementations includes each dependent claim in combination with every other claim in the claim set.