Sidelink quality of service flow management in wireless communications systems and related methods and apparatuses

Methods of operating user equipment for device-to-device, D2D, communications are provided. Operations include transmitting a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink, responsive to a determination that a required QoS flow will be fulfilled, receiving a message indicating that a requested sidelink QoS flow will be supported and receiving mapping and configuration data corresponding to the sidelink QoS flow, and responsive to determining that the required QoS may not be fulfilled, receiving a message indicating that the requested sidelink QoS flow will not be established.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a 35 U.S.C. § 371 national stage application of PCT International Application No. PCT/EP2019/079582 filed on Oct. 30, 2019, which in turns claims priority to International Patent Application No. PCT/CN2018/115128, filed on Nov. 13, 2018, the disclosures and content of which are incorporated by reference herein in their entirety.

TECHNICAL FIELD

The present disclosure relates generally to communications, and more particularly, to wireless communications and related wireless devices and network nodes.

BACKGROUND

LTE vehicle-to-anything (V2X) was first specified in 3GPP Release 14 of 3GPP LTE and is currently under investigation for 3GPP Release 15. LTE V2X includes new features and enhancements that allow for vehicular communications. One of the most relevant aspects is the introduction of direct vehicle-to-vehicle (V2V) communication functionalities. The specifications support other type of V2X communications, including V2P (vehicle-to-pedestrian or pedestrian-to-vehicle), V2I (vehicle-to-infrastructure), etc., as shown inFIG.1.

These direct communication functionalities are built upon LTE D2D (device to device), also known as ProSe (Proximity Services), as first specified in the Release 12 of LTE, and include many important enhancements targeting the specific characteristics of vehicular communications. For example, LTE V2X operation is possible with and without network coverage and with varying degrees of interaction between the UEs (user equipment) and the network (NW), including support for standalone, network-less operation. To enhance the system level performance under high device density while meeting the latency requirements of V2X, new transmission modes (also referred to as resource allocation modes) were introduced: Mode 3 and Mode 4. In Mode 3, the NW is in charge of performing resource allocation whereas in Mode 4, the UE autonomously selects the resources for its own transmissions.

To support 5G V2X services, 28 use cases and their performance requirements are studied in TR 22.886 [1]. It is shown that 5G V2X services usually come with stringent Quality of Service (QoS) requirements, e.g. 99.999% reliability and 10 ms latency. Benefiting from the ultra-reliable and lower latency wireless connection, vehicles can optimize their maneuvers via, e.g., cooperative driving or forming a platoon. From another perspective, any disturbance/interruption on the wireless connection may lead to hazardous situations or even car accident.

Currently, there are many Use Cases (UCs) under discussion within V2X context, e.g. platooning, cooperative driving, car following and hazard zone warning etc. [1]. Many of them have stringent requirements on QoS, e.g. 99.9% reliability and 50 ms maximum latency. Table 1 provides some example UCs and their requirements discussed within 3GPP.

In NR Uu interface, QoS control may be handled on QoS flow level in 5GS. The basic idea behind is that each QoS flow is associated with a 5QI value, which indicates the associated QoS requirements. Such requirements may include reliability, latency, and/or data rate, among others. QoS requirements may depend on the service and user's subscription with the operator.

Once a UE is connected to the core network, CN, a session may be established between the UE and the CN with a default QoS flow and a default data radio bearer (DRB). Reference [2] specifies a number of ways to establish/release a new QoS flow. Brief reference is made toFIG.2, which is a schematic data flow diagram illustrating an example of QoS flow establishment in NR Uu. As provided, a new QoS flow can be initiated by CN, the request is sent to gNB. It may be up to gNB to decide whether to accept or reject the QoS flow according to admission control rules. If accepted, gNB may map the QoS flow to a new DRB or an existing DRB. UE will be configured accordingly. Another example provides that a new QoS flow can be initiated by UE, which first sends the data via default bearer with a new QFI in its SDAP header. It's up to gNB whether to establish a new DRB for this new QoS flow. In another example, when CN wants to release an established QoS flow, it may send a request to gNB, and then may send an RRC DRB modify request to the UE to release the QFI to DRB mapping.

The ARP of a QoS flow is used for the sake of flow-based admission control procedures in which gNB decides whether or not the requested flow should be established in case of radio congestion. It also governs the prioritization of the QoS flow in terms of pre-emption with respect to a new QoS flow establishment request [3]. Further, in NR, it may be allowed to have multiple QoS flows mapped to the same bearer. In other word, it may be up to gNB to map the QoS flow to an existing DRB or a new DRB.

The QoS framework for NR sidelink, SL, is under discussion in 3GPP. Since the QoS framework in LTE SL, which is based on PPPP/PPPR per packet, is not robust enough to support stringent eV2X QoS requirements, it is expected that NR SL should use similar QoS framework as in Uu, which is QoS flow and DRB based.

NR SL bearer establishment and admission control considering the available resources and the interference environment have been considered. For instance, according to reference [4] In NW controlled mode, before the transmitter establishes a bearer and activates the service, it shall request bearer permission/configuration from gNB. gNB estimates the amount of available resources and accepts the request when there are enough resources to support the required QoS, e.g. data rate.

According to reference [5], in autonomous mode, the admission control can be done based on the (pre)configured rules from NW, e.g. via SIB/RRC. For instance, one UE can only establish a bearer for a certain service when the channel busy ratio (CBR) is lower than a threshold value.

According to reference [6], methods to leverage information from RX side when TX UE attempts to establish a DRB are described. In reference [7], methods to monitor, maintain and release an established SL DRB according to the QoS performance are described.

Until now, some solutions include SL QoS management at DRB level, which could work when it's one to one mapping between SL QoS flow and SL DRB. Establishing or releasing one SL DRB may mean establishing or releasing a corresponding SL QoS flow. However, it becomes problematic when multiple SL QoS flows are mapped to the same SL DRB. For example, assuming one UE has three SL QoS flows mapped to one SL DRB, and gNB must pre-empt some resources due to channel congestion, it would release the SL QoS flow with the lowest priority rather than release the whole SL DRB. This may mean the release all three associated QoS flows. In other word, QoS management in NR SL must target not only SL bearer but also SL QoS flow. The SL QoS flow management mechanisms are currently missing. Of course, NR SL QoS flow management can reuse what is in NR Uu. However, heavy interaction, which also means overhead, with CN as in NR Uu seems unnecessary for NR SL, since SL data does not go via CN. Thus, CN involvement in SL QoS flow management can be minimized.

SUMMARY

According to some embodiments of inventive concepts, methods of operating a user equipment, UE, for device-to-device, D2D, communications are provided. Methods may include transmitting a quality of service, QoS, flow establishment request. The flow establishment request may indicate that the QoS flow is to be transmitted over a sidelink, SL. In response to a determination that a required QoS flow will be fulfilled, operations include receiving a message indicating that a requested sidelink QoS flow will be supported and receiving mapping and configuration data corresponding to the sidelink QoS flow. In response to determining that the required QoS may not be fulfilled, operations may include receiving a message indicating that the requested sidelink QoS flow will not be established.

According to some embodiments of inventive concepts, a user equipment, UE is provided. The UE may include a transceiver, a processor coupled to the transceiver, and a memory coupled to the processor, wherein the memory stores instructions that when executed by the processor cause the UE to transmit a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink. In response to a determination that a required QoS flow will be fulfilled, a message may be received that indicates that a requested sidelink QoS flow will be supported and receiving mapping and configuration data corresponding to the sidelink QoS flow. In response to determining that the required QoS may not be fulfilled, a message may be received that indicates that the requested sidelink QoS flow will not be established.

According to some embodiments of inventive concepts, methods of operating a network node for providing network assisted sidelink quality of service flow management are provided. Such methods include receiving, from a user equipment, UE, a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink, determining whether a required QoS flow will be fulfilled, in response to determining that the required QoS flow will be fulfilled, transmitting a message indicating that a requested sidelink QoS will be supported and transmitting mapping and configuration data corresponding to the sidelink QoS flow, and in response to determining that the required QoS flow may not be fulfilled, transmitting a message indicating that the requested sidelink QoS will not be established.

According to some embodiments of inventive concepts, a network node is provided. The network node may include a transceiver, a processor coupled to the transceiver and a memory coupled with the processor. The memory stores instructions that when executed by the processor causes the network node to receive, from a user equipment, UE, a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink, to determine whether a required QoS flow will be fulfilled, to, in response to determining that the required QoS flow will be fulfilled, transmit a message indicating that a requested sidelink QoS will be supported and transmitting mapping and configuration data corresponding to the sidelink QoS flow and to, in response to determining that the required QoS flow may not be fulfilled, transmit a message indicating that the requested sidelink QoS will not be established.

According to some embodiments of inventive concepts, methods of operating a user equipment, UE, for device-to-device, D2D, communications are provided. Such methods include storing a preconfigured SL QoS flow management control rule set that defines operations for establishing, by the UE, a SL QoS flow, establishing a SL QoS flow by performing rules in the preconfigured SL QoS flow management control rule set, and responsive to a determination that the QoS will be fulfilled, establishing, by the UE, the SL QoS flow and mapping the SL QoS flow to a DRB.

According to some embodiments of inventive concepts, a user equipment, UE, is provided. The UE includes a transceiver, a processor coupled to the transceiver, and memory coupled with the processor. The memory stores instructions that when executed by the processor causes the user equipment to store a preconfigured SL QoS flow management control rule set that defines operations for establishing, by the UE, a SL QoS flow, establish a SL QoS flow by performing rules in the preconfigured SL QoS flow management control rule set, and, responsive to a determination that the QoS will be fulfilled, establish, by the UE, the SL QoS flow and mapping the SL QoS flow to a DRB.

According to some embodiments, a computer program product includes a non-transitory computer readable storage medium that includes computer readable program code embodied in the medium that when executed by a processor of a user equipment, UE, causes the UE to transmit a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink. The UE is further configured to, responsive to a determination that a required QoS flow will be fulfilled, receive a message indicating that a requested sidelink QoS flow will be supported and receive mapping and configuration data corresponding to the sidelink QoS flow. The UE is further configured to, responsive to determining that the required QoS may not be fulfilled, receive a message indicating that the requested sidelink QoS flow will not be established.

According to some embodiments, a computer program product includes a non-transitory computer readable storage medium that includes computer readable program code embodied in the medium that when executed by a processor of a network node, causes the network node to receive, from a user equipment, UE, a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink. The network node is further configured to determine whether a required QoS flow will be fulfilled and, in response to determining that the required QoS flow will be fulfilled, transmit a message indicating that a requested sidelink QoS will be supported and transmitting mapping and configuration data corresponding to the sidelink QoS flow. The network node is further configured to, in response to determining that the required QoS flow may not be fulfilled, transmit a message indicating that the requested sidelink QoS will not be established.

According to some embodiments, a computer program product includes a non-transitory computer readable storage medium that includes computer readable program code embodied in the medium that when executed by a processor of a user equipment, UE, causes the UE to store a preconfigured sidelink QoS flow management control rule set that defines operations for establishing, by the UE, a sidelink QoS flow. The UE is further configured to establish a sidelink QoS flow by performing rules in the preconfigured sidelink QoS flow management control rule set and, responsive to a determination that the QoS will be fulfilled, establish, by the UE, the sidelink QoS flow and mapping the sidelink QoS flow to a DRB.

According to some embodiments disclosed herein, communication resources may minimize the involvement of a CN in SL QoS flow management, which may improve efficiency.

DETAILED DESCRIPTION

Overview of Present Approaches and Potential Advantages:

Systems, methods, and corresponding apparatuses are disclosed below that operate to enable SL admission control and packet preemption in autonomous mode. Each SL bearer is associated with a bearer level priority indicator and a packet level priority indicator. When there are not enough resources available for SL bearer establishment or for packets transmission, one UE can preempt some booked lower priority transmissions; otherwise, the UE must release the corresponding bearer.

According to some embodiments herein, methods for enabling QoS flow management in NR SL are provided. The difference of SL QoS flow management compared to NR Uu is emphasized, and detailed procedure and signaling transmission are described. Scenarios in coverage with or without NW assistance are disclosed. Further, QoS flow information exchange between TX UE and RX UE is disclosed and additional criteria to map QoS flows into bearer based on casting scheme/session are disclosed.

In some embodiments, methods for managing SL QoS flow with and/or without NW assistance are provided. Each SL QoS flow may be associated with its QoS profiles (e.g. 5QI, ARP, GBR, MGBR etc.), and may be identified by its QoS flow ID (QFI). SL QFI may be unique within one SL session.

In NW assisted SL QoS flow management, when SL UE is in RRC_CONNECTED mode, SL QoS flow management can be controlled by the NW with limited CN involvement.

Reference is now made toFIG.3, which is a schematic flow diagram illustrating LS QoS flow management with CN involvement according to some embodiments. In some embodiments, NAS signaling is used to perform SL QoS flow management. Only limited number of CN entities, e.g. AMF and SMF, may be involved. As illustrated, block310provides that establishing a SL QoS flow for a service, a QoS flow establishment request may be sent to CN, e.g. SMF, using NAS signaling. The UE may indicate in the request that the QoS flow will be transmitted over SL.

The SMF may understand that the requested QoS flow will be transmitted over SL and may generate and send a corresponding request and sends relevant SL QoS flow parameters, e.g. SL QFI and QoS profiles, to gNB via NG interface (block312. The SMF may indicate to the gNB that the requested QoS flow will be transmitted over SL.

The gNB may understand that the requested QoS flow will be transmitted over SL and performs SL admission control (block314). If the required QoS is estimated to be fulfilled, gNB informs the SMF that the requested QoS can be supported, the SMF then informs the UE via. NAS signaling that the requested SL QoS flow can be established. The gNB may map the requested SL QoS flow to either an existing SL DRB or a new SL DRB and send the mapping and relevant configurations to the UE via e.g. RRC signaling.

If the required QoS is estimated to be not fulfilled, gNB informs the SMF that the requested QoS cannot be supported and the SMF then informs the UE via NAS signaling that the requested SL QoS flow cannot be established.

The release of an established QoS flow can be triggered by either UE or gNB.

Some embodiments provide that the SL QoS flow release is initiated by UE. The UE may want to release one SL QoS flow, e.g. due to QoS degradation. The release request containing the associated QFI may be sent from UE to CN, e.g. SMF, via NAS signaling (block320). The UE will then clear the relevant QoS flow context, e.g. QFI, QoS profiles, the QoS flow to DRB mapping, the UE may also clear the associated DRB when there are no other QoS flow using the same DRB. The UE may indicate in the request that the QoS flow to be released is transmitted over SL.

The CN, e.g. SMF, may generate and send a corresponding release request to gNB via NG interface (block322). The SMF may indicate in the request that the QoS flow to be released is transmitted over SL. The CN and gNB may clear the relevant QoS flow context. The gNB may also clear the associated DRB when there are no other QoS flow using the same DRB.

In some embodiments, the SL QoS flow release may be initiated by gNB. When the gNB wants to release one SL QoS flow, e.g. to preempt some resources for new QoS flow, a release request containing the associated QFI will be sent from gNB to CN, e.g. SMF, via NG interface (block330). The gNB may indicate in the request that the QoS flow to be released is transmitted over SL. The gNB will then clear the relevant QoS flow context, e.g. QFI, QoS profiles. the gNB clears the corresponding flow to DRB mapping and may also clear the associated DRB when there are no other QoS flow using the same DRB.

The CN, e.g. SMF, generates and sends a release request to UE via, e.g. NAS signaling (block332). The CN and UE clear the relevant QoS flow context. The UE clears the corresponding flow to DRB mapping may also clear the associated DRB when there are no other QoS flow using the same DRB.

Reference is now made toFIG.4, which is a schematic data flow diagram illustrating SL QoS flow management without CN involvement according to some embodiments. In some embodiments, the service to SL QoS profiles mapping is (pre)configured by CN and informed to the UE (in advanced) (block410). Later on, the SL QoS flow management may be performed only between UE and gNB without CN involvement.

QoS flow establishment may also be provided without the CN. For example, when one UE wants to establish a new SL QoS flow for a service, it may first find the associated QoS profiles according to (pre)configuration and generates a QFI for it (block420). The info is then passed from NAS layer to AS layer within the UE and the AS layer of the UE sends a QoS flow establishment request containing the requested QFI and associated QoS profiles to gNB via RRC signaling. The UE may indicate in the request that the requested QoS flow will be transmitted over SL. Note that the QFI generation can follow some pre-defined rules, e.g. a pre-defined 5QI to QFI mapping according to some embodiments.

In some embodiments, the gNB may perform SL admission control. If the required QoS is estimated to be fulfilled, the gNB accepts the request. The gNB may map the SL QoS flow to either an existing SL DRB or a new SL DRB and sends an acknowledgement to the UE including the mapping and relevant configurations via e.g. RRC signaling (block422). The UE then updates SL DRB configurations accordingly and informs its own upper layer that the requested SL QoS flow is accepted.

If the required QoS is estimated to be not fulfilled, the QoS flow request may be rejected. The rejection message may be sent from gNB to UE via e.g. RRC signaling. The UE informs its own upper layer that the requested SL QoS flow is rejected.

Some embodiments provide that the QoS flow release may be initiated by the UE. When the UE wants to release one SL QoS flow, e.g. due to QoS degradation, a release request containing the associated QFI may be sent from the UE to gNB via e.g. RRC signaling (block430). The UE may indicate in the request that the QoS flow to be released is transmitted over SL. The UE and gNB will then clear the relevant QoS flow context, e.g. QFI, QoS profiles. QoS flow to DRB mapping, the UE and gNB may also clear the associated DRB when there are no other QoS flow using the same DRB.

In some embodiments, the QoS flow release may be initiated by gNB. When the gNB wants to release one SL QoS flow, e.g. to preempt some resources for new QoS flow, a release request containing the associated QFI will be sent from the gNB to UE via e.g. RRC signaling (block440). The UE and gNB may then clear the relevant QoS flow context, e.g. QFI, QoS profiles, QoS flow to DRB mapping/The UE and gNB may also clear the associated DRB when there are no other QoS flow using the same DRB.

Some embodiments provide for autonomous SL QoS flow management. For example, when UE is out of coverage and/or in RRC_IDLE mode, the SL QoS flow management may be performed by UE itself according to pre-configuration. When one UE wants to establish a SL QoS flow, it follows preconfigured admission control rules to estimate if required QoS can be fulfilled. If the condition allows, it setups the QoS flow and maps it to existing or new DRB. When one UE wants to release a SL QoS flow, it may clear the corresponding QoS flow context and may also release the associated DRB if there are no other QoS flows using the same DRB.

Reference is now made toFIG.5, which is a schematic data flow diagram illustrating SL QoS flow management in SL unicast and/or groupcast according to embodiments. For SL unicast/groupcast, the SL QoS flow context should be aware among involved SL UE peers. SL QoS flow establishment may be first performed by the TX UE, with/without assistance from RX UE according to embodiments herein (block500). Once the QoS flow is established at TX side, TX UE should inform RX UE(s) with regard to the QoS flow context. In some embodiments, QFI value can be conveyed in the SDAP header during data transmission, the RX UE(s) can then recognize the SL QoS flow from QFI value and interpret the corresponding QoS characteristics and/or service type.

The SL QoS flow release can be initiated by either TX UE or RX UE or gNB, e.g. due to QoS degradation (block510). In one embodiment, a release notification is used, e.g. one UE notifies the other UE about the planed SL QoS flow release via. e.g. NAS signaling, and associated QFI can be contained in the notification signaling. Then TX UE or gNB will execute the SL QoS flow release following embodiments herein.

Some embodiments provide that additional criteria may be used to map QoS flows into the DRB. In the following description, the terminology “casting scheme” is used to represent unicast/groupcast/broadcast transmissions. The terminology “casting session” is instead used to represent a specific V2X traffic session intended for a specific receiver (unicast) or for a specific group of UEs (groupcast). A UE may be involved in multiple casting sessions, e.g. multiple unicast session with different UEs, and for each casting session different traffics/services can be transmitted.

Both the specific casting scheme and the specific casting session can be signaled to Access Stratum by higher layers and represented by dedicated field and/or ID in Access stratum (e.g. in MAC).

The following additional criteria may be used by the UE (e.g. for the case of Autonomous SL QoS flow management as described in previous embodiments) or by the network (e.g. for the case of network-controlled QoS flow management, as described in previous embodiments). A QoS flow related to a certain V2X service can be associated/multiplexed into a radio bearer where only QoS flows related to the same service can be associated/multiplexed. The V2X service can be represented by any ID, such as ITS ID, AID, or equivalent L2 destination ID.

The method does not preclude that there are multiple radio bearers associated to the same V2X service, e.g. depending on the 5QI associated to the different QoS flows which are related to the same V2X service.

In some embodiments, a QoS flow related to a certain casting scheme can be associated/multiplexed into a radio bearer where only QoS flows associated to the same casting scheme can be associated/multiplexed. For example, if a QoS flow is associated to a traffic type which is supposed to be transmitted in broadcast fashion, such QoS flow can be multiplexed into a radio bearer where only broadcast type of traffics can be multiplexed/associated. The method does not preclude that there are multiple radio bearers associated to the same casting scheme, e.g. depending on the 5QI associated to the QoS flow associated to the different QoS flows which are related to the same casting scheme.

Some embodiments provide that a QoS flow related to a certain casting session can be associated/multiplexed into a radio bearer where only QoS flows associated to the same casting session can be associated/multiplexed. For example, if a QoS flow is associated to a traffic type which is supposed to be transmitted in unicast/groupcast fashion and intended for a specific receiver or group of receivers, i.e. associated to a specific casting session, such QoS flow can be multiplexed into a radio bearer where only traffics intended for the same receiver or group of receivers, i.e. casting session, can be associated/multiplexed. The method does not preclude that there are multiple radio bearers associated to the same casting session, i.e. same receiver or group of receivers, for example depending on the 5QI associated to the QoS flow associated to the different QoS flows which are related to the same casting scheme.

A combination of the above criteria, e.g. a QoS flow related to a certain casting scheme and V2X service can be associated/multiplexed into a radio bearer where only QoS flows associated to the same casting scheme and V2X service can be associated/multiplexed.

To support the above, specific radio bearer ID and logical channel ID can be associated. For example, in one embodiment, a set of radio bearer ID/LCID can be associated to represent radio bearers associated to the same V2X service, and/or the same casting scheme. In one embodiment, among the set of IDs reserved for the same casting scheme, the UE may select different IDs to represent different casting session. In another embodiment, among the set of IDs reserved to the same V2X service, different IDs can be used to represent different casting scheme.

Additional criteria may be used in the MAC layer to handle multiplexing of the QoS flows into a MAC PDU, as part of the logical channel prioritization procedure. Following criteria can include that a MAC layer multiplexes into the same MAC PDU only radio bearers, with associated QoS flows, which are associated to the same V2X service. A MAC layer may multiplex into the same MAC PDU only radio bearers, with associated QoS flows, which are associated to the same casting scheme. A MAC layer may multiplex into the same MAC PDU only radio bearers, with associated QoS flows, which are associated to the same casting session. Any combination of the above criteria may be included. For example, a UE may multiplex in the same MAC PDU only traffic which is carrying the same V2X service and which is associated to the same casting scheme and/or to the same casting session.

Reference is now made toFIG.6, which is a flow chart illustrating operations of methods, systems and apparatus according to some embodiments. Methods of operating a user equipment, UE, for device-to-device, D2D, communications include transmitting a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink (block600). Operations may include, responsive to a determination that a required QoS flow will be fulfilled, receiving a message indicating that a requested sidelink QoS flow will be supported and receiving mapping and configuration data corresponding to the sidelink QoS flow (block602) and responsive to determining that the required QoS may not be fulfilled, receiving a message indicating that the requested sidelink QoS flow will not be established (block604).

In some embodiments, operations may include, responsive to determining that the required QoS may not be fulfilled, generating, by the UE, a QFI corresponding to the requested QoS flow (block608). Some embodiments provide transmitting a QoS flow release request that includes a QoS flow identifier, QFI, that identifies a corresponding sidelink QoS flow and clearing a relevant QoS flow context, wherein the relevant QoS flow context comprises QFI, QoS profiles, QFI to radio data bearer, DRB, mapping and/or the corresponding DRB.

In some embodiments, the mapping and configuration data are preconfigured by a core network and received by the UE, wherein transmitting the QoS flow establishment request comprises transmitting the QoS flow establishment request via radio resource control, RRC, signaling to a gNB, and wherein the QoS flow establishment request comprises QoS flow related data that was preconfigured and indication that the requested QoS flow will be transmitted over the sidelink QoS flow.

Some embodiments provide that transmitting the QoS flow establishment request comprises transmitting the release request to a core network, CN, via NAS signaling. In some embodiments, an acknowledgement message may be received from the gNB via RRC signaling that includes relevant mapping and configurations corresponding to the sidelink QoS flow. The sidelink QoS DRB configurations may be updated and a UE upper layer may be informed that the requested sidelink QoS flow is accepted.

Some embodiments provide that responsive to determining that the required QoS may not be fulfilled, operations may include receiving a rejection message via RRC and from the gNB signaling that the QoS flow request will be rejected, wherein the RRC rejection message comprises the QFI corresponding to the QoS flow and updating the UE upper layer that the requested sidelink QoS flow is rejected (block610).

Some embodiments provide receiving, from a gNB, a release request that includes a QFI corresponding to the sidelink QoS flow (block612) and clearing a relevant QoS flow context that includes the QFI, QoS profile, QFI to DRB mapping and/or the corresponding DRB (block614).

Some embodiments provide that a gNB is caused to release the QoS flow and delete relevant QoS context data. In some embodiments, responsive to QoS degradation of a sidelink QoS flow, a release request may be transmitted that includes a QFI corresponding to the sidelink QoS flow. Methods include clearing a relevant QoS flow context that includes the QFI, QoS profile, QFI to DRB mapping and/or the corresponding DRB (block614) wherein a gNB is caused to release the QoS flow and delete relevant QoS context data.

In some embodiments, transmitting the release request comprises transmitting the release request to a core network, CN, via NAS signaling. In some embodiments, in response to determining that no other QoS flows are being used by a same DRB, the release request includes a request to release the DRB.

Some embodiments include following a preconfigured admission control rule to determine if the sidelink QoS flow is fulfilled (block616) and establishing a sidelink QoS flow responsive to determining that the QoS flow is fulfilled (block618).

In some embodiments, the UE comprises a transmitter, TX, UE, wherein responsive to establishing the sidelink QoS flow, operations include transmitting, to a receiver, RX, UE a message corresponding to the sidelink QoS flow (block620). In some embodiments, the message comprises the QFI value during data transmission and that causes the RX UE to determine a QoS characteristic and/or service type.

Reference is now made toFIG.7, which is a flow chart illustrating operations of methods, systems and apparatus according to some embodiments. Methods of operating a network node for providing network assisted sidelink quality of service flow management may include receiving, from a user equipment, UE, a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink (block700), determining whether a required QoS flow will be fulfilled (block702), and, in response to determining that the required QoS flow will be fulfilled, transmitting a message indicating that a requested sidelink QoS will be supported and transmitting mapping and configuration data corresponding to the sidelink QoS flow (block704). Methods further include, in response to determining that the required QoS flow may not be fulfilled, transmitting a message indicating that the requested sidelink QoS will not be established (block706).

In some embodiments, methods include, responsive to determining that the required QoS may not be fulfilled, receiving, from the UE, a QFI corresponding to the requested QoS flow (block708). Some embodiments include receiving a QoS flow release request that includes a QoS flow identifier, QFI, that identifies a session corresponding to the sidelink QoS flow (block710) and clearing a relevant QoS flow context (block712). In some embodiments, the relevant QoS flow context comprises QFI, QoS profiles, QFI to radio data bearer, DRB, mapping and/or the corresponding DRB.

Some embodiments provide that the mapping and configuration data are preconfigured by a core network and transmitted to the UE and that receiving the QoS flow establishment request includes receiving the QoS establishment request directly from the UE via radio resource control, RRC, signaling to a gNB. In some embodiments, the QoS establishment request includes QoS flow related data that was preconfigured and indication that the requested QoS flow will be transmitted over the sidelink QoS flow.

Some embodiments include transmitting an acknowledgement message to the UE via RRC signaling that includes relevant mapping and configurations corresponding to the sidelink QoS flow (block714). responsive to determining that the required QoS may not be fulfilled, operations may further include transmitting a rejection message via RRC to the UE signaling that the QoS flow request will be rejected, wherein the RRC rejection message comprises the QFI corresponding to the QoS flow (block716) and causing the UE to update the UE upper layer that the requested sidelink QoS flow is rejected (block718).

Some embodiments include transmitting, to the UE, a release request that includes a QFI corresponding to the sidelink QoS flow (block720), clearing a relevant QoS flow context that includes the QFI, QoS profile, QFI to DRB mapping and/or the corresponding DRB (block722) and releasing the QoS flow and delete relevant QoS context data (block724).

Some embodiments include following a preconfigured admission control rule to determine if the sidelink QoS flow will be fulfilled (block726) and establishing a sidelink QoS flow responsive to determining that the QoS flow is fulfilled (block728).

Operations may further include associating the sidelink QoS flow with a plurality of other sidelink QoS flows that correspond to a same V2X service (block730) and selecting a plurality of identifiers to represent respective ones of a plurality of sidelink QoS flow sessions (block732).

Reference is now made toFIG.8, which is a flow chart illustrating operations of methods, systems and apparatus according to some embodiments. Methods of operating a user equipment, UE, for device-to-device, D2D, communications may include storing a preconfigured SL QoS flow management control rule set that defines operations for establishing, by the UE, a SL QoS flow (block800). Embodiments may include establishing a SL QoS flow by performing rules in the preconfigured SL QoS flow management control rule set (block802). Operations may include, responsive to a determination that the QoS will be fulfilled, establishing, by the UE, the SL QoS flow and mapping the SL QoS flow to a DRB (block804).

In some embodiments, the DRB comprises an existing DRB or a new DRB. Some embodiments provide performing a SL QoS flow release operation (block806). Some embodiments provide that the release operation includes clearing a QoS flow context and releasing the DRB if no other QoS flows are using the DRB. In some embodiments, the QoS flow that is related to a given V2X service is associated with a DRB and only other QoS flows that are related to the given V2X service are associated with the DRB.

FIG.9is a block diagram illustrating elements of a wireless device UE900(also referred to as a wireless terminal, a wireless communication device, a wireless communication terminal, user equipment, UE, a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of inventive concepts. As shown, the UE may include an antenna9007, and a transceiver circuit9001(also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with other UEs (e.g., SL communications), a radio access network RAN node (e.g., a base station, eNB, gNB, network node, etc.) of a wireless communication network. UE900may also include a processor circuit903(also referred to as a processor) coupled to the transceiver circuit, and a memory circuit905(also referred to as memory) coupled to the processor circuit. The memory circuit905may include computer readable program code that when executed by the processor circuit903causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 3 may be defined to include memory so that a separate memory circuit is not required. UE900may also include an interface (such as a user interface) coupled with processor and a three, and/or wireless device UE may be an IoT and/or MTC device.

As discussed herein, operations of wireless device UE900may be performed by processor903and/or transceiver901. For example, processor903may control transceiver901to transmit uplink communications through transceiver901over a radio interface to another UE and/or a RAN node of a wireless communication network and/or to receive downlink communications through transceiver901from another UE and/or a RAN node of the wireless communication network over a radio interface. Moreover, modules may be stored in memory905, and these modules may provide instructions so that when instructions of a module are executed by processor903, processor903performs respective operations (e.g., operations discussed below with respect to Example Embodiments).

FIG.10is a block diagram illustrating elements of a node1000(also referred to as a network node, base station, eNB, eNodeB, gNB, gNodeB, etc.) of a Radio Access Network (RAN) configured to provide cellular communication according to embodiments of inventive concepts. As shown, the network node may include a transceiver circuit1001(also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with wireless communication devices UEs. The network node may include a network interface circuit1007(also referred to as a network interface) configured to provide communications with other nodes (e.g., with other base stations and/or core network nodes) of the RAN and/or core network. The network node may also include a processor circuit1003(also referred to as a processor) coupled to the transceiver circuit, and a memory circuit1005(also referred to as memory) coupled to the processor circuit. The memory circuit1005may include computer readable program code that when executed by the processor circuit1003causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit1003may be defined to include memory so that a separate memory circuit is not required.

As discussed herein, operations of the network node may be performed by processor1003, network interface1007, and/or transceiver1001. For example, processor1003may control transceiver1001to transmit communications through transceiver1001over a radio interface to one or more UEs and/or to receive communications through transceiver1001from one or more UEs over a radio interface. Similarly, processor1003may control network interface1007to transmit communications through network interface1007to one or more other network nodes and/or to receive communications through network interface from one or more other network nodes. Moreover, modules may be stored in memory1005, and these modules may provide instructions so that when instructions of a module are executed by processor1003, processor1003performs respective operations (e.g., operations discussed below with respect to Example Embodiments).

Listing of Embodiments

1. A method of operating a user equipment, UE, for device-to-device, D2D, communications, the method comprising:transmitting a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink;responsive to a determination that a required QoS flow will be fulfilled, receiving a message indicating that a requested sidelink QoS flow will be supported and receiving mapping and configuration data corresponding to the sidelink QoS flow; and responsive to determining that the required QoS may not be fulfilled, receiving a message indicating that the requested sidelink QoS flow will not be established.

2. The method of embodiment 1, the method further comprising responsive to determining that the required QoS may not be fulfilled, generating, by the UE, a QFI corresponding to the requested QoS flow.

3. The method of any of embodiments 1 and 2, further comprising: transmitting a QoS flow release request that includes a QoS flow identifier, QFI, that identifies a corresponding sidelink QoS flow; andclearing a relevant QoS flow context, wherein the relevant QoS flow context comprises QFI, QoS profiles, QFI to radio data bearer, DRB, mapping and/or the corresponding DRB.

4. The method of any of embodiments 1-3, wherein the mapping and configuration data are preconfigured by a core network and received by the UE, wherein transmitting the QoS flow establishment request comprises transmitting the QoS flow establishment request via radio resource control, RRC, signaling to a gNB, and wherein the QoS flow establishment request comprises QoS flow related data that was preconfigured and indication that the requested QoS flow will be transmitted over the sidelink QoS flow.

5. The method of any of embodiments 1-4, wherein transmitting the QoS flow establishment request comprises transmitting the release request to a core network, CN, via NAS signaling.

6. The method of embodiment 5, further comprising receiving an acknowledgement message from the gNB via RRC signaling that includes relevant mapping and configurations corresponding to the sidelink QoS flow.

7. The method of embodiment 6, further comprising updating the sidelink QoS DRB configurations and informing a UE upper layer that the requested sidelink QoS flow is accepted.

8. The method of any of embodiments 1-7, wherein responsive to determining that the required QoS may not be fulfilled, the method further comprising:receiving a rejection message via RRC and from the gNB signaling that the QoS flow request will be rejected, wherein the RRC rejection message comprises the QFI corresponding to the QoS flow; andupdating the UE upper layer that the requested sidelink QoS flow is rejected.

9. The method of embodiments 1-8, wherein the method further comprises:receiving, from a gNB, a release request that includes a QFI corresponding to the sidelink QoS flow; andclearing a relevant QoS flow context that includes the QFI, QoS profile, QFI to DRB mapping and/or the corresponding DRB,wherein a gNB is caused to release the QoS flow and delete relevant QoS context data.

10. The method of any of embodiments 1-9, wherein responsive to QoS degradation of a sidelink QoS flow, the method further comprises:transmitting a release request that includes a QFI corresponding to the sidelink QoS flow; andclearing a relevant QoS flow context that includes the QFI, QoS profile, QFI to DRB mapping and/or the corresponding DRB,wherein a gNB is caused to release the QoS flow and delete relevant QoS context data.

11. The method of embodiment 10, wherein transmitting the release request comprises transmitting the release request to a core network, CN, via NAS signaling.

12. The method of embodiment 10, wherein in response to determining that no other QoS flows are being used by a same DRB, the release request includes a request to release the DRB.

13. The method of any of embodiments 1-12, further comprising:following a preconfigured admission control rule to determine if the sidelink QoS flow is fulfilled; andestablishing a sidelink QoS flow responsive to determining that the QoS flow is fulfilled.

14. The method of any of embodiments 1-13, wherein the UE comprises a transmitter, TX, UE, wherein responsive to establishing the sidelink QoS flow, the method further comprises transmitting, to a receiver, RX, UE a message corresponding to the sidelink QoS flow,wherein the message comprises the QFI value during data transmission and that causes the RX UE to determine a QoS characteristic and/or service type.

15. The method of embodiment 14, wherein the TX UE is further configured to initiate a sidelink QoS flow release based on a QoS degradation.

16. The method of any of embodiments 14-15, wherein the TX UE is further configured to receive, from the RX UE, a sidelink QoS flow release based on a QoS degradation.

17. The method of any of embodiments 1-16, wherein a unicast sidelink QoS flow comprises a specific V2X traffic session that is transmitted to a specific RX UE.

18. The method of any of embodiments 1-16, wherein a groupcast sidelink QoS flow comprises a specific V2X traffic session that is transmitted to a specific group of RX UEs.

19. The method of any of embodiments 1-18, further comprising associating the sidelink QoS flow with a plurality of other sidelink QoS flows that correspond to a same V2X service.

20. The method of any of embodiments 1-19, wherein the same V2X service is represented by a unique identifier.

21. The method of any of embodiments 1-20, wherein the same V2X service is associated with a plurality of radio bearers.

22. The method of any of embodiments 1-21, further comprising selecting a plurality of identifiers to represent respective ones of a plurality of sidelink QoS flows.

23. The method of any of embodiments 1 to 21, wherein the service is a vehicle to anything, V2X, service.

24. The method of any of embodiments 1-23,wherein the QoS flow that is related to a given V2X service is associated with a DRB, andwherein only other QoS flows that are related to the given V2X service are associated with the DRB.

25. The method of any of embodiments 1-24,wherein the QoS flow that is related to a given V2X service is multiplexed into a DRB, andwherein only other QoS flows that are related to the given V2X service are multiplexed into the DRB.

26. The method of any of embodiments 1-25,wherein the QoS flow that is related to a given casting scheme is associated with a DRB, andwherein only QoS flows that are associated with the given casting scheme are associated with the DRB.

27. The method of any of embodiments 1-26,wherein the QoS flow that is related to a given casting scheme is multiplexed into a DRB, andwherein only QoS flows that are multiplexed into the given casting scheme are associated with the DRB.

28. The method of any of embodiments 1-27,wherein the QoS flow that is related to a given casting session is associated with a DRB, andwherein only QoS flows that are associated with the given casting session are associated with the DRB.

29. The method of any of embodiments 1-28,wherein the QoS flow that is related to a given casting session is multiplexed into a DRB, andwherein only QoS flows that are multiplexed into the given casting session are associated with the DRB.

30. The method according to any combination of embodiments 24-29.

31. The method of any of embodiments 1-30, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same V2X service.

32. The method of any of embodiments 1-31, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same casting scheme.

33. The method of any of embodiments 1-32, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same casting session.

34. A user equipment, UE, adapted to perform according to any of Embodiments 1 to 33.

35. A user equipment, UE, comprising:transceiver;a processor coupled to the transceiver; andmemory coupled with the processor, wherein the memory stores instructions that when executed by the processor causes the UE to perform operations according to any of Embodiments 1 to 33.

36. A computer program product, comprising:a non-transitory computer readable storage medium comprising computer readable program code embodied in the medium that when executed by a processor of a user equipment, UE, causes the UE to perform operations according to any of embodiments 1 to 33.

37. A method of operating a network node for providing network assisted sidelink quality of service flow management, method comprising:receiving, from a user equipment, UE, a quality of service, QoS, flow establishment request, the flow establishment request indicating that the QoS flow is to be transmitted over a sidelink;determining whether a required QoS flow will be fulfilled;in response to determining that the required QoS flow will be fulfilled, transmitting a message indicating that a requested sidelink QoS will be supported and transmitting mapping and configuration data corresponding to the sidelink QoS flow; andin response to determining that the required QoS flow may not be fulfilled, transmitting a message indicating that the requested sidelink QoS will not be established.

38. The method of embodiments 37, wherein responsive to determining that the required QoS may not be fulfilled, receiving, from the UE, a QFI corresponding to the requested QoS flow.

39. The method of embodiment 38, further comprising:receiving a QoS flow release request that includes a QoS flow identifier, QFI, that identifies a session corresponding to the sidelink QoS flow; andclearing a relevant QoS flow context, wherein the relevant QoS flow context comprises QFI, QoS profiles, QFI to radio data bearer, DRB, mapping and/or the corresponding DRB.

40. The method of any of embodiments 37-39, wherein the mapping and configuration data are preconfigured by a core network and transmitted to the UE,wherein receiving the QoS flow establishment request comprises receiving the QoS establishment request directly from the UE via radio resource control, RRC, signaling to a gNB, andwherein the QoS establishment request comprises QoS flow related data that was preconfigured and indication that the requested QoS flow will be transmitted over the sidelink QoS flow.

41. The method of any of embodiments 37-40, wherein the mapping and configuration data are preconfigured by a core network and transmitted to the UE,wherein receiving the QoS flow establishment request comprises receiving the QoS establishment request via a NAS message from the core network radio resource control, RRC, signaling to a gNB, andwherein the QoS establishment request comprises QoS flow related data that was preconfigured and indication that the requested QoS flow will be transmitted over the sidelink QoS flow.

42. The method of any of embodiments 37-40, wherein the mapping and configuration data are preconfigured by a core network and transmitted to the UE,wherein receiving the QoS flow establishment request comprises receiving the QoS establishment request via radio resource control, RRC, signaling to a gNB, andwherein the QoS establishment request comprises QoS flow related data that was preconfigured and indication that the requested QoS flow will be transmitted over the sidelink QoS flow.

43. The method of any of embodiments 37-42, wherein receiving the QoS flow establishment request comprises transmitting the release request to a core network, CN, via NAS signaling.

44. The method of embodiment 43, further comprising transmitting an acknowledgement message to the UE via RRC signaling that includes relevant mapping and configurations corresponding to the sidelink QoS flow.

45. The method of any of embodiments 37-44, wherein responsive to determining that the required QoS may not be fulfilled, the method further comprising:transmitting a rejection message via RRC to the UE signaling that the QoS flow request will be rejected, wherein the RRC rejection message comprises the QFI corresponding to the QoS flow; andcausing the UE to update the UE upper layer that the requested sidelink QoS flow is rejected.

46. The method of embodiments 37-45, further comprising:transmitting, to the UE, a release request that includes a QFI corresponding to the sidelink QoS flow;clearing a relevant QoS flow context that includes the QFI, QoS profile, QFI to DRB mapping and/or the corresponding DRB; andreleasing the QoS flow and delete relevant QoS context data.

47. The method of any of embodiments 37-45, wherein responsive to QoS degradation of a sidelink QoS flow, the method further comprises:transmitting a release request that includes a QFI corresponding to the sidelink QoS flow;causing a relevant QoS context in the UE that includes the QFI and/or QoS profile data to be cleared; andreleasing the QoS flow.

48. The method of embodiment 47, wherein transmitting the release request comprises transmitting the release request to a core network, CN, and wherein the core network informs the UE via NAS signaling.

49. The method of embodiment 37-48, wherein in response to determining that no other QoS flows are being used by a same DRB, the release request includes a request to release the DRB.

50. The method of any of embodiments 37-49, further comprising:following a preconfigured admission control rule to determine if the sidelink QoS flow will be fulfilled; andestablishing a sidelink QoS flow responsive to determining that the QoS flow is fulfilled.

51. The method of any of embodiments 37-50, wherein a unicast sidelink QoS flow session comprises a specific V2X traffic session that is transmitted to a specific RX UE.

52. The method of any of embodiments 37-50, wherein a groupcast sidelink QoS flow session comprises a specific V2X traffic session that is transmitted to a specific group of RX UEs.

53. The method of any of embodiments 37-52, further comprising associating the sidelink QoS flow with a plurality of other sidelink QoS flows that correspond to a same V2X service.

54. The method of any of embodiments 37-53, wherein the same V2X service is represented by a unique identifier.

55. The method of any of embodiments 37-54, wherein the same V2X service is associated with a plurality of radio bearers.

56. The method of any of embodiments 37-55, further comprising selecting a plurality of identifiers to represent respective ones of a plurality of sidelink QoS flow sessions.

57. The method of any of embodiments 37 to 56, wherein the service is a vehicle to anything, V2X, service.

58. The method of any of embodiments 37-57,wherein the QoS flow that is related to a given V2X service is associated with a DRB, andwherein only other QoS flows that are related to the given V2X service are associated with the DRB.

59. The method of any of embodiments 37-58,wherein the QoS flow that is related to a given V2X service is multiplexed into a DRB, andwherein only other QoS flows that are related to the given V2X service are multiplexed into the DRB.

60. The method of any of embodiments 37-59,wherein the QoS flow that is related to a given casting scheme is associated with a DRB, andwherein only QoS flows that are associated with the given casting scheme are associated with the DRB.

61. The method of any of embodiments 37-60,wherein the QoS flow that is related to a given casting scheme is multiplexed into a DRB, andwherein only QoS flows that are multiplexed into the given casting scheme are associated with the DRB.

62. The method of any of embodiments 37-61,wherein the QoS flow that is related to a given casting session is associated with a DRB, andwherein only QoS flows that are associated with the given casting session are associated with the DRB.

63. The method of any of embodiments 37-62,wherein the QoS flow that is related to a given casting session is multiplexed into a DRB, andwherein only QoS flows that are multiplexed into the given casting session are associated with the DRB.

64. The method according to any combination of embodiments 58-63.

65. The method of any of embodiments 37-64, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same V2X service.

66. The method of any of embodiments 37-67, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same casting scheme.

67. The method of any of embodiments 37-66, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same casting session.

68. The method according to any combination of embodiments 65-67.

70. A network node adapted to perform according to any of embodiments 37 to 68.

71. A network node comprising:transceiver;a processor coupled to the transceiver; andmemory coupled with the processor, wherein the memory stores instructions that when executed by the processor causes the network node to perform operations according to any of Embodiments 37 to 68.

72. A computer program product, comprising:a non-transitory computer readable storage medium comprising computer readable program code embodied in the medium that when executed by a processor of a network node, causes the network node to perform operations according to any of Embodiments 37 to 68.

73. A method of operating a user equipment, UE, for device-to-device, D2D, communications, the method comprising:storing a preconfigured SL QoS flow management control rule set that defines operations for establishing, by the UE, a SL QoS flow;establishing a SL QoS flow by performing rules in the preconfigured SL QoS flow management control rule set; andresponsive to a determination that the QoS will be fulfilled, establishing, by the UE, the SL QoS flow and mapping the SL QoS flow to a DRB.

74. The method of embodiment 73, wherein the DRB comprises an existing DRB or a new DRB.

75. The method of any of embodiments 73-74, further comprising performing a SL QoS flow release operation.

76. The method of any of embodiments 73-75, wherein the release operation comprises:clearing a QoS flow context and releasing the DRB if no other QoS flows are using the DRB.

77. The method of any of embodiments 73-76,wherein the QoS flow that is related to a given V2X service is associated with a DRB, andwherein only other QoS flows that are related to the given V2X service are associated with the DRB.

78. The method of any of embodiments 73-77,wherein the QoS flow that is related to a given V2X service is multiplexed into a DRB, andwherein only other QoS flows that are related to the given V2X service are multiplexed into the DRB.

79. The method of any of embodiments 73-78,wherein the QoS flow that is related to a given casting scheme is associated with a DRB, andwherein only QoS flows that are associated with the given casting scheme are associated with the DRB.

80. The method of any of embodiments 73-79,wherein the QoS flow that is related to a given casting scheme is multiplexed into a DRB, andwherein only QoS flows that are multiplexed into the given casting scheme are associated with the DRB.

81. The method of any of embodiments 73-80,wherein the QoS flow that is related to a given casting session is associated with a DRB, andwherein only QoS flows that are associated with the given casting session are associated with the DRB.

82. The method of any of embodiments 73-81,wherein the QoS flow that is related to a given casting session is multiplexed into a DRB, andwherein only QoS flows that are multiplexed into the given casting session are associated with the DRB.

82. The method according to any combination of embodiments 73-82.

83. The method of any of embodiments 73-82, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same V2X service.

84. The method of any of embodiments 73-83, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same casting scheme.

85. The method of any of embodiments 73-84, wherein a MAC layer multiplexes into the same MAC PDU as DRBs having QoS flows that are associated with a same casting session.

86. The method according to any combination of embodiments 83-85.

87. A network node adapted to perform according to any of embodiments 37 to 86.

88. A network node comprising:transceiver;a processor coupled to the transceiver; andmemory coupled with the processor, wherein the memory stores instructions that when executed by the processor causes the network node to perform operations according to any of Embodiments 73 to 86.

88. A computer program product, comprising:a non-transitory computer readable storage medium comprising computer readable program code embodied in the medium that when executed by a processor of a network node, causes the network node to perform operations according to any of Embodiments 73 to 86.
Explanations for abbreviations from the above disclosure are provided below.

REFERENCES

Additional explanation is provided below.

FIG.11: A wireless network in accordance with some embodiments.

InFIG.11, network node QQ160includes processing circuitry QQ170, device readable medium QQ180, interface QQ190, auxiliary equipment QQ184, power source QQ186, power circuitry QQ187, and antenna QQ162. Although network node QQ160illustrated in the example wireless network ofFIG.11may represent a device that includes the illustrated combination of hardware components, other embodiments may comprise network nodes with different combinations of components. It is to be understood that a network node comprises any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Moreover, while the components of network node QQ160are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, a network node may comprise multiple different physical components that make up a single illustrated component (e.g., device readable medium QQ180may comprise multiple separate hard drives as well as multiple RAM modules).

Processing circuitry QQ170is configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being provided by a network node. These operations performed by processing circuitry QQ170may include processing information obtained by processing circuitry QQ170by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination.

Processing circuitry QQ170may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node QQ160components, such as device readable medium QQ180, network node QQ160functionality. For example, processing circuitry QQ170may execute instructions stored in device readable medium QQ180or in memory within processing circuitry QQ170. Such functionality may include providing any of the various wireless features, functions, or benefits discussed herein. In some embodiments, processing circuitry QQ170may include a system on a chip (SOC).

In some embodiments, processing circuitry QQ170may include one or more of radio frequency (RF) transceiver circuitry QQ172and baseband processing circuitry QQ174. In some embodiments, radio frequency (RF) transceiver circuitry QQ172and baseband processing circuitry QQ174may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry QQ172and baseband processing circuitry QQ174may be on the same chip or set of chips, boards, or units.

In certain embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB or other such network device may be performed by processing circuitry QQ170executing instructions stored on device readable medium QQ180or memory within processing circuitry QQ170. In alternative embodiments, some or all of the functionality may be provided by processing circuitry QQ170without executing instructions stored on a separate or discrete device readable medium, such as in a hard-wired manner. In any of those embodiments, whether executing instructions stored on a device readable storage medium or not, processing circuitry QQ170can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry QQ170alone or to other components of network node QQ160, but are enjoyed by network node QQ160as a whole, and/or by end users and the wireless network generally.

Interface QQ190is used in the wired or wireless communication of signalling and/or data between network node QQ160, network QQ106, and/or WDs QQ110. As illustrated, interface QQ190comprises port(s)/terminal(s) QQ194to send and receive data, for example to and from network QQ106over a wired connection. Interface QQ190also includes radio front end circuitry QQ192that may be coupled to, or in certain embodiments a part of, antenna QQ162. Radio front end circuitry QQ192comprises filters QQ198and amplifiers QQ196. Radio front end circuitry QQ192may be connected to antenna QQ162and processing circuitry QQ170. Radio front end circuitry may be configured to condition signals communicated between antenna QQ162and processing circuitry QQ170. Radio front end circuitry QQ192may receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. Radio front end circuitry QQ192may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ198and/or amplifiers QQ196. The radio signal may then be transmitted via antenna QQ162. Similarly, when receiving data, antenna QQ162may collect radio signals which are then converted into digital data by radio front end circuitry QQ192. The digital data may be passed to processing circuitry QQ170. In other embodiments, the interface may comprise different components and/or different combinations of components.

In certain alternative embodiments, network node QQ160may not include separate radio front end circuitry QQ192, instead, processing circuitry QQ170may comprise radio front end circuitry and may be connected to antenna QQ162without separate radio front end circuitry QQ192. Similarly, in some embodiments, all or some of RF transceiver circuitry QQ172may be considered a part of interface QQ190. In still other embodiments, interface QQ190may include one or more ports or terminals QQ194, radio front end circuitry QQ192, and RF transceiver circuitry QQ172, as part of a radio unit (not shown), and interface QQ190may communicate with baseband processing circuitry QQ174, which is part of a digital unit (not shown).

Antenna QQ162, interface QQ190, and/or processing circuitry QQ170may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by a network node. Any information, data and/or signals may be received from a wireless device, another network node and/or any other network equipment. Similarly, antenna QQ162, interface QQ190, and/or processing circuitry QQ170may be configured to perform any transmitting operations described herein as being performed by a network node. Any information, data and/or signals may be transmitted to a wireless device, another network node and/or any other network equipment.

Power circuitry QQ187may comprise, or be coupled to, power management circuitry and is configured to supply the components of network node QQ160with power for performing the functionality described herein. Power circuitry QQ187may receive power from power source QQ186. Power source QQ186and/or power circuitry QQ187may be configured to provide power to the various components of network node QQ160in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source QQ186may either be included in, or external to, power circuitry QQ187and/or network node QQ160. For example, network node QQ160may be connectable to an external power source (e.g., an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry QQ187. As a further example, power source QQ186may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry QQ187. The battery may provide backup power should the external power source fail. Other types of power sources, such as photovoltaic devices, may also be used.

Alternative embodiments of network node QQ160may include additional components beyond those shown inFIG.11that may be responsible for providing certain aspects of the network node's functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, network node QQ160may include user interface equipment to allow input of information into network node QQ160and to allow output of information from network node QQ160. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node QQ160.

As illustrated, wireless device QQ110includes antenna QQ111, interface QQ114, processing circuitry QQ120, device readable medium QQ130, user interface equipment QQ132, auxiliary equipment QQ134, power source QQ136and power circuitry QQ137. WD QQ110may include multiple sets of one or more of the illustrated components for different wireless technologies supported by WD QQ110, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention a few. These wireless technologies may be integrated into the same or different chips or set of chips as other components within WD QQ110.

Antenna QQ111may include one or more antennas or antenna arrays, configured to send and/or receive wireless signals, and is connected to interface QQ114. In certain alternative embodiments, antenna QQ111may be separate from WD QQ110and be connectable to WD QQ110through an interface or port. Antenna QQ111, interface QQ114, and/or processing circuitry QQ120may be configured to perform any receiving or transmitting operations described herein as being performed by a WD. Any information, data and/or signals may be received from a network node and/or another WD. In some embodiments, radio front end circuitry and/or antenna QQ111may be considered an interface.

As illustrated, interface QQ114comprises radio front end circuitry QQ112and antenna QQ111. Radio front end circuitry QQ112comprise one or more filters QQ118and amplifiers QQ116. Radio front end circuitry QQ114is connected to antenna QQ111and processing circuitry QQ120, and is configured to condition signals communicated between antenna QQ111and processing circuitry QQ120. Radio front end circuitry QQ112may be coupled to or a part of antenna QQ111. In some embodiments, WD QQ110may not include separate radio front end circuitry QQ112; rather, processing circuitry QQ120may comprise radio front end circuitry and may be connected to antenna QQ111. Similarly, in some embodiments, some or all of RF transceiver circuitry QQ122may be considered a part of interface QQ114. Radio front end circuitry QQ112may receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. Radio front end circuitry QQ112may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ118and/or amplifiers QQ116. The radio signal may then be transmitted via antenna QQ111. Similarly, when receiving data, antenna QQ111may collect radio signals which are then converted into digital data by radio front end circuitry QQ112. The digital data may be passed to processing circuitry QQ120. In other embodiments, the interface may comprise different components and/or different combinations of components.

Processing circuitry QQ120may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and/or encoded logic operable to provide, either alone or in conjunction with other WD QQ110components, such as device readable medium QQ130, WD QQ110functionality. Such functionality may include providing any of the various wireless features or benefits discussed herein. For example, processing circuitry QQ120may execute instructions stored in device readable medium QQ130or in memory within processing circuitry QQ120to provide the functionality disclosed herein.

As illustrated, processing circuitry QQ120includes one or more of RF transceiver circuitry QQ122, baseband processing circuitry QQ124, and application processing circuitry QQ126. In other embodiments, the processing circuitry may comprise different components and/or different combinations of components. In certain embodiments processing circuitry QQ120of WD QQ110may comprise a SOC. In some embodiments, RF transceiver circuitry QQ122, baseband processing circuitry QQ124, and application processing circuitry QQ126may be on separate chips or sets of chips. In alternative embodiments, part or all of baseband processing circuitry QQ124and application processing circuitry QQ126may be combined into one chip or set of chips, and RF transceiver circuitry QQ122may be on a separate chip or set of chips. In still alternative embodiments, part or all of RF transceiver circuitry QQ122and baseband processing circuitry QQ124may be on the same chip or set of chips, and application processing circuitry QQ126may be on a separate chip or set of chips. In yet other alternative embodiments, part or all of RF transceiver circuitry QQ122, baseband processing circuitry QQ124, and application processing circuitry QQ126may be combined in the same chip or set of chips. In some embodiments, RF transceiver circuitry QQ122may be a part of interface QQ114. RF transceiver circuitry QQ122may condition RF signals for processing circuitry QQ120.

In certain embodiments, some or all of the functionality described herein as being performed by a WD may be provided by processing circuitry QQ120executing instructions stored on device readable medium QQ130, which in certain embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by processing circuitry QQ120without executing instructions stored on a separate or discrete device readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a device readable storage medium or not, processing circuitry QQ120can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry QQ120alone or to other components of WD QQ110, but are enjoyed by WD QQ110as a whole, and/or by end users and the wireless network generally.

Processing circuitry QQ120may be configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being performed by a WD. These operations, as performed by processing circuitry QQ120, may include processing information obtained by processing circuitry QQ120by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored by WD QQ110, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination.

Device readable medium QQ130may be operable to store a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry QQ120. Device readable medium QQ130may include computer memory (e.g., Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device readable and/or computer executable memory devices that store information, data, and/or instructions that may be used by processing circuitry QQ120. In some embodiments, processing circuitry QQ120and device readable medium QQ130may be considered to be integrated. User interface equipment QQ132may provide components that allow for a human user to interact with WD QQ110. Such interaction may be of many forms, such as visual, audial, tactile, etc. User interface equipment QQ132may be operable to produce output to the user and to allow the user to provide input to WD QQ110. The type of interaction may vary depending on the type of user interface equipment QQ132installed in WD QQ110. For example, if WD QQ110is a smart phone, the interaction may be via a touch screen; if WD QQ110is a smart meter, the interaction may be through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alert (e.g., if smoke is detected). User interface equipment QQ132may include input interfaces, devices and circuits, and output interfaces, devices and circuits. User interface equipment QQ132is configured to allow input of information into WD QQ110, and is connected to processing circuitry QQ120to allow processing circuitry QQ120to process the input information. User interface equipment QQ132may include, for example, a microphone, a proximity or other sensor, keys/buttons, a touch display, one or more cameras, a USB port, or other input circuitry. User interface equipment QQ132is also configured to allow output of information from WD QQ110, and to allow processing circuitry QQ120to output information from WD QQ110. User interface equipment QQ132may include, for example, a speaker, a display, vibrating circuitry, a USB port, a headphone interface, or other output circuitry. Using one or more input and output interfaces, devices, and circuits, of user interface equipment QQ132, WD QQ110may communicate with end users and/or the wireless network, and allow them to benefit from the functionality described herein.

Power source QQ136may, in some embodiments, be in the form of a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic devices or power cells, may also be used. WD QQ110may further comprise power circuitry QQ137for delivering power from power source QQ136to the various parts of WD QQ110which need power from power source QQ136to carry out any functionality described or indicated herein. Power circuitry QQ137may in certain embodiments comprise power management circuitry. Power circuitry QQ137may additionally or alternatively be operable to receive power from an external power source; in which case WD QQ110may be connectable to the external power source (such as an electricity outlet) via input circuitry or an interface such as an electrical power cable. Power circuitry QQ137may also in certain embodiments be operable to deliver power from an external power source to power source QQ136. This may be, for example, for the charging of power source QQ136. Power circuitry QQ137may perform any formatting, converting, or other modification to the power from power source QQ136to make the power suitable for the respective components of WD QQ110to which power is supplied.

FIG.12: User Equipment in accordance with some embodiments

InFIG.12, UE QQ200includes processing circuitry QQ201that is operatively coupled to input/output interface QQ205, radio frequency (RF) interface QQ209, network connection interface QQ211, memory QQ215including random access memory (RAM) QQ217, read-only memory (ROM) QQ219, and storage medium QQ221or the like, communication subsystem QQ231, power source QQ233, and/or any other component, or any combination thereof. Storage medium QQ221includes operating system QQ223, application program QQ225, and data QQ227. In other embodiments, storage medium QQ221may include other similar types of information. Certain UEs may utilize all of the components shown inFIG.12, or only a subset of the components. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

RAM QQ217may be configured to interface via bus QQ202to processing circuitry QQ201to provide storage or caching of data or computer instructions during the execution of software programs such as the operating system, application programs, and device drivers. ROM QQ219may be configured to provide computer instructions or data to processing circuitry QQ201. For example, ROM QQ219may be configured to store invariant low-level system code or data for basic system functions such as basic input and output (I/O), startup, or reception of keystrokes from a keyboard that are stored in a non-volatile memory. Storage medium QQ221may be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, or flash drives. In one example, storage medium QQ221may be configured to include operating system QQ223, application program QQ225such as a web browser application, a widget or gadget engine or another application, and data file QQ227. Storage medium QQ221may store, for use by UE QQ200, any of a variety of various operating systems or combinations of operating systems.

InFIG.12, processing circuitry QQ201may be configured to communicate with network QQ243busing communication subsystem QQ231. Network QQ243aand network QQ243bmay be the same network or networks or different network or networks. Communication subsystem QQ231may be configured to include one or more transceivers used to communicate with network QQ243b. For example, communication subsystem QQ231may be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication such as another WD, UE, or base station of a radio access network (RAN) according to one or more communication protocols, such as IEEE 802.QQ2, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, or the like. Each transceiver may include transmitter QQ233and/or receiver QQ235to implement transmitter or receiver functionality, respectively, appropriate to the RAN links (e.g., frequency allocations and the like). Further, transmitter QQ233and receiver QQ235of each transceiver may share circuit components, software or firmware, or alternatively may be implemented separately.

The features, benefits and/or functions described herein may be implemented in one of the components of UE QQ200or partitioned across multiple components of UE QQ200. Further, the features, benefits, and/or functions described herein may be implemented in any combination of hardware, software or firmware. In one example, communication subsystem QQ231may be configured to include any of the components described herein. Further, processing circuitry QQ201may be configured to communicate with any of such components over bus QQ202. In another example, any of such components may be represented by program instructions stored in memory that when executed by processing circuitry QQ201perform the corresponding functions described herein. In another example, the functionality of any of such components may be partitioned between processing circuitry QQ201and communication subsystem QQ231. In another example, the non-computationally intensive functions of any of such components may be implemented in software or firmware and the computationally intensive functions may be implemented in hardware.

FIG.13: Virtualization environment in accordance with some embodiments

In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments QQ300hosted by one or more of hardware nodes QQ330. Further, in embodiments in which the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node), then the network node may be entirely virtualized.

The functions may be implemented by one or more applications QQ320(which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operative to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. Applications QQ320are run in virtualization environment QQ300which provides hardware QQ330comprising processing circuitry QQ360and memory QQ390. Memory QQ390contains instructions QQ395executable by processing circuitry QQ360whereby application QQ320is operative to provide one or more of the features, benefits, and/or functions disclosed herein.

Virtualization environment QQ300, comprises general-purpose or special-purpose network hardware devices QQ330comprising a set of one or more processors or processing circuitry QQ360, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device may comprise memory QQ390-1which may be non-persistent memory for temporarily storing instructions QQ395or software executed by processing circuitry QQ360. Each hardware device may comprise one or more network interface controllers (NICs) QQ370, also known as network interface cards, which include physical network interface QQ380. Each hardware device may also include non-transitory, persistent, machine-readable storage media QQ390-2having stored therein software QQ395and/or instructions executable by processing circuitry QQ360. Software QQ395may include any type of software including software for instantiating one or more virtualization layers QQ350(also referred to as hypervisors), software to execute virtual machines QQ340as well as software allowing it to execute functions, features and/or benefits described in relation with some embodiments described herein.

Virtual machines QQ340, comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer QQ350or hypervisor. Different embodiments of the instance of virtual appliance QQ320may be implemented on one or more of virtual machines QQ340, and the implementations may be made in different ways.

During operation, processing circuitry QQ360executes software QQ395to instantiate the hypervisor or virtualization layer QQ350, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer QQ350may present a virtual operating platform that appears like networking hardware to virtual machine QQ340.

As shown inFIG.13, hardware QQ330may be a standalone network node with generic or specific components. Hardware QQ330may comprise antenna QQ3225and may implement some functions via virtualization. Alternatively, hardware QQ330may be part of a larger cluster of hardware (e.g. such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) QQ3100, which, among others, oversees lifecycle management of applications QQ320.

In the context of NFV, virtual machine QQ340may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of virtual machines QQ340, and that part of hardware QQ330that executes that virtual machine, be it hardware dedicated to that virtual machine and/or hardware shared by that virtual machine with others of the virtual machines QQ340, forms a separate virtual network elements (VNE).

Still in the context of NFV, Virtual Network Function (VNF) is responsible for handling specific network functions that run in one or more virtual machines QQ340on top of hardware networking infrastructure QQ330and corresponds to application QQ320inFIG.13.

In some embodiments, one or more radio units QQ3200that each include one or more transmitters QQ3220and one or more receivers QQ3210may be coupled to one or more antennas QQ3225. Radio units QQ3200may communicate directly with hardware nodes QQ330via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station.

In some embodiments, some signalling can be effected with the use of control system QQ3230which may alternatively be used for communication between the hardware nodes QQ330and radio units QQ3200.

With reference toFIG.14, in accordance with an embodiment, a communication system includes telecommunication network QQ410, such as a 3GPP-type cellular network, which comprises access network QQ411, such as a radio access network, and core network QQ414. Access network QQ411comprises a plurality of base stations QQ412a, QQ412b, QQ412c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area QQ413a, QQ413b, QQ413c. Each base station QQ412a, QQ412b, QQ412cis connectable to core network QQ414over a wired or wireless connection QQ415. A first UE QQ491located in coverage area QQ413cis configured to wirelessly connect to, or be paged by, the corresponding base station QQ412c. A second UE QQ492in coverage area QQ413ais wirelessly connectable to the corresponding base station QQ412a. While a plurality of UEs QQ491, QQ492are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station QQ412.

Telecommunication network QQ410is itself connected to host computer QQ430, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. Host computer QQ430may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections QQ421and QQ422between telecommunication network QQ410and host computer QQ430may extend directly from core network QQ414to host computer QQ430or may go via an optional intermediate network QQ420. Intermediate network QQ420may be one of, or a combination of more than one of, a public, private or hosted network; intermediate network QQ420, if any, may be a backbone network or the Internet; in particular, intermediate network QQ420may comprise two or more sub-networks (not shown).

The communication system ofFIG.14as a whole enables connectivity between the connected UEs QQ491, QQ492and host computer QQ430. The connectivity may be described as an over-the-top (OTT) connection QQ450. Host computer QQ430and the connected UEs QQ491, QQ492are configured to communicate data and/or signaling via OTT connection QQ450, using access network QQ411, core network QQ414, any intermediate network QQ420and possible further infrastructure (not shown) as intermediaries. OTT connection QQ450may be transparent in the sense that the participating communication devices through which OTT connection QQ450passes are unaware of routing of uplink and downlink communications. For example, base station QQ412may not or need not be informed about the past routing of an incoming downlink communication with data originating from host computer QQ430to be forwarded (e.g., handed over) to a connected UE QQ491. Similarly, base station QQ412need not be aware of the future routing of an outgoing uplink communication originating from the UE QQ491towards the host computer QQ430.

FIG.15: Host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference toFIG.15. In communication system QQ500, host computer QQ510comprises hardware QQ515including communication interface QQ516configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system QQ500. Host computer QQ510further comprises processing circuitry QQ518, which may have storage and/or processing capabilities. In particular, processing circuitry QQ518may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Host computer QQ510further comprises software QQ511, which is stored in or accessible by host computer QQ510and executable by processing circuitry QQ518. Software QQ511includes host application QQ512. Host application QQ512may be operable to provide a service to a remote user, such as UE QQ530connecting via OTT connection QQ550terminating at UE QQ530and host computer QQ510. In providing the service to the remote user, host application QQ512may provide user data which is transmitted using OTT connection QQ550.

Communication system QQ500further includes base station QQ520provided in a telecommunication system and comprising hardware QQ525enabling it to communicate with host computer QQ510and with UE QQ530. Hardware QQ525may include communication interface QQ526for setting up and maintaining a wired or wireless connection with an interface of a different communication device of communication system QQ500, as well as radio interface QQ527for setting up and maintaining at least wireless connection QQ570with UE QQ530located in a coverage area (not shown inFIG.15) served by base station QQ520. Communication interface QQ526may be configured to facilitate connection QQ560to host computer QQ510. Connection QQ560may be direct or it may pass through a core network (not shown inFIG.15) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, hardware QQ525of base station QQ520further includes processing circuitry QQ528, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Base station QQ520further has software QQ521stored internally or accessible via an external connection.

Communication system QQ500further includes UE QQ530already referred to. Its hardware QQ535may include radio interface QQ537configured to set up and maintain wireless connection QQ570with a base station serving a coverage area in which UE QQ530is currently located. Hardware QQ535of UE QQ530further includes processing circuitry QQ538, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. UE QQ530further comprises software QQ531, which is stored in or accessible by UE QQ530and executable by processing circuitry QQ538. Software QQ531includes client application QQ532. Client application QQ532may be operable to provide a service to a human or non-human user via UE QQ530, with the support of host computer QQ510. In host computer QQ510, an executing host application QQ512may communicate with the executing client application QQ532via OTT connection QQ550terminating at UE QQ530and host computer QQ510. In providing the service to the user, client application QQ532may receive request data from host application QQ512and provide user data in response to the request data. OTT connection QQ550may transfer both the request data and the user data. Client application QQ532may interact with the user to generate the user data that it provides.

It is noted that host computer QQ510, base station QQ520and UE QQ530illustrated inFIG.15may be similar or identical to host computer QQ430, one of base stations QQ412a, QQ412b, QQ412cand one of UEs QQ491, QQ492ofFIG.14, respectively. This is to say, the inner workings of these entities may be as shown inFIG.15and independently, the surrounding network topology may be that ofFIG.14.

InFIG.15, OTT connection QQ550has been drawn abstractly to illustrate the communication between host computer QQ510and UE QQ530via base station QQ520, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from UE QQ530or from the service provider operating host computer QQ510, or both. While OTT connection QQ550is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

Wireless connection QQ570between UE QQ530and base station QQ520is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments may improve the performance of OTT services provided to UE QQ530using OTT connection QQ550, in which wireless connection QQ570forms the last segment. More precisely, the teachings of these embodiments may improve the deblock filtering for video processing and thereby provide benefits such as improved video encoding and/or decoding.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring OTT connection QQ550between host computer QQ510and UE QQ530, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring OTT connection QQ550may be implemented in software QQ511and hardware QQ515of host computer QQ510or in software QQ531and hardware QQ535of UE QQ530, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which OTT connection QQ550passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software QQ511, QQ531may compute or estimate the monitored quantities. The reconfiguring of OTT connection QQ550may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect base station QQ520, and it may be unknown or imperceptible to base station QQ520. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating host computer QQ510's measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that software QQ511and QQ531causes messages to be transmitted, in particular empty or ‘dummy’ messages, using OTT connection QQ550while it monitors propagation times, errors etc.

FIG.16is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference toFigures QQ4and QQ5. For simplicity of the present disclosure, only drawing references toFIG.16will be included in this section. In step QQ610, the host computer provides user data. In substep QQ611(which may be optional) of step QQ610, the host computer provides the user data by executing a host application. In step QQ620, the host computer initiates a transmission carrying the user data to the UE. In step QQ630(which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step QQ640(which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

FIG.18is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference toFigures QQ4and QQ5. For simplicity of the present disclosure, only drawing references toFIG.18will be included in this section. In step QQ810(which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step QQ820, the UE provides user data. In substep QQ821(which may be optional) of step QQ820, the UE provides the user data by executing a client application. In substep QQ811(which may be optional) of step QQ810, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in substep QQ830(which may be optional), transmission of the user data to the host computer. In step QQ840of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.