Patent Description:
Generally, a wireless multiple-access communication system can simultaneously support communication for multiple user equipment devices (UE). Each UE communicates with one or more base stations, such as an evolved Node B (eNB) via transmissions on the forward and reverse links. The forward link (or downlink) refers to the communication link from the eNBs to the UEs, and the reverse link (or uplink) refers to the communication link from the UEs to the eNBs. This communication link may be established via a single-in-single-out, multiple-in-single-out or a multiple-in-multiple-out (MIMO) system. In this regard, the UEs can access wireless network via one or more eNBs.

In systems such as LTE, an evolved packet system (EPS) bearer is established between a UE and a core network to facilitate communications therebetween, and the UE can establish a data radio bearer (DRB) for radio access network (RAN) communications with the eNB, where the DRB can be bound to the EPS bearer. Multiple EPS bearers with the core network, and corresponding DRBs between the UE and eNB, are used for providing a quality-of-service (QoS) to a given traffic flow between the UE and the core network. A bearer establishes a "virtual" connection between two endpoints so that traffic can be sent between them. The bearer acts as a pipeline between the two endpoints. This coupling between EPS bearers and DRBs requires the core network to manage EPS bearers for each DRB to provide the prescribed QoS. <CIT> discusses QoS improvements using existing LTE architecture. 3GPP document S2-<NUM> discuses introduces different tunnelling methods as solutions for application/priority marking between a TDF and a P-GW in case the TDF is deployed for application detection and control.

In accordance with the present invention, there is provided a method for wireless communication as set out in claim <NUM>, a method for wireless communication as set out in claim <NUM>, an apparatus for wireless communications as set out in claim <NUM>, and an apparatus for wireless communications as set out in claim <NUM>. Other aspects of the invention can be found in the dependent claims. Any embodiment referred to and not falling within the scope of the claims is merely an example useful to the understanding of the invention.

Described herein are various aspects related to managing quality-of-service (QoS) for one or more traffic flows (also referred to herein as service data flows (SDF)) for a wireless device over a single connection with a core network. An SDF can be defined by a Traffic Flow Template (TFT) defined by the core network. A core network component, e.g. a mobility management entity (MME), can provide the TFT of a SDF and/or its associated QoS treatment parameters to the radio access network (RAN). The QoS definition may be initiated by policy and charging rules function (PCRF), a user plane gateway, a home subscriber server (HSS), etc. For example, an access point can establish one or more data radio bearers (DRB) with a wireless device based on a QoS parameter of one or more SDFs. A DRB can define over-the-air packet treatments in the RAN such that packets mapped to the same DRB can receive the same packet forwarding treatments, e.g. scheduling policy, queue management policy, rate shaping policy, radio link control (RLC) configuration, etc. A DRB may be established, released or modified by the RAN to establish QoS in over-the-air wireless communications with a user equipment (UE) or other device. The establishment or modification of a DRB can be by a radio resource control (RRC) procedure. The QoS parameter may correspond to a QoS requested for the SDF (e.g., a bit rate or other throughput parameter, etc.). An association between the Policy and Charging Control (PCC) rules and a bearer can be referred to as a bearer binding. A PCC rule is mapped to a corresponding bearer in the access network to ensure that subscriber packets receive the appropriate quality of service (QoS), charging, and gating control. The policy and charging enforcement function (PCEF) can perform the bearer binding. User (or UE) traffic (e.g., IP flows) may be classified into different SDFs having different QoS classes by a network based on the type of the service that is being provided through the SDFs. For example, service types of the SDFs may include voice services (e.g., voice over IP, Internet services, etc.). Then, the QoS rules can be applied to each SDF by the network.

In an example, the access point may not establish separate bearers with a core network for each SDF, but may manage QoS for the SDFs over the one or more DRBs with the UE (or other device). For example, the access point may determine whether, for a given SDF, a current DRB has associated QoS treatment parameters that can support the QoS parameter of the SDF or determine whether to establish a new DRB for the SDF to support the QoS parameter of the SDF. The QoS treatment parameters may correspond to the DRB configuration such as a packet data convergence protocol (PDCP) or radio link control (RLC) parameters, a maximum and/or minimum delay (or delay budget, delay requirement, etc.) of the DRB, throughput budget of the DRB (throughput budget, minimum throughput requirement, etc.), priority of the DRB, etc. used to achieve a certain QoS requirement from the core network. In this regard, for example, the access point may aggregate SDFs having the same or similar QoS parameter (e.g., a desired or required QoS) to a DRB that can support the QoS parameter. For example, the access point may include multiple TFTs in a DRB binding that bind the DRB to multiple SDFs. Thus, in an example, the access point may have a one-to-many mapping of DRBs to transport with the core network.

As used in this application, the terms "component," "module," "system" and the like are intended to include a computer-related entity, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components can communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets, such as data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal.

Furthermore, various aspects are described herein in connection with a terminal, which can be a wired terminal or a wireless terminal. A terminal can also be called a system, device, subscriber unit, subscriber station, mobile station, mobile, mobile device, remote station, remote terminal, access terminal, user terminal, terminal, communication device, user agent, user device, user equipment, or user equipment device. A wireless terminal can be a cellular telephone, a satellite phone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, a computing device, or other processing devices connected to a wireless modem. Moreover, various aspects are described herein in connection with a base station. A base station can be utilized for communicating with wireless terminal(s) and can also be referred to as an access point, access node, a Node B, evolved Node B (eNB), or some other terminology.

The techniques described herein may be used for various wireless communication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other systems. The terms "system" and "network" are often used interchangeably. A CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), cdma2000, etc. UTRA includes Wideband-CDMA (W-CDMA) and other variants of CDMA. Further, cdma2000 covers IS-<NUM>, IS-<NUM> and IS-<NUM> standards. An OFDMA system may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE <NUM> (WiFi), IEEE <NUM> (WiMAX), IEEE <NUM>, Flash-OFDM®, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). Additionally, cdma2000 and UMB are described in documents from an organization named "3rd Generation Partnership Project <NUM>" (3GPP2). Further, such wireless communication systems may additionally include peer-to-peer (e.g., mobile-to-mobile) ad hoc network systems often using unpaired unlicensed spectrums, <NUM>. xx wireless LAN (WLAN), BLUETOOTH and any other short- or long- range, wireless communication techniques.

Referring first to <FIG>, a diagram illustrates an example of a wireless communications system <NUM>, in accordance with aspects described herein. The wireless communications system <NUM> includes a plurality of access points (e.g., base stations, eNBs, or WLAN access points) <NUM>, a number of user equipment (UEs) <NUM>, and a core network <NUM>. One or more of access points <NUM> can include a DRB managing component <NUM> for managing DRBs for related SDFs of one or more UEs <NUM>. One or more of UEs <NUM> can include a communicating component <NUM> for communicating with the one or more access points <NUM> over the one or more DRBs corresponding to related SDFs with core network <NUM>. In addition, the core network <NUM> may include a flow managing component <NUM> for managing SDFs with the one or more UEs <NUM> via one or more access points <NUM>.

Some of the access points <NUM> may communicate with the UEs <NUM> under the control of a base station controller (not shown), which may be part of the core network <NUM> or the access points <NUM> (e.g., base stations or eNBs) in various examples. Access points <NUM> may communicate control information and/or user data with the core network <NUM> through backhaul links <NUM>. In examples, the access points <NUM> may communicate, either directly or indirectly, with each other over backhaul links <NUM>, which may be wired or wireless communication links. The wireless communications system <NUM> may support operation on multiple carriers (waveform signals of different frequencies). Multi-carrier transmitters can transmit modulated signals simultaneously on the multiple carriers. For example, each of communication links <NUM> may be a multi-carrier signal modulated according to the various radio technologies described above. Each modulated signal may be sent on a different carrier and may carry control information (e.g., reference signals, control channels, etc.), overhead information, data, etc..

In this regard, a UE <NUM> can be configured to communicate with one or more access points <NUM> over multiple carriers using carrier aggregation (CA) (e.g., with one access point <NUM>) and/or multiple connectivity (e.g., with multiple access points <NUM>). In either case, UE <NUM> can be configured with at least one primary cell (PCell) configured to support uplink and downlink communications between UE <NUM> and an access point <NUM>. In an example, there can be a PCell for each of communication links <NUM> between a UE <NUM> and a given access point <NUM>. In addition, each of the communication links <NUM> can have one or more secondary cells (SCell) that can support uplink and/or downlink communications as well. In some examples, the PCell can be used to communicate at least a control channel, and the SCell can be used to communicate a data channel.

The access points <NUM> may wirelessly communicate with the UEs <NUM> via one or more access point antennas. Each of the access points <NUM> sites may provide communication coverage for a respective coverage area <NUM>. In some examples, access points <NUM> may be referred to as a base transceiver station, a radio base station, a radio transceiver, a basic service set (BSS), an extended service set (ESS), a NodeB, eNodeB, Home NodeB, a Home eNodeB, or some other suitable terminology. The coverage area <NUM> for an access point may be divided into sectors making up a portion of the coverage area (not shown). The wireless communications system <NUM> may include access points <NUM> of different types (e.g., macro, micro, and/or pico base stations). The access points <NUM> may also utilize different radio technologies, such as cellular and/or WLAN radio access technologies (RAT). The access points <NUM> may be associated with the same or different access networks or operator deployments. The coverage areas <NUM> of different access points <NUM>, including the coverage areas of the same or different types of access points <NUM>, utilizing the same or different radio access technologies, and/or belonging to the same or different access networks, may overlap.

In LTE/LTE-A network communication systems, the terms evolved Node B (eNodeB or eNB) may be generally used to describe the access points <NUM>. The wireless communications system <NUM> may be a Heterogeneous LTE/LTE-A network in which different types of access points <NUM> provide coverage for various geographical regions. For example, each access point <NUM> may provide communication coverage for a macro cell, a pico cell, a femto cell, and/or other types of cell. Small cells such as pico cells, femto cells, and/or other types of cells may include low power nodes or LPNs. A macro cell may covers a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by UEs <NUM> with service subscriptions with the network provider. A small cell may cover a relatively smaller geographic area and may allow unrestricted access by UEs <NUM> with service subscriptions with the network provider, for example, and in addition to unrestricted access, may also provide restricted access by UEs <NUM> having an association with the small cell (e.g., UEs in a closed subscriber group (CSG), UEs for users in the home, and the like). An eNB for a small cell may be referred to as a small cell eNB. An eNB may support one or multiple (e.g., two, three, four, and the like) cells. The term eNB, as used generally herein, may relate to a macro eNB and/or a small cell eNB.

In an example, a small cell may operate in an "unlicensed" frequency band or spectrum, which can refer to a portion of radio frequency (RF) space that is not licensed for use by one or more wireless wide area network (WWAN) technologies, but may or may not be used by other communication technologies (e.g., wireless local area network (WLAN) technologies, such as Wi-Fi). Moreover, a network or device that provides, adapts, or extends its operations for use in an "unlicensed" frequency band or spectrum may refer to a network or device that is configured to operate in a contention-based radio frequency band or spectrum. In addition, for illustration purposes, the description below may refer in some respects to an LTE system operating on an unlicensed band by way of example when appropriate, although such descriptions are not intended to exclude other cellular communication technologies. LTE on an unlicensed band may also be referred to herein as LTE / LTE-Advanced in unlicensed spectrum, or simply LTE, in the surrounding context.

The core network <NUM> may communicate with the eNBs or other access points <NUM> via a backhaul links <NUM> (e.g., S1 interface, etc.). The access points <NUM> may also communicate with one another, e.g., directly or indirectly via backhaul links <NUM> (e.g., X2 interface, etc.) and/or via backhaul links <NUM> (e.g., through core network <NUM>). The wireless communications system <NUM> may support synchronous or asynchronous operation. For synchronous operation, the access points <NUM> may have similar frame timing, and transmissions from different access points <NUM> may be approximately aligned in time. For asynchronous operation, the access points <NUM> may have different frame timing, and transmissions from different access points <NUM> may not be aligned in time. Furthermore, transmissions in the first hierarchical layer and second hierarchical layer may or may not be synchronized among access points <NUM>.

The UEs <NUM> are dispersed throughout the wireless communications system <NUM>, and each UE <NUM> may be stationary or mobile. A UE <NUM> may also be referred to by those skilled in the art as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology. A UE <NUM> may be a cellular phone, a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a tablet computer, a laptop computer, a cordless phone, a wearable item such as a watch or glasses, a wireless local loop (WLL) station, or the like. A UE <NUM> may be able to communicate with macro eNodeBs, small cell eNodeBs, relays, and the like. A UE <NUM> may also be able to communicate over different access networks, such as cellular or other WWAN access networks, or WLAN access networks.

The communication links <NUM> shown in wireless communications system <NUM> may include uplink (UL) transmissions from a UE <NUM> to an access point <NUM>, and/or downlink (DL) transmissions, from an access point <NUM> to a UE <NUM>. The downlink transmissions may also be called forward link transmissions while the uplink transmissions may also be called reverse link transmissions. The communication links <NUM> may carry transmissions of each hierarchical layer which, in some examples, may be multiplexed in the communication links <NUM>. The UEs <NUM> may be configured to collaboratively communicate with multiple access points <NUM> through, for example, Multiple Input Multiple Output (MIMO), carrier aggregation (CA), Coordinated MultiPoint (CoMP), multiple connectivity (e.g., CA with each of one or more access points <NUM>) or other schemes. MIMO techniques use multiple antennas on the access points <NUM> and/or multiple antennas on the UEs <NUM> to transmit multiple data streams. Carrier aggregation may utilize two or more component carriers on a same or different serving cell for data transmission. CoMP may include techniques for coordination of transmission and reception by a number of access points <NUM> to improve overall transmission quality for UEs <NUM> as well as increasing network and spectrum utilization.

As mentioned, in some examples access points <NUM> and UEs <NUM> may utilize carrier aggregation to transmit on multiple carriers. In some examples, access points <NUM> and UEs <NUM> may concurrently transmit in a first hierarchical layer, within a frame, one or more subframes each having a first subframe type using two or more separate carriers. Each carrier may have a bandwidth of, for example, <NUM>, although other bandwidths may be utilized. For example, if four separate <NUM> carriers are used in a carrier aggregation scheme in the first hierarchical layer, a single <NUM> carrier may be used in the second hierarchical layer. The <NUM> carrier may occupy a portion of the radio frequency spectrum that at least partially overlaps the radio frequency spectrum used by one or more of the four <NUM> carriers. In some examples, scalable bandwidth for the second hierarchical layer type may be combined techniques to provide shorter RTTs such as described above, to provide further enhanced data rates.

Each of the different operating modes that may be employed by wireless communications system <NUM> may operate according to frequency division duplexing (FDD) or time division duplexing (TDD). In some examples, different hierarchical layers may operate according to different TDD or FDD modes. For example, a first hierarchical layer may operate according to FDD while a second hierarchical layer may operate according to TDD. In some examples, OFDMA communications signals may be used in the communication links <NUM> for LTE downlink transmissions for each hierarchical layer, while single carrier frequency division multiple access (SC-FDMA) communications signals may be used in the communication links <NUM> for LTE uplink transmissions in each hierarchical layer.

<FIG> is a diagram illustrating an example of an access network <NUM> in an LTE network architecture. In this example, the access network <NUM> is divided into a number of cellular regions (cells) <NUM>. One or more small cell eNBs <NUM> may have cellular regions <NUM> that overlap with one or more of the cells <NUM>. The small cell eNBs <NUM> may be of a lower power class (e.g., home eNB (HeNB)), femto cell pico cell, micro cell, or remote radio head (RRH). The macro eNBs <NUM> are each assigned to a respective cell <NUM> and are configured to provide an access point to the core network <NUM> for all the UEs <NUM> in the cells <NUM>. In an aspect, one or more of eNBs <NUM>, small cell eNBs <NUM>, etc. can include a DRB managing component <NUM> for managing DRBs with one or more UEs for related SDFs in the core network. One or more of UEs <NUM> can include a communicating component <NUM> for communicating with the one or more eNBs <NUM>/<NUM> over the one or more DRB corresponding to related SDFs with a core network. There is no centralized controller shown in this example of an access network <NUM>, but a centralized controller may be used in alternative configurations. The eNBs <NUM>/<NUM> can be responsible for all radio related functions including radio bearer control, admission control, mobility control, scheduling, security, and connectivity to a serving gateway.

The modulation and multiple access scheme employed by the access network <NUM> may vary depending on the particular telecommunications standard being deployed. In LTE applications, OFDM may be used on the DL and SC-FDMA may be used on the UL to support both frequency division duplexing (FDD) and time division duplexing (TDD). As those skilled in the art will readily appreciate from the detailed description to follow, the various concepts presented herein are well suited for LTE applications. However, these concepts may be readily extended to other telecommunication standards employing other modulation and multiple access techniques. By way of example, these concepts may be extended to Evolution-Data Optimized (EV-DO) or Ultra Mobile Broadband (UMB). EV-DO and UMB are air interface standards promulgated by the 3rd Generation Partnership Project <NUM> (3GPP2) as part of the CDMA2000 family of standards and employs CDMA to provide broadband Internet access to mobile stations. These concepts may also be extended to Universal Terrestrial Radio Access (UTRA) employing Wideband-CDMA (W-CDMA) and other variants of CDMA, such as TD-SCDMA; Global System for Mobile Communications (GSM) employing TDMA; and Evolved UTRA (E-UTRA), IEEE <NUM> (Wi-Fi), IEEE <NUM> (WiMAX), IEEE <NUM>, and Flash-OFDM employing OFDMA. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from the 3GPP organization. CDMA2000 and UMB are described in documents from the 3GPP2 organization. The actual wireless communication standard and the multiple access technology employed will depend on the specific application and the overall design constraints imposed on the system.

The eNBs <NUM> may have multiple antennas supporting MIMO technology. The use of MIMO technology enables the eNBs <NUM> to exploit the spatial domain to support spatial multiplexing, beamforming, and transmit diversity. Spatial multiplexing may be used to transmit different streams of data simultaneously on the same frequency. The data steams may be transmitted to a single UE <NUM> to increase the data rate or to multiple UEs <NUM> to increase the overall system capacity. This is achieved by spatially precoding each data stream (i.e., applying a scaling of an amplitude and a phase) and then transmitting each spatially precoded stream through multiple transmit antennas on the DL. The spatially precoded data streams arrive at the UE(s) <NUM> with different spatial signatures, which enables each of the UE(s) <NUM> to recover the one or more data streams destined for that UE <NUM>. On the UL, each UE <NUM> transmits a spatially precoded data stream, which enables the eNB <NUM> to identify the source of each spatially precoded data stream.

Spatial multiplexing is generally used when channel conditions are good (e.g., when one or more measured channel condition parameters achieve one or more thresholds). When channel conditions are less favorable (e.g., when one or more measured channel condition parameters do not achieve one or more thresholds), beamforming may be used to focus the transmission energy in one or more directions. This may be achieved by spatially precoding the data for transmission through multiple antennas. To achieve good coverage at the edges of the cell, a single stream beamforming transmission may be used in combination with transmit diversity.

In the detailed description that follows, various aspects of an access network will be described with reference to a MIMO system supporting OFDM on the DL. OFDM is a spread-spectrum technique that modulates data over a number of subcarriers within an OFDM symbol. The subcarriers are spaced apart at precise frequencies. The spacing provides "orthogonality" that enables a receiver to recover the data from the subcarriers. In the time domain, a guard interval (e.g., cyclic prefix) may be added to each OFDM symbol to combat inter-OFDM-symbol interference. The UL may use SC-FDMA in the form of a DFT-spread OFDM signal to compensate for high peak-to-average power ratio (PAPR).

<FIG> is a block diagram of an eNB <NUM> in communication with a UE <NUM> in an access network. In the DL, upper layer packets from the core network are provided to a controller/processor <NUM>. The controller/processor <NUM> implements the functionality of the L2 layer. In the DL, the controller/processor <NUM> provides header compression, ciphering, packet segmentation and reordering, multiplexing between logical and transport channels, and radio resource allocations to the UE <NUM> based on various priority metrics. The controller/processor <NUM> is also responsible for hybrid automatic repeat/request (HARQ) operations, retransmission of lost packets, and signaling to the UE <NUM>.

The transmit (TX) processor <NUM> implements various signal processing functions for the L1 layer (i.e., physical layer). The signal processing functions includes coding and interleaving to facilitate forward error correction (FEC) at the UE <NUM> and mapping to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols are then split into parallel streams. Each stream is then mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and/or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. Each spatial stream is then provided to a different antenna <NUM> via a separate transmitter 318TX. Each transmitter 318TX modulates an RF carrier with a respective spatial stream for transmission. eNB <NUM> can include a DRB managing component <NUM> for managing DRBs for related SDFs of one or more UEs <NUM>. Though DRB managing component <NUM> is shown as coupled to controller/processor <NUM>, in an example DRB managing component <NUM> can also be coupled to other processors (e.g., TX processor <NUM>, RX processor <NUM>, etc.) and/or implemented by the one or more processors <NUM>, <NUM>, <NUM> to perform actions described herein.

The RX processor <NUM> implements various signal processing functions of the L1 layer. The RX processor <NUM> performs spatial processing on the information to recover any spatial streams destined for the UE <NUM>. The symbols on each subcarrier, and the reference signal, is recovered and demodulated by determining the most likely signal constellation points transmitted by the eNB <NUM>. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the eNB <NUM> on the physical channel. The data and control signals are then provided to the controller/processor <NUM>.

The controller/processor <NUM> implements the L2 layer. The controller/processor can be associated with a memory <NUM> that stores program codes and data. In the UL, the controller/processor <NUM> provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover upper layer packets from the core network. The upper layer packets are then provided to a data sink <NUM>, which represents all the protocol layers above the L2 layer. Various control signals may also be provided to the data sink <NUM> for L3 processing. The controller/processor <NUM> is also responsible for error detection using an acknowledgement (ACK) and/or negative acknowledgement (NACK) protocol to support HARQ operations. In addition, UE <NUM> may include a communicating component <NUM> for communicating with the one or more eNBs <NUM> over the one or more DRB corresponding to related SDFs with a core network. Though communicating component <NUM> is shown as coupled to controller/processor <NUM>, in an example communicating component <NUM> can also be coupled to other processors (e.g., RX processor <NUM>, TX processor <NUM>, etc.) and/or implemented by the one or more processors <NUM>, <NUM>, <NUM> to perform actions described herein.

In the UL, a data source <NUM> is used to provide upper layer packets to the controller/processor <NUM>. The data source <NUM> represents all protocol layers above the L2 layer. Similar to the functionality described in connection with the DL transmission by the eNB <NUM>, the controller/processor <NUM> implements the L2 layer for the user plane and the control plane by providing header compression, ciphering, packet segmentation and reordering, and multiplexing between logical and transport channels based on radio resource allocations by the eNB <NUM>. The controller/processor <NUM> is also responsible for HARQ operations, retransmission of lost packets, and signaling to the eNB <NUM>.

Channel estimates derived by a channel estimator <NUM> from a reference signal or feedback transmitted by the eNB <NUM> may be used by the TX processor <NUM> to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor <NUM> are provided to different antenna <NUM> via separate transmitters 354TX. Each transmitter 354TX modulates an RF carrier with a respective spatial stream for transmission.

The UL transmission is processed at the eNB <NUM> in a manner similar to that described in connection with the receiver function at the UE <NUM>. The RX processor <NUM> may implement the L1 layer.

The controller/processor <NUM> implements the L2 layer. In the UL, the controller/processor <NUM> provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover upper layer packets from the UE <NUM>. Upper layer packets from the controller/processor <NUM> may be provided to the core network.

In future wireless communications technology, such as <NUM>, the core network may do away from the end-to-end QoS bearer model due to various reasons. For example, it may be desired to reduce the QoS bearer set-up delay for short-lived QoS sessions. In practice, the core network paths may be over-provisioned and thus the bottleneck of QoS may reside in the air interface. In addition, the potential use of software-defined networking solution for routing path/tunneling control leads to the desire of a flat routing, bearerless model in core network. While the core network adopts a bearerless model, data radio bearer (DRB) support in RAN may still be desired or required. The RLC and MAC scheduling configurations may be differentiated in order to support certain QoS requirements, e.g. reliability and delay. In a bearerless core network model, the responsibility of associating the flows with various QoS to a DRB may be in RAN. Described below are examples of RAN QoS handling.

Turning now to <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and<FIG>, aspects are depicted with reference to one or more components and one or more methods that may perform the actions or operations described herein, where aspects in dashed line may be optional. Although the operations described below in <FIG> are presented in a particular order and/or as being performed by an example component, it should be understood that the ordering of the actions and the components performing the actions may be varied, depending on the implementation. Moreover, it should be understood that the following actions, functions, and/or described components may be performed by a specially-programmed processor, a processor executing specially-programmed software or computer-readable media, or by any other combination of a hardware component and/or a software component capable of performing the described actions or functions.

<FIG> and <FIG> depict an example of a system <NUM> for managing DRBs in accordance with aspects described herein. System <NUM> includes a UE <NUM> that communicates with an access point <NUM> to access a wireless network, such as network component <NUM>, examples of which are described in <FIG> above (e.g., UEs <NUM>, <NUM>, <NUM>, access points/eNBs <NUM>, <NUM>, <NUM>, <NUM>, etc., core network <NUM>, etc.). In an aspect, access point <NUM> and UE <NUM> may have established one or more downlink channels over which downlink signals <NUM> can be transmitted by access point <NUM> (e.g., via access point transceiver <NUM>) and received by UE <NUM> (e.g., via UE transceiver <NUM>) for communicating control and/or data messages (e.g., signaling) from the access point <NUM> to the UE <NUM> over configured communication resources. Moreover, for example, access point <NUM> and UE <NUM> may have established one or more uplink channels over which uplink signals <NUM> can be transmitted by UE <NUM> (e.g., via UE transceiver <NUM>) and received by access point <NUM> (e.g., via access point transceiver <NUM>) for communicating control and/or data messages (e.g., signaling) from the UE <NUM> to the access point <NUM> over configured communication resources. For example, access point <NUM> and UE <NUM> may establish a bearer <NUM> over which the downlink signals <NUM> and/or uplink signals <NUM> may be communicated. In an example, as described further here, access point <NUM> and UE <NUM> may establish multiple bearers <NUM> for communicating, where each bearer <NUM> can correspond to a QoS, and may be bound to multiple SDFs.

In an aspect, UE <NUM> may include one or more processors <NUM> and/or a memory <NUM> that may be communicatively coupled, e.g., via one or more buses <NUM>, and may operate in conjunction with or otherwise implement a communicating component <NUM> for communicating with one or more access points <NUM> over one or more DRBs bound to one or more SDFs. For example, the various operations related to the communicating component <NUM> may be implemented or otherwise executed by one or more processors <NUM> and, in an aspect, can be executed by a single processor, while in other aspects, different ones of the operations may be executed by a combination of two or more different processors. For example, in an aspect, the one or more processors <NUM> may include any one or any combination of a modem processor, or a baseband processor, or a digital signal processor, or an application specific integrated circuit (ASIC), or a transmit processor, or a transceiver processor associated with UE transceiver <NUM>. Further, for example, the memory <NUM> may be a non-transitory computer-readable medium that includes, but is not limited to, random access memory (RAM), read only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), a magnetic storage device (e.g., hard disk, floppy disk, magnetic strip), an optical disk (e.g., compact disk (CD), digital versatile disk (DVD)), a smart card, a flash memory device (e.g., card, stick, key drive), a register, a removable disk, and any other suitable medium for storing software and/or computer-readable code or instructions that may be accessed and read by a computer or one or more processors <NUM>. Moreover, memory <NUM> or computer-readable storage medium may be resident in the one or more processors <NUM>, external to the one or more processors <NUM>, distributed across multiple entities including the one or more processors <NUM>, etc..

In particular, the one or more processors <NUM> and/or memory <NUM> may execute actions or operations defined by communicating component <NUM> or its subcomponents. For instance, the one or more processors <NUM> and/or memory <NUM> may execute actions or operations defined by a DRB establishing component <NUM> for establishing one or more DRBs between UE <NUM> and access point <NUM>. In an aspect, for example, DRB establishing component <NUM> may include hardware (e.g., one or more processor modules of the one or more processors <NUM>) and/or computer-readable code or instructions stored in memory <NUM> and executable by at least one of the one or more processors <NUM> to perform the specially configured DRB establishing operations described herein. Further, for instance, the one or more processors <NUM> and/or memory <NUM> may execute actions or operations defined by a DRB binding component <NUM> for binding the one or more DRBs to one or more SDFs to facilitate providing a QoS for the SDF(s). In an aspect, for example, DRB binding component <NUM> may include hardware (e.g., one or more processor modules of the one or more processors <NUM>) and/or computer-readable code or instructions stored in memory <NUM> and executable by at least one of the one or more processors <NUM> to perform the specially configured binding operations described herein.

Similarly, in an aspect, access point <NUM> may include one or more processors <NUM> and/or a memory <NUM> that may be communicatively coupled, e.g., via one or more buses <NUM>, and may operate in conjunction with or otherwise implement a DRB managing component <NUM> for managing one or more DRBs for one or more UEs <NUM> to provide QoS for one or more SDFs. For example, the various functions related to DRB managing component <NUM> may be implemented or otherwise executed by one or more processors <NUM> and, in an aspect, can be executed by a single processor, while in other aspects, different ones of the functions may be executed by a combination of two or more different processors, as described above. In one example, the one or more processors <NUM> and/or memory <NUM> may be configured as described in examples above with respect to the one or more processors <NUM> and/or memory <NUM> of UE <NUM>.

In an example, the one or more processors <NUM> and/or memory <NUM> may execute actions or operations defined by DRB managing component <NUM> or its subcomponents. For instance, the one or more processors <NUM> and/or memory <NUM> may execute actions or operations defined by a DRB establishing component <NUM> for establishing one or more DRBs with a UE. In an aspect, for example, DRB establishing component <NUM> may include hardware (e.g., one or more processor modules of the one or more processors <NUM>) and/or computer-readable code or instructions stored in memory <NUM> and executable by at least one of the one or more processors <NUM> to perform the specially configured DRB establishing operations described herein. Further, for instance, the one or more processors <NUM> and/or memory <NUM> may execute actions or operations defined by a DRB binding component <NUM> for binding the one or more DRBs to one or more SDFs. In an aspect, for example, DRB binding component <NUM> may include hardware (e.g., one or more processor modules of the one or more processors <NUM>) and/or computer-readable code or instructions stored in memory <NUM> and executable by at least one of the one or more processors <NUM> to perform the specially configured DRB binding operations described herein.

In an example, transceivers <NUM>, <NUM> may be configured to transmit and receive wireless signals through one or more antennas <NUM>, <NUM> and may generate or process the signals using one or more RF front end components (e.g., power amplifiers, low noise amplifiers, filters, analog-to-digital converters, digital-to-analog converters, etc.), one or more transmitters, one or more receivers, etc. In an aspect, transceivers <NUM>, <NUM> may be tuned to operate at specified frequencies such that UE <NUM> and/or access point <NUM> can communicate at a certain frequency. In an aspect, the one or more processors <NUM>, <NUM> may configure transceivers <NUM>, <NUM> to operate at a specified frequency and power level based on a configuration, a communication protocol, etc..

In an aspect, transceivers <NUM>, <NUM> can operate in multiple bands (e.g., using a multiband-multimode modem, not shown) such to process digital data sent and received using transceivers <NUM>, <NUM>. In an aspect, transceivers <NUM>, <NUM> can be multiband and be configured to support multiple frequency bands for a specific communications protocol. In an aspect, transceivers <NUM>, <NUM> can be configured to support multiple operating networks and communications protocols. Thus, for example, transceivers <NUM>, <NUM> may enable transmission and/or reception of signals based on a specified modem configuration.

In addition, for example, network component <NUM> can be or can include one or more components of a core network, such as core network <NUM>. For example, network component <NUM> can be or can include a mobility management entity (MME) for establishing SDFs with one or more UEs via one or more access points. As shown in <FIG>, network component <NUM> may include one or more processors <NUM> and/or a memory <NUM> that may be communicatively coupled, e.g., via one or more buses <NUM>, and may operate in conjunction with or otherwise implement a flow managing component <NUM> for managing one or more SDFs for one or more UEs <NUM> to provide QoS for one or more SDFs. For example, the various functions related to flow managing component <NUM> may be implemented or otherwise executed by one or more processors <NUM> and, in an aspect, can be executed by a single processor, while in other aspects, different ones of the functions may be executed by a combination of two or more different processors, as described above. In one example, the one or more processors <NUM> and/or memory <NUM> may be configured as described in examples above with respect to the one or more processors <NUM> and/or memory <NUM> of UE <NUM>.

In an example, the one or more processors <NUM> and/or memory <NUM> may execute actions or operations defined by flow managing component <NUM> or its subcomponents. For instance, the one or more processors <NUM> and/or memory <NUM> may execute actions or operations defined by a QoS component <NUM> for specifying one or more QoS parameters for a SDF. In an aspect, for example, QoS component <NUM> may include hardware (e.g., one or more processor modules of the one or more processors <NUM>) and/or computer-readable code or instructions stored in memory <NUM> and executable by at least one of the one or more processors <NUM> to perform the specially configured QoS operations described herein. Further, for instance, the one or more processors <NUM> and/or memory <NUM> may optionally execute actions or operations defined by a DRB requesting component <NUM> for requesting establishing of a DRB for providing QoS for a SDF. In an aspect, for example, DRB requesting component <NUM> may include hardware (e.g., one or more processor modules of the one or more processors <NUM>) and/or computer-readable code or instructions stored in memory <NUM> and executable by at least one of the one or more processors <NUM> to perform the specially configured DRB requesting operations described herein.

Network component <NUM> may also include a communications component <NUM> that may be coupled to one or more processors <NUM> and/or memory <NUM> via one or more buses <NUM>. Communications component <NUM> may enable communication internally among components of network component <NUM>, and/or may include one or more interfaces that enable communication with external devices, such as other components of the core network (e.g., one or more gateways, HSS, etc.), access point <NUM>, etc. As such, communications component <NUM> can be configured to establish and maintain communications with one or more entities utilizing hardware, software, and/or services as described herein. In an aspect, for example with respect to external communications, communications component <NUM> may further include transmit chain components (e.g., protocol layer entities, processor(s), modulator(s), antenna) and receive chain components (e.g., protocol layer entities, processor(s), demodulator(s), antenna) associated with one or more transmitters and receivers, respectively, or one or more transceivers, operable for interfacing with external devices over a wired or wireless connection (similar to transceivers <NUM>, <NUM>). In one example, communications component <NUM> may include a network interface card that includes one or more wired or wireless interfaces for coupling to one or more networks (e.g., local area networks, wide area networks, etc.).

As described, UE <NUM> can have one or more DRBs with access point <NUM> to manage one or more SDFs, where access point <NUM> has a single bearerless transport with the core network. An example is depicted in <FIG>, which illustrates an example of a system <NUM> for wireless communication. <FIG> depicts a UE <NUM> that communicates with an eNB <NUM> to receive access to one or more core network components, which may include a serving gateway (SGW) <NUM>, packet data network (PDN) gateway (PGW) <NUM>, backend PDN <NUM>, etc. UE <NUM> may establish one or more DRBs <NUM> with the eNB <NUM>, where each DRB <NUM> may have one or more associated SDFs <NUM>. SDFs <NUM> may be associated with DRBs <NUM> based on a QoS for the SDFs <NUM> (e.g., based on determining that the DRB <NUM> has one or more associated QoS treatment parameters that can support one or more QoS parameters of the SDF <NUM>). eNB <NUM> has a bearerless transport <NUM> with the SGW <NUM>/PGW <NUM> and/or other core network components. In this regard, eNB <NUM> can manage QoS for the SDFs <NUM> (e.g., based at least in part on establishing DRBs <NUM> that can provide QoS for the SDFs <NUM>), as described further herein.

Referring to <FIG>, an example of a method <NUM> is illustrated for communicating (e.g., by a UE) data related to one or more SDFs over one or more DRBs with an access point. In method <NUM>, blocks indicated as dashed boxes can represent optional steps.

In an example, method <NUM> includes, at Block <NUM>, receiving an indication of a binding between a SDF and a DRB. In an aspect, communicating component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or UE transceiver <NUM>, may receive the indication of the binding between the SDF and the DRB. For example, DRB establishing component <NUM> may establish one or more DRBs with the access point <NUM>. In one example, DRB establishing component <NUM> may establish a DRB with the access point <NUM> as part of initiating communications therewith (e.g., based on performing a random access procedure therewith) to receive access to a network component <NUM>. In another example, DRB establishing component <NUM> may establish one or more other DRBs with the access point <NUM> (e.g., to provide QoS for one or more SDFs), as described further herein. In an example, the indication of the binding between the SDF and the DRB may correspond to one or more of the DRBs established with the access point <NUM> and/or a new DRB for establishing with the access point <NUM>. Moreover, for example, the indication can be received as part of establishing a new SDF and/or updating QoS parameters for an existing SDF. For example, the indication may include a parameter value in a message from the access point <NUM> that indicates the existence of the binding. In an example, the message may include an RRC message or other message from the access point <NUM>. In addition, in an example, the indication may include a value in a TFT received from the access point <NUM>.

Method <NUM> also includes, at Block <NUM>, determining the DRB for binding to the SDF as either an existing DRB that supports one or more QoS parameters of the SDF, or a new DRB to support one or more QoS parameters of the SDF. In an aspect, DRB binding component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or UE transceiver <NUM>, may determine the DRB for binding to the SDF as one of an existing DRB that supports one or more QoS parameters of the SDF or a new DRB. In an example, DRB binding component <NUM> may determine this based on a binding or other information/indication (e.g., a TFT) received from the access point <NUM> that specifies the SDF to DRB binding. In an example, where a TFT is received from the access point <NUM>, the TFT may include one or more of a source internet protocol (IP) address, a destination IP address, a UE identifier, a source port number, a destination port number, a source media access control (MAC) address, a destination MAC address, etc. Moreover, for example, the TFT can include an uplink TFT that binds SDFs to DRBs on the uplink at the UE <NUM>, a downlink TFT that binds SDFs to DRBs on the downlink at the access point <NUM>, etc. In an example, DRB binding component <NUM> can accordingly receive the TFT information and bind the associated SDF (e.g., the SDF associated with the source IP, destination IP, UE identifier, source port number, destination port number, etc.) to the DRB. For example, DRB binding component <NUM> can bind the SDF to the DRB by associating the SDF to the DRB such that communications associated with the SDF are communicated with the access point <NUM> over the DRB. For example, UE <NUM> can transmit communications associated with the SDF over the DRB based on the binding, and can receive communications associated with the SDF over the DRB.

Moreover, for example, communicating component <NUM> can receive at least one of an indication of quality-of-service (QoS) treatment parameters configured for the DRB, a data network session identifier, an identifier of the DRB from the access point <NUM>, etc. In this example, communicating component <NUM> may classify the packet as related to the DRB based at least in part on at least one of the QoS treatment parameters configured for the DRB (e.g., based on determining whether the DRB can support QoS parameters of the SDF to which the packet relates) the data network session identifier (e.g., where the session identifier is associated with the DRB), or the identifier of the data radio bearer. In another example, DRB binding component <NUM> may determine the binding of a SDF to the DRB based on determining whether an existing DRB can support a QoS parameter of the SDF or whether a new DRB can be established to support the QoS parameter of the SDF.

Method <NUM> also includes, at Block <NUM>, modifying an existing DRB or establishing the new DRB based on the determination. In an aspect, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or UE transceiver <NUM>, DRB binding component <NUM> can modify an existing DRB or DRB establishing component <NUM> with access point <NUM> can establish the new DRB based on the determination. For example, where DRB binding component <NUM> determines the DRB as the existing DRB that supports a QoS parameter of the SDF, DRB binding component <NUM> can modify the DRB binding to associate the SDF along with other SDFs associated with the DRB. In another example, DRB binding component <NUM> can request update of the DRB to support the QoS parameter of the SDF.

In an example, modifying the existing DRB at Block <NUM> may optionally include, at Block <NUM>, requesting a QoS parameter change for the SDF. For example, DRB binding component <NUM> can request the QoS parameter (e.g., for an existing DRB) be changed for the SDF. Thus, for example, DRB binding component <NUM> may request an increase in QoS for the SDF from access point <NUM>, which may cause access point <NUM> to determine whether one or more existing DRBs can support the requested change in QoS parameter (e.g., whether a bit rate of the DRB, maximum and/or minimum delay of the DRB, a change in priority of the DRB, etc. can satisfy the updated QoS parameter), and accordingly update an existing DRB binding to include the SDF, establish a new DRB to handle the updated QoS parameter, reject the request, etc., as described further herein.

For example, DRB binding component <NUM> can request QoS parameter change for the SDF from access point <NUM> using access stratum (AS) signaling to the access point <NUM> (e.g., via radio resource control (RRC) message). In another example, DRB binding component <NUM> can request QoS parameter change for the SDF from network component <NUM> using non-AS (NAS) signaling via access point <NUM> to network component <NUM>. In one example, DRB binding component <NUM> can request the QoS parameter change using AS signaling for existing SDFs and using NAS signaling for new SDFs.

In addition, for example, DRB binding component <NUM> can receive a response to the request for QoS parameter change from the access point <NUM>, which may indicate success or failure of the parameter change, an indication to establish a new DRB to support the new QoS treatment parameter, etc. In one example, where DRB binding component <NUM> receives a success or acceptance of the QoS parameter change from access point <NUM>, the response from the access point <NUM> may indicate establishment of the new DRB and/or mapping of the associated SDF to an existing DRB (e.g., where the new DRB parameters and/or existing DRB parameters may be indicated in the response). In another example, where DRB binding component <NUM> receives a failure of the parameter change from the access point <NUM> over AS signaling, DRB binding component <NUM> may then request the parameter change via NAS signaling (e.g., from network component <NUM>). The selection of AS or NAS signaling may additionally be based on prior configuration or UE <NUM>/access point <NUM> capability (e.g. advertised by access point <NUM>), where the configuration may be related to the type of SDF, a data network session type, delay requirement, etc..

In another example, where DRB binding component <NUM> determines the DRB as a new DRB, DRB establishing component <NUM> can establish the new DRB with the access point <NUM>, and can bind the new DRB to the SDF. In an example, DRB establishing component <NUM> can establish the new DRB as one of a UE-initiated establishment (e.g., based on determining to establish a new DRB for a SDF where existing DRBs may not support QoS parameters of the SDF) or in response to a request from access point <NUM> to establish the new DRB (e.g., where the access point <NUM> determines existing DRBs to not support the QoS parameters of the SDF), etc. In one example, DRB binding component <NUM> can receive a list of DRBs from the access point <NUM>, where the list may indicate one or more DRBs and/or one or more flow identifiers (e.g., of one or more SDFs) to be associated with each of the one or more DRBs. The DRB binding component <NUM> can accordingly establish new DRBs, and/or modify existing DRBs (e.g., to associate or disassociate one or more SDFs with the existing DRBs) with the access point <NUM> based on the list of DRBs. In an example, the list of DRBs may also include other DRB-specific parameters, such as PDCP and/or RLC configuration information, a logical channel identifier or configuration, etc..

Method <NUM> may also include, at Block <NUM>, transmitting, based on the binding, a packet using the DRB based at least in part on classifying the packet as related to the SDF. In an aspect, communicating component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or UE transceiver <NUM>, may transmit, based on the binding (e.g., and to the access point <NUM>), the packet using the DRB based at least in part on classifying the packet as related to the SDF. For example, communicating component <NUM> can receive packets for communicating to the access point <NUM>, where the packets correspond to a SDF (e.g., based on an application at the UE <NUM> that establishes the SDF with the network component <NUM>. The packets may include one or more parameters related to the SDF, such as a source IP, destination IP, SDF or other flow/routing identifier, etc., and communicating component <NUM> classifies packets as associated with the SDF based on the one or more parameters. Accordingly, communicating component <NUM> can transmit a packet classified as relating to an SDF over an associated DRB.

Referring to <FIG>, an example of a method <NUM> is illustrated for managing (e.g., by an eNB) one or more DRBs to provide QoS for one or more SDFs. In method <NUM>, blocks indicated as dashed boxes can represent optional steps.

In an example, method <NUM> optionally includes, at Block <NUM>, receiving an indication of a SDF. In an aspect, DRB managing component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or access point transceiver <NUM>, may receive the indication of the SDF. For example, DRB managing component <NUM> can receive the indication of the SDF from the network component <NUM>. In this example, UE <NUM> can establish the SDF with network component <NUM> via access point <NUM>, and DRB managing component <NUM> can receive the indication of the SDF as part of the establishment. The indication, for example, may include a SDF description that indicates one or more parameters regarding the SDF, such as the one or more QoS parameters, an identifier or label of the SDF, etc. In another example, DRB managing component <NUM> can receive the indication of the SDF from the UE <NUM> as part of a request for QoS treatment parameter modification, as described further herein.

Method <NUM> includes, at Block <NUM>, determining a DRB for binding to the SDF as one of an existing DRB that supports one or more QoS parameters of the SDF or a new DRB that supports one or more QoS parameters of the SDF if no existing DRB does. In an aspect, DRB binding component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or access point transceiver <NUM>, can determine the DRB for binding to the SDF as one of the existing DRB that supports one or more QoS parameters of the SDF or the new DRB. For example, DRB binding component <NUM> may receive one or more QoS parameters regarding the SDF, such as a desired QoS for the SDF, which can be indicated by the network component <NUM> to access point <NUM> in establishing the SDF, from the UE <NUM> based on establishing the SDF, etc. For example, DRB binding component <NUM> can determine whether one or more DRBs between access point <NUM> and UE <NUM> can support the QoS parameter of the SDF.

In one example, each of the one or more DRBs can have associated QoS treatment parameters, and DRB binding component <NUM> can determine whether the QoS treatment parameters (e.g., one or more of a bit rate, delay, priority, etc.) can support the QoS for the SDF. For example, DRB binding component <NUM> can determine whether the QoS treatment parameters of the DRB are sufficient to satisfy a QoS parameter of the SDF (e.g., a desired or required QoS for a related service). The QoS treatment parameters of the DRB may include a configuration of the DRB, a current load of the RAN (e.g., a number of UEs communicating with the RAN, a number or capacity of resources of the RAN that are being utilized by UEs, etc.), a channel condition of the UE <NUM> (e.g., received signal strength indicator (RSSI), reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-noise ratio (SNR), interference over thermal (IoT), etc.), available resources in transmission and reception points of the RAN, etc. If the QoS treatment parameters of one or more of the existing DRBs are sufficient to satisfy the QoS parameter of the SDF, DRB binding component <NUM> can bind the SDF to the corresponding DRB for communicating data of the SDF over the DRB. If DRB binding component <NUM> determines that no existing DRBs can support the QoS parameter of the SDF, in an example, DRB establishing component <NUM> can establish a new DRB with the UE <NUM>.

For example, method <NUM> may optionally include, at Block <NUM>, establishing the new DRB. In an aspect, DRB establishing component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or access point transceiver <NUM>, can establish the new DRB (e.g., with UE <NUM>) where the DRB binding component <NUM> determines to establish the new DRB, and DRB binding component <NUM> can accordingly determine the binding between the SDF and the new DRB. For example, DRB binding component <NUM> can establish the new DRB with the UE <NUM> using RRC signaling to establish the new DRB. In addition, for example, DRB binding component <NUM> can establish the new DRB with the UE <NUM> with parameters (e.g., a certain bit rate or other throughput parameter, etc.) for achieving a corresponding QoS. As described, the access point <NUM> can manage communications from the new DRB and existing DRBs over a connection with the network component <NUM>, which may be a single bearerless connection per UE, a single connection for multiple UEs, etc..

Method <NUM> may also optionally include, at Block <NUM>, determining whether the UE is authorized for a QoS based on receiving a change request for a QoS treatment parameter. In an aspect, DRB binding component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or access point transceiver <NUM>, can determine whether the UE is authorized for a QoS based on receiving a change request for a QoS treatment parameter. In one example, DRB binding component <NUM> can receive the change request based on establishing the SDF as a new flow (e.g., based on receiving the indication of the SDF). For example, DRB binding component <NUM> can receive (e.g., from the network component <NUM> or UE <NUM>) a label, flow identifier, QoS parameter, etc. for the SDF indicating a type SDF, from which DRB binding component <NUM> can determine one or more QoS treatment parameters that correspond to the label, flow identifier, QoS parameter, etc. (e.g., based on a configuration at the access point <NUM>).

In another example, DRB binding component <NUM> can receive the request from UE <NUM> (e.g., via RRC message). As described, in an example, UE <NUM> may request change in a QoS treatment parameter for a DRB (e.g., to support a SDF QoS parameter). In this example, DRB binding component <NUM> can determine whether the UE is authorized for a QoS based on changing the QoS treatment parameter. For example, DRB binding component <NUM> can determine whether the UE is authorized based on locally stored subscription information for the UE <NUM>, subscription information received from the network component <NUM> for the UE <NUM> (e.g., based on subscription information regarding the UE <NUM> as maintained or obtained by the network component <NUM> or another network component, which may include an HSS), etc. In an example, DRB binding component <NUM> can request upgrade approval for the QoS from network component <NUM> for UE <NUM> (e.g., where additional information regarding the SDF is desired and/or where access point <NUM> cannot permit the upgrade in QoS without authorization from the network component <NUM>, such as where the UE <NUM> can be limited to certain QoS based on subscription). Based on the response from network component <NUM> or otherwise, DRB binding component <NUM> may indicate the SDF as bound to the existing DRB with the QoS treatment parameter updated and/or may indicate the SDF as bound to one or more new DRBs that may achieve the QoS based on the QoS treatment parameter.

Method <NUM> also includes, at Block <NUM>, indicating, to a wireless device, whether the DRB is the existing DRB or the new DRB. In an aspect, DRB managing component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or access point transceiver <NUM>, can indicate, to the wireless device (e.g., UE <NUM>), whether the DRB is the existing DRB or the new DRB. For example, DRB managing component <NUM> can indicate whether the DRB is the existing DRB or a new DRB via RRC message to the UE <NUM> (e.g., by setting a parameter value in the RRC message as the indication). For example, DRB managing component <NUM> can indicate whether the DRB is the existing DRB or a new DRB based on at least one of determining the DRB as the existing DRB that supports the one or more QoS parameters of the SDF or a new data DRB, determining whether the UE is authorized for the QoS based on the change request, etc..

Moreover, for example, DRB managing component <NUM> can transmit DRB to SDF binding information to the UE <NUM>, which may include a TFT, or a list thereof, data network session identifiers, etc. associated with the DRB, an identifier of the DRB, etc. For example, the indication can additionally include one or more of the PDCP and/or RLC configuration information for the DRB, a priority, delay requirement or threshold, scheduling policy, etc. for the DRB. Moreover, in an example, DRB managing component <NUM> can indicate whether the QoS parameter of the SDF can be satisfied by the DRB.

Method <NUM> also optionally includes, at Block <NUM>, communicating, over the DRB, a packet related to the SDF. In an aspect, DRB managing component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or access point transceiver <NUM>, can communicate, over the DRB, a packet related to the SDF. For example, DRB managing component <NUM> can manage packet forwarding for packets between UE <NUM> and network component <NUM> related to the one or more SDFs based on QoS treatment parameters (e.g., PDCP/RLC configuration, scheduling policy, queue management policy, rate shaping policy, delay, throughput, priority, etc.) defined for the associated one or more DRBs.

Referring to <FIG>, an example of a method <NUM> is illustrated for managing (e.g., by one or more network components of a core network) a SDF with a UE. In method <NUM>, blocks indicated as dashed boxes can represent optional steps.

In an example, method <NUM> optionally includes, at Block <NUM>, receiving a QoS request for a SDF. In an aspect, QoS component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or communications component <NUM>, may receive the QoS request for the SDF. As described, in an example, access point <NUM> may request a QoS for a SDF, which may be based on a request from UE <NUM> to modify the QoS. In an example, this may include UE <NUM> requesting a QoS change via a NAS request, as described, interacting with a control plane function in the core network (e.g., via access point <NUM>) to have a new IP address allocated, network component <NUM> detecting a flow for one of an existing IP address allocated to the UE <NUM>, and/or the like. For example, the request may include one or more parameters related to the QoS of the SDF, such as a desired QoS for the SDF, a flow descriptor or label of the SDF, a description of the QoS parameter, etc. to allow for identifying the associated QoS for the SDF. In an example, communication between the network component <NUM> control plane function and the access point <NUM> may be a communication between the control plane function performing session management to the access point <NUM> via the control plane function performing mobility management function.

Method <NUM> includes, at Block <NUM>, determining whether to establish a separate DRB to satisfy a QoS parameter for a SDF. In an aspect, DRB requesting component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or communications component <NUM>, may determine whether to establish the separate DRB to satisfy the QoS parameter for the SDF. In one example, DRB requesting component <NUM> may determine whether to establish the separate DRB based at least in part on determining whether one or more existing DRBs between access point <NUM> and UE <NUM> can satisfy a QoS of the SDF (e.g., based on comparing one or more QoS treatment parameters indicated for the existing DRBs to a QoS parameter of the SDF, receiving an indication from the access point <NUM> and/or UE <NUM> that the DRB cannot support a QoS parameter of the SDF, etc.).

Method <NUM> may also include, at Block <NUM>, indicating, to an access point, the QoS parameter and/or the determination of whether to establish the separate DRB. In an aspect, QoS component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or communications component <NUM>, may indicate, to the access point (e.g., access point <NUM>, the QoS parameter and/or the determination of whether to establish the separate DRB. Thus, the access point <NUM> may determine a DRB for binding to the SDF, as described, based on determining a DRB that has QoS treatment parameters that can satisfy a QoS parameter of the SDF. In another example, the access point <NUM> may establish a new DRB based on the determination indicated from the network component <NUM> that an existing DRB cannot satisfy an QoS parameter of the SDF, and then binds the new DRB to the SDF, as described.

Method <NUM> may also optionally include, at Block <NUM>, indicating, to the access point, a security requirement for the QoS. In an aspect, QoS component <NUM>, e.g., in conjunction with processor(s) <NUM>, memory <NUM>, and/or communications component <NUM>, may indicate, to the access point (e.g., access point <NUM>), a security requirement for the QoS. For example, the security requirement may include a network session security requirement, a flow security requirement, etc. As described, for example, authentication of the UE <NUM> may be used as part of a change request for QoS of a flow. Thus, QoS component <NUM> may indicate the requirement for security, whether network session based, flow based, etc., to the access point <NUM> in this example. In another example, the indicted security requirement may include a secured token for the flow to simplify QoS classification. In this example, access point <NUM> can obtain the secured token, and can associate the secured token to the flow for providing with packets related to the flow. For example, the secured token may indicate that the UE <NUM> associated with the flow is authorized for the associated QoS.

<FIG> illustrate an example of a system <NUM> for establishing DRBs for managing QoS of SDFs. <FIG> depicts a UE <NUM> that communicates with a RAN <NUM>, which may include an eNB, to receive access to a core network (CN) <NUM> control plane and/or one or more related network components. In an example, CN <NUM> can be or can include network component <NUM>. System <NUM> also includes a GW <NUM>. UE <NUM> may establish one or more DRBs <NUM> with the RAN <NUM>, where each DRB <NUM> may have one or more associated SDFs. DRB <NUM><NUM> may be a best efforts DRB (e.g., a non-guaranteed bit rate DRB) that includes SDF <NUM><NUM> and SDF <NUM><NUM>. At <NUM>, UE <NUM> can communicate user plane data over SDF <NUM><NUM> and SDF <NUM><NUM> (e.g., over DRB <NUM>). In this example, QoS binding is triggered by a change in a QoS parameter of the SDF <NUM><NUM>, where CN <NUM> communicates an access network (AN) connectivity modify request <NUM> to RAN <NUM> (e.g., via flow managing component <NUM> or related components), which identifies SDF <NUM><NUM> and an associated QoS parameter to be updated. As described, for example, the change in QoS parameter may be initiated by the CN <NUM>, based on a request from UE <NUM>, etc. RAN <NUM> (e.g., via DRB managing component <NUM> or related components) can receive the request <NUM> and determine to establish a new DRB to support the new QoS parameter for SDF <NUM><NUM> (e.g., based on determining that DRB <NUM><NUM> and/or other DRBs cannot support the QoS). Accordingly, RAN <NUM> (e.g., via DRB managing component <NUM> or related components) can transmit a RRC connection reconfiguration <NUM> to UE <NUM> to add a DRB <NUM>, along with a TFT configuration to bind SDF <NUM><NUM> to DRB <NUM><NUM>. In a specific example, the TFT configuration may include a list of SDF identifiers to be bound to the corresponding DRB. The UE <NUM> can transmit an RRC connection reconfiguration component <NUM> to indicate that the binding is complete.

<FIG> depicts establishment of DRB <NUM><NUM> between UE <NUM> and RAN <NUM> in this regard. UE <NUM> can establish (e.g., via communicating component <NUM> or related components) DRB <NUM><NUM> with RAN <NUM>, which may be based on parameters received in the RRC connection reconfiguration <NUM> (e.g., RLC configuration, priority, etc. for the DRB <NUM><NUM>). UE <NUM> can additionally (e.g., via communicating component <NUM> or related components) update binding of the SDF <NUM><NUM> to bind to DRB <NUM><NUM> instead of DRB <NUM><NUM> (and/or any indicated update in binding for DRB <NUM><NUM>) based on the received TFT configuration. For example, DRB <NUM><NUM> can be established as a guaranteed bit rate (GBR) DRB to support the QoS updated for SDF <NUM><NUM>. UE can transmit a RRC connection reconfiguration complete <NUM> to RAN <NUM> indicating establishment of the new DRB <NUM><NUM> and/or updating of the binding of SDF <NUM><NUM>. RAN <NUM> can transmit a AN connectivity modify response <NUM> to CN <NUM>. Accordingly, UE <NUM> and CN <NUM> can communicate data for SDF <NUM><NUM>, where UE <NUM> uses DRB <NUM><NUM> with RAN <NUM> to communicate over SDF <NUM><NUM>.

Though shown as accepting the request <NUM>, RAN <NUM> may reject the request <NUM> based on determining that the updated QoS of the SDF <NUM><NUM> cannot be fulfilled by the RAN <NUM>. In an example, RAN <NUM> can transmit a rejection message that includes a rejection code, and can refrain from modifying the DRB configuration.

<FIG> illustrate an example of a system <NUM> for modifying DRBs for managing QoS of SDFs. <FIG> depicts a UE <NUM> that communicates with a RAN <NUM>, which may include an eNB, to receive access to a CN <NUM> control plane and/or one or more related network components. For example, CN <NUM> may be or may include network component <NUM>. System <NUM> also includes a GW <NUM>. UE <NUM> may establish one or more DRBs <NUM>, <NUM> with the RAN <NUM>, where each DRB <NUM>, <NUM> may have one or more associated SDFs. DRB <NUM><NUM> may be a best efforts DRB (e.g., a non-GBR DRB) that includes SDF <NUM><NUM> and SDF <NUM><NUM>, and DRB <NUM><NUM> can be a GBR bearer that includes SDF <NUM><NUM>.

At <NUM>, UE <NUM> can communicate user plane data over SDF <NUM><NUM>, SDF <NUM><NUM>, and/or SDF <NUM><NUM> (e.g., over DRB <NUM><NUM> and/or DRB <NUM><NUM>). In this example, QoS modification is triggered by a change in a QoS parameter of the SDF <NUM><NUM>, where CN <NUM> communicates an access network (AN) connectivity modify request <NUM> to RAN <NUM> (e.g., via flow managing component <NUM> or related components), which identifies SDF <NUM><NUM> and an associated QoS parameter to be updated. As described, for example, the change in QoS parameter may be initiated by the CN <NUM>, based on a request from UE <NUM>, etc. RAN <NUM> (e.g., via DRB managing component <NUM> or related components) can receive the request <NUM> and determine to modify a binding of SDF <NUM><NUM> to DRB <NUM><NUM> instead of DRB <NUM><NUM> (e.g., to support the new QoS parameter. For example, RAN <NUM> may determine that DRB <NUM><NUM> cannot support the QoS parameter for SDF <NUM><NUM>. Accordingly, RAN <NUM> (e.g., via DRB managing component <NUM> or related components) can transmit a RRC connection reconfiguration <NUM> to UE <NUM> to modify DRB <NUM><NUM>, along with a TFT configuration to bind SDF <NUM><NUM> to DRB <NUM><NUM>. In a specific example, the TFT configuration may include a list of SDF identifiers to be bound to the corresponding DRB. The UE <NUM> can transmit an RRC connection reconfiguration component <NUM> to indicate that the binding is complete.

<FIG> depicts binding of the SDF <NUM><NUM> to bind to DRB <NUM><NUM> instead of DRB <NUM><NUM> (and/or any indicated update in binding for DRB <NUM><NUM>) based on the received TFT configuration. UE can transmit a RRC connection reconfiguration complete <NUM> to RAN <NUM> indicating updating of the binding of SDF <NUM><NUM>. RAN <NUM> can transmit a AN connectivity modify response <NUM> to CN <NUM>. Accordingly, UE <NUM> and CN <NUM> can communicate data for SDF <NUM><NUM>, where UE <NUM> uses DRB <NUM><NUM> with RAN <NUM> to communicate over SDF <NUM><NUM>.

The various illustrative logics, logical blocks, modules, components, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Additionally, at least one processor may comprise one or more modules operable to perform one or more of the steps and/or actions described above. An exemplary storage medium may be coupled to the processor, such that the processor can read information from, and write information to, the storage medium. Further, in some aspects, the processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in a user terminal.

In one or more aspects, the functions, methods, or algorithms described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium, which may be incorporated into a computer program product. A storage medium may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, substantially any connection may be termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs usually reproduce data optically with lasers.

Claim 1:
A method for communicating in a wireless network, comprising:
receiving (<NUM>), by a wireless device, an indication of a binding between a service data flow and a data radio bearer with an access point;
determining (<NUM>), based on the received indication, whether the data radio bearer for binding to the service data flow corresponds to an existing data radio bearer that supports one or more quality-of-service, QoS, parameters of the service data flow, or corresponds to a new data radio bearer to be established
with the access point to support the one or more QoS parameters of the service data flow;
based on the determination:
modifying (<NUM>), by the wireless device and based on the determination, the existing data radio bearer with the access point or establishing, by the wireless device and based on the determination, the new data radio bearer with the access point; and
transmitting (<NUM>), by the wireless device in an uplink communication to the access point and based on the binding, a packet using the data radio bearer based at least in part on classifying the packet as related to the service data flow.