WO2023143729A1

WO2023143729A1 - Device and method for correlated qos treatment cross multiple flows

Info

Publication number: WO2023143729A1
Application number: PCT/EP2022/052030
Authority: WO
Inventors: Qing Wei; Hanwen Cao
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-01-28
Filing date: 2022-01-28
Publication date: 2023-08-03

Abstract

The present disclosure relates to entities and methods for handling a flow group with inter-dependency in a network. Each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies. The disclosure proposes a control plane network entity that is configured to, for each RAN entity, determine, based on the different importance levels and/or different dependencies of the plurality of frames, priority information of one or more frame groups related to the RAN entity, wherein each frame group comprises frames of multiple flows of the flow group, and provide the priority information of the one or more frame groups to the related RAN entity. Further, the disclosure proposes a RAN entity being configured to obtain such priority information and perform resource scheduling for the one or more frame groups based on that.

Description

DEVICE AND METHOD FOR CORRELATED QoS TREATMENT CROSS MULTIPLE FLOWS

TECHNICAL FIELD

The present disclosure relates to communication networks, and particularly to resource coordination for packet flows in communication networks. In order to improve the radio resource usage efficiency, and to provide a better service experience for users, the disclosure proposes a correlated Quality of Service (QoS) treatment of frames across multiple flows comprising a plurality of frames each. To this end, the disclosure proposes a control plane entity, a radio access network (RAN) entity, and corresponding methods, for handling at least one flow group of flows.

BACKGROUND

Various new video-based media services are emerging with the advancement of telecommunication technologies, for example: Cloud VR/AR, Cloud gaming, 4K/8K VoD, Video-based remote control, or machine vision. Such services require not only high bandwidth, but also a short End-to-End (E2E) latency and high communication reliability. For instance, the consumption of VR content via a tethered VR headset requires a maximum of 5-10 ms E2E latency, 0.1-10Gbit/s service bit rate, and 99.99% reliability (3GPP TS 22.261 vl8.2.0). The transfer of such type of service traffic is challenging, especially in mobile networks, due to the limited radio resource and dynamic radio conditions.

SUMMARY

To reduce the required bandwidth, in order to transfer a video stream, various compression technologies have been studied for a long time. For instance, H.264 compresses the video stream by exploring the temporal/spatial dependency of the packets in video traffic. H.265 and other video codecs further improve the video compression/coding efficiency. Still, the basic principle of the video codec does not change, and the dependency between the video packets is maintained. For instance, some of the slices or pictures or frames (i.e., a group of video packets) in a video stream may be coded without reference to any other slices or pictures or frames (e.g., reference frames), while some of the slices or pictures or frames reference other slices or pictures or frames for decoding and/or prediction (e.g., dependent frames). For the sake of simplicity, all the “slices”, “pictures”, “group of packets”, are referred to as “frames” in this disclosure. Due to the mentioned dependency between the frames, QoS fulfillment of different packets in a video stream will cause different impairs to the service experience of the user. Layered coding is another type of data compression for digital video or digital audio, wherein the result of compressing the source video data is not just one compressed data stream, but comprises multiple data streams - so called layers - allowing decompression even if some layers are missing. In multiple QoS flows, a frame of one QoS flow may be coded with reference to a frame in another QoS flow. Due to such dependency between frames, QoS fulfillment of different frames in different QoS flows will cause different impairments to the service experience of the user as well. For instance, packet error and/or loss in a reference frame, to which other frames reference, will affect the decoding of the other dependent frames. Failing to deliver the packets of a reference frame on time would cause the decoding and/or prediction error of the dependent frames.

The current mobile networks manage and control the QoS of communication services per QoS flow. They do, however, not support the QoS treatment in a frame granularity within a video stream, or the QoS treatment across multiple video streams.

A differentiated QoS treatment within a QoS flow could be explicitly defined per packet, for example, a data packet could be marked with a “type” (e.g., frame type) and specified by the application layer a certain treatment of such type of data packet. In conventional solutions, differentiated treatment for packets of the same type of frame is not possible. For example, some solutions may drop all dependent frames (e.g., P-frame) in case of radio resource shortage. This could be harmful in some situations. Further, some solutions may define that the reference frames always have higher priority than a dependent frame. Another solution proposes to reallocate significant video data within a unit of inter-frame dependency during the coding phase, and then transmit the encoded video with different transmission priorities on a per-packet basis depending on the packet’s significance for decoding. In principle, this solution is based on prioritized packet dropping. Low priority packets (i.e., dependent frames or slices) are dropped instead of high priority packets (e.g., reference frames or slices) in case of radio resource shortage.

One solution proposes to police individual flows and sub-flows of a data stream. Sub-flows may be further classified into additional sub-flows. Another solution proposes to merge sub flows based on traffic rate thresholds. However, these solutions are either limited to the QoS control in flow granularity, or limited to frame-level QoS control within a certain QoS flow. This would waste the mobile network resource or affect the user experience during the network resource shortage, since the resource may be given to the dependent frames instead of their reference frames in some other flows without the awareness of cross-flow frame dependency.

An improved solution, which can support dynamic resource coordination for packets transmission between different frames or slices in a QoS flow, is desired.

In view of the above, this disclosure has the objective to introduce a solution to support dependent frame treatment across multiple QoS flows in a mobile network. Another objective is a QoS treatment scheme that is based on frame dependency and flow dependency across multiple flows in the mobile network. Another objective is to achieve a higher efficiency of radio resource usage, and a better Quality of Experience (QoE). A further objective is to reduce the transmission delay and power consumption.

These and other objectives are achieved by the solution of the present disclosure as provided in the enclosed independent claims. Advantageous implementations are further defined in the dependent claims.

A first aspect of the disclosure provides a control plane network entity for assisting the handling of a flow group by one or more RAN entities, wherein each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies, and wherein the flow group comprises a baseline flow and one or more other flows that depend on the baseline flow, wherein the control plane network entity is configured to, for each RAN entity of the one or more RAN entities: determine, based on the different importance levels and/or different dependencies of the plurality of frames, priority information of one or more frame groups related to the RAN entity, wherein each frame group comprises frames of multiple flows of the flow group; and provide the priority information of the one or more frame groups to the related RAN entity.

This disclosure proposes a solution to control QoS treatment of video frames in multiple QoS flows in the mobile network, wherein dependency information across multiple QoS flows can be considered. This solution may be realized by introducing new functionality into the mobile network, e.g., implemented at a Policy Control Function (PCF) or implemented partially at the PCF and partially at a Session Management Function (SMF). It may be worth mentioning that the plurality of frames decribed here are frames related to an application or a communication service. For simplicity, this may be referred to as “related to an application” in the following part of this application.

In this disclosure, a “frame” refers to a group of packets at the application layer, which has similar importance for the application and requires similar QoS treatment in the network. For example, the frame could be a video frame or slice, alternatively an audio frame or slice. A frame may also be named Media Unit (MU) in this application. The frames can be grouped into a frame group across multiple QoS flows. It should be noted that an application may define multiple frame groups. For instance, for a periodical traffic pattern such as a Group of Picture (GOP) structure, multiple periodical frame groups may be defined. The obtained priority information of one or more frame groups related to the RAN entity, which may also be referred to as cross flow (X-flow) priority information per RAN in this disclosure, is provided to the involved RAN entity. This allows the RAN entity to perform resource management and scheduling using the X-flow priority information of the frame groups.

In an implementation form of the first aspect, the priority information of the one or more frame groups related to the RAN entity comprises first frame group information and first frame priority information, wherein the first frame group information comprises information about the one or more frame groups related to the RAN entity, and the first frame priority information comprises priority information of each frame of the one or more frame groups related to the RAN entity.

In an implementation form of the first aspect, the control plane network entity is configured to determine the first frame group information and the related RAN entity based on second frame group information comprising information about one or more frame groups related to an application.

For instance, an Application Function (AF) may provide X-flow frame group information and/or frame priority information to the PCF by using the existing procedure of “Setting up an AF session with required QoS“ per-flow per application. The PCF may identify the flows of the same flow group based on the X-flow frame group information from the AF, and may further calculate the X-flow frame group information per group and per RAN, and also the frame priority information per group and per RAN.

In an implementation form of the first aspect, the second frame group information comprises one or more of the following: an identity of the application, a group window and/or a group size of one or more frame groups related to the application, an identity of a flow group related to the application, an identity of a flow of the flow group related to the application, an indication of a baseline flow of the flow group related to the application, and/or the first frame group information comprises one or more of the following: the identity of the application, a group window and/or a group size of the one or more frame groups related to the RAN entity, an indication of a baseline flow of the flow group related to the RAN entity, an identity of a flow group related to the RAN entity, an identity of a flow of the flow group related to the RAN entity.

Optionally, the second frame group information discussed here may be the X-flow frame group information provided from the AF. The contents of X-flow frame group information may be the same to the second frame group information. Possibly, there may be only one flow group related to the application, which may be split into multiple flow groups each related to a respective RAN.

In an implementation form of the first aspect the group window of a frame group is indicated by using one or more of the following: a burst starting time of a first frame of the frame group, a burst starting time of a last frame of the frame group, an identity of a first frame in a baseline flow of the frame group, an identity of a last frame in a baseline flow of the frame group, a type of a first frame in a baseline flow of the frame group, a type of a last frame in a baseline flow of the frame group, an identity of a first frame in all flows of the frame group, an identity of a last frame in all flows of the frame group, a type of a first frame in all flows of the frame group, a type of a last frame in all flows of the frame group.

In an implementation form of the first aspect, determining the first frame group information and the related RAN entity based on the second frame group information comprises: identifying flows of a same flow group based on an identity of the flow group related to the application or an identity of a flow of the flow group related to the application; identifying one or more RAN entities serving the flow group related to the application; identifying a baseline flow based on an identity of a baseline flow or a priority level of a flow of the flow group related to the application; and calculating information about the flow group related to each of the one or more RAN entities.

In an implementation form of the first aspect, the control plane network entity is further configured to determine the first frame priority information based on second frame priority information related to the application and the first frame group information.

The control plane network entity may determine X-flow priority information of a frame group in different manners. Details will be explained in a later part of this disclosure.

In an implementation form of the first aspect, the second frame priority information comprises one or more of the following: an identity of a flow group related to the application, an identity of a flow of the flow group, a flow priority of each flow in the flow group, a set of indicators indicating the different importance levels and/or different dependencies of the plurality of frames in the flow; and/or the first frame priority information comprises one or more of the following: an identity of a frame, a priority of the frame in a flow group related to the RAN entity.

Optionally, the second frame priority information discussed here may be the X-flow frame priority information provided from the AF. The contents of X-flow frame priority information may be the same to the second frame priority information. Optionally, the set of indicators may indicate a type of each frame. For example, frame type “I” indicates a independent frame, frame type”P” indicates a dependent frame. Optionally, the set of indicators may indicate a GOP structure (M, N), where the frame type could be derived from the GOP structure.

In an implementation form of the first aspect, determining the first frame priority information based on second frame priority information and the first frame group information comprises calculating the priority of the frame based on a frame priority of that frame in the flow, and the set of indicators.

In an implementation form of the first aspect, the control plane network entity is configured to obtain the second frame group information and/or the second frame priority information from an application function, or via a Network Exposure Function (NEF), and/or a User Data Repository (UDR).

Optionally, the application layer entity may provide the frame group information or the frame priority information of the flow group, to the PCF via the NEF and/or UDR.

In an implementation form of the first aspect, the control plane network entity is further configured to split the flow group into a first sub flow group related to a first RAN entity and a second sub flow group related to a second RAN entity; determine priority information of one or more frame groups related to the first RAN entity, and provide the priority information of the one or more frame groups to the first RAN entity; and determine priority information of one or more frame groups related to the second RAN entity, and provide the priority information of the one or more frame groups to the second RAN entity.

Optionally, the control plane network entity may split one application traffic flow into multiple QoS flows according to different importance of the packets, and/or may aggregate multiple QoS flows into one traffic flow again, when the traffic flow leaves mobile network. The control plane network entity may also split one X-flow group into multiple sub X-flow groups, wherein each sub-x-flow group is processed at the same RAN resource management/scheduling entity.

In an implementation form of the first aspect, the control plane network entity comprises a PCF or a PCF together with a SMF.

That is, the proposed control plane network entity may be realized by introducing new functionality in the mobile network, e.g., at the PCF and/or SMF.

A second aspect of the disclosure provides a RAN entity for handling a flow group, wherein the flow group comprises a plurality of frames with different importance levels and/or different dependencies, and wherein the flow group comprises a baseline flow and one or more other flows depending on the baseline flow, and wherein the RAN entity is configured to: obtain priority information of one or more frame groups related to the RAN entity, wherein each frame group comprises frames of multiple flows of the flow group, and wherein the priority information indicates the different importance levels and/or different dependencies of the plurality of frames of each frame group; and perform resource scheduling for the one or more frame groups based on the priority information of one or more frame groups.

Another aspect of this disclosure proposes a RAN processing based on X-flow frame priority information. This disclosure further proposes a solution for performing resource management and scheduling on frame groups based on the cross flow frame priority information. Such information may be obtained from a control plane network entity. This solution may be realized by introducing new functionality at a Radio Access Node.

In an implementation form of the second aspect, the priority information of the one or more frame groups related to the RAN entity comprises first frame group information and first frame priority information, wherein the first frame group information comprises information about the one or more frame groups related to the RAN entity, and the first frame priority information comprises priority information of each frame of the one or more frame groups related to the RAN entity.

In an implementation form of the second aspect, the first frame group information comprises one or more of the following: an identity of an application, a group window and/or a group size of the one or more frame groups related to the RAN entity, and an indication of a baseline flow of the flow group related to the RAN entity, an identity of a flow group related to the RAN entity, an identity of a flow of the flow group related to the RAN entity.

In an implementation form of the second aspect, the first frame priority information comprises one or more of the following: an identity of a frame, a priority of the frame in a flow group related to the RAN entity.

In an implementation form of the second aspect, performing resource scheduling for the one or more frame groups comprises one or more of the following: scheduling a resource for packet transmissions in a frame group together; scheduling a resource for packet transmission in a frame group in the order of frame priority in the frame group; dropping a remaining transmission of a frame group if a packet in the transmission is not successfully transmitted; and dropping or preempting a transmission of frames with lower priorities in a frame group in case of resource shortage. Notably, this disclosure allows for selective packet dropping based on frame dependency cross flows instead of random dropping. It also supports temporary resource coordination between packets with frame dependency cross flows. In this way, a better service experience for the user in case of radio resource shortage or disturbances, and less delay and jitter, can be assured. According to the proposed approach, radio resource usage in case of radio resource shortage is more efficient. Transmission of useless packets can be avoided.

In an implementation form of the second aspect, wherein dropping the remaining transmission comprises: identifying a frame, to which the packet belongs, based on the first frame group information; determining priority information of the frame based on the first frame priority information, and determining a frame group, to which the frame belongs, based on the first frame group information; identifying other packets that belong to the frame and other frames in the frame group with a lower priority than a priority of the frame; and dropping the identified packets and frames.

A third aspect of the disclosure provides a control plane network entity for assisting the handling of a flow group by one or more RAN entities, wherein each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies, and wherein the flow group comprises a baseline flow and one or more other flows that depend on the baseline flow, wherein the method comprises, for each RAN entity of the one or more RAN entities: determining, based on the different importance levels and/or different dependencies of the plurality of frames, priority information of one or more frame groups related to the RAN entity, wherein each frame group comprises frames of multiple flows of the flow group; and providing the priority information of the one or more frame groups to the related RAN entity.

Implementation forms of the method of the third aspect may correspond to the implementation forms of the control plane network entity of the first aspect described above. The method of the third aspect and its implementation forms achieve the same advantages and effects as described above for the control plane network entity of the first aspect and its implementation forms.

A fourth aspect of the disclosure provides a method for handling a flow group, each flow of the flow group comprising a plurality of frames with different importance levels and/or different dependencies, wherein the flow group comprises a baseline flow and one or more other flows depending on the baseline flow, wherein the method comprises: obtaining priority information of one or more frame groups related to the RAN entity, wherein each frame group comprises frames cross multiple flows of the flow group, and wherein the priority information indicates the different importance levels and/or different dependenciesof the plurality of frames of each frame group; and performing resource scheduling for the one or more frame groups based on the priority information of one or more frame groups.

Implementation forms of the method of the fourth aspect may correspond to the implementation forms of the RAN entity of the second aspect described above. The method of the fourth aspect and its implementation forms achieve the same advantages and effects as described above for the RAN entity of the second aspect and its implementation forms.

A fifth aspect of the disclosure provides a computer program product comprising a program code for carrying out, when implemented on a processor, the method according to the third aspect and any implementation forms of the third aspect, or the fourth aspect and any implementation forms of the fourth aspect.

A sixth aspect of the disclosure provides a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out, the method according to the third aspect and any implementation forms of the third aspect, or the fourth aspect and any implementation forms of the fourth aspect.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which:

FIG. 1 shows an example of multiple streams in layered coding;

FIG. 2 shows a principle for mapping application layer packets to QoS flows in an example of a mobile network;

FIG. 3 shows a control plane network entity according to an embodiment of this disclosure;

FIG. 4 shows a RAN entity according to an embodiment of this disclosure;

FIG. 5 shows two examples of frame group information according to an embodiment of this disclosure;

FIG. 6 shows an example of resource scheduling according to an embodiment of this disclosure;

FIG. 7 shows an example of resource scheduling according to an embodiment of this disclosure;

FIG. 8 shows a system architecture according to an embodiment of this disclosure;

FIG. 9 shows a signaling chart for setting up an AF session according to an embodiment of this disclosure;

FIG. 10 shows a signaling chart for setting a policy for a future AF session according to an embodiment of this disclosure;

FIG. 11 shows a signaling chart of a policy association modification procedure according to an embodiment of this disclosure;

FIG. 12 shows a signaling chart of a Protocol Data Unit (PDU) session modification procedure according to an embodiment of this disclosure;

FIG. 13 shows a signaling chart of a PDU session modification procedure according to an embodiment of this disclosure;

FIG. 14 shows examples of frame grouping according to an embodiment of this disclosure;

FIG. 15 shows an example of flow splitting according to an embodiment of this disclosure;

FIG. 16 shows an example of flow splitting according to an embodiment of this disclosure; FIG. 17 shows a flow chart of transmission decision according to an embodiment of this disclosure;

FIG. 18 shows a method according to an embodiment of this disclosure; and

FIG. 19 shows a method according to an embodiment of this disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

Illustrative embodiments of a control plane network entity, a RAN entity, and corresponding methods for handling and assisting the handling of a flow group are described in the following with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment or example may refer to other embodiments or examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment or example is applicative to the other embodiments or examples.

For ease of understanding, an example of frames with dependency is first explained here. For example, H.264 introduces the concept of Group of Picture (GOP) with different types of video pictures/frames. Intra-coded (I) frames contain an entire image. They are coded without reference to any other frame. Predicted (P) frames reference to proceeding pictures for decoding/prediction. There can be multiple previously decoded pictures as references during decoding. Bi-directional predicted (B) frames reference both proceeding and subsequent frame(s) to be displayed. Layered Coding (e.g., Scalable Video Coding (SVC), MPEG-5 Low Complexity Enhancement Video Coding (LCEVC)), is another type of data compression for digital video or digital audio where the result of compressing the source video data is not just one compressed data stream, but multiple data streams, called layers, allowing decompression even if some layers are missing.

FIG. 1 shows an example of layer coding where enhanced layers 1 and 2 are independent to each other while both depend on the base layer. In the mobile network (e.g., 5G system), the base layer can be transferred in a QoS flow with more stringent QoS requirements and the enhanced layer can be transferred in a QoS flow with relaxed QoS requirements. Meanwhile, the enhanced layer 1 and enhanced layer 2 can be transferred in separate QoS flows following different paths through the mobile network for better redundancy. In such case of multiple QoS flows, a frame (e.g., Enhanced I-frame or Enhanced P-frame) may be coded with reference to a frame (e.g., correspondent I-frame or P-frame) in another QoS flow. Due to such dependency between frames, QoS fulfillment of different frames in different QoS flows will cause different impairments to the service experience of the user. E.g., packet error/loss in the first P frame in the base layer will affect the decoding of the follow-up P frame as well as the correspondent EP frames in Enhanced layer 1 and Enhanced layer 2.

As shown in FIG. 2, application/service layer packets are mapped into QoS flows using a packet filter. Each QoS flow is bound to a QoS Profile (which is derived from the application layer service requirements). The network entities (e.g., RAN, SMF) treat each QoS flow separately according to the corresponding QoS Profile.

A differentiated QoS treatment within a QoS flow could be explicitly defined per packet. For example, a data packet could be marked with a “type” and specified by the application layer a certain treatment of such type of data packet. For instance, in a conventional solution, the application may mark the undiscardable frame (e.g., I-frame/slice), discardable frame, starting/ending of a frame in an extension field in the RTP header. In another solution, it is proposed that the application provides to the CPFs of the mobile network an indication of whether different packets within a data flow require differentiated treatment. For such solutions, differentiated treatment for packets for the same type of frame/slice is not possible. For example, the first solution may drop all the B/P frames in case of radio resource shortage, although dropping the first P-frame and unaffected B-frame in a GOP may not be necessary if the transmission error happens only during the transmission of the second P-frame, or would be more harmful comparing to drop a later P-frame. In the second solution, it may define that P-frame/slice always has a higher priority than a B-frame/slice. The packet treatment at the RAN level is limited to the “dropping” of a pre-defined type of packets (e.g., with low priority, or marked with “discardable”) in case of radio resource shortage.

However, these solutions are either limited to the QoS control in flow granularity or limited to frame-level QoS control within a certain QoS flow. This would waste the mobile network resource or affect the user experience during the network resource shortage, since the resource may be given to the dependent frames instead of their reference frames in some other flows. This disclosure introduces a QoS treatment that considers frame dependencies across multiple flows in the mobile network, thereby achieving higher resource usage efficiency and better Quality of Experience (QoE).

FIG. 3 shows a control plane network entity 300 adapted for assisting the handling of a flow group by one or more RAN entities 400. In particular, each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies. The flow group comprises a baseline flow and one or more other flows that depend on the baseline flow.

In this disclosure, frame refers to a group of packets at the application layer, which has similar importance for the application and requires the same level of QoS treatment in the network. It could be e.g., a video frame/slice, audio frame/slice. A frame may be considered as an equivalent to a media unit (MU) as also used in this application.

The plurality of frames in a flow may have inter-dependency. For instance, some frames, which may be referred to as dependent frames, may depend on other frames. Frames that other frames depend on may be referred to as reference frames. It should be understood that a reference frame, on which another frame has a dependency, may also have a dependency on another reference frame.

The control plane network entity 300 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the control plane network entity 300 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multipurpose processors. The control plane network entity 300 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the control plane network entity 300 to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the control plane network entity 300 to perform, conduct or initiate the operations or methods described herein.

The control plane network entity 300 is configured to, for each RAN entity 400 of the one or more RAN entities, determine, based on the different importance levels and/or different dependencies of the plurality of frames related to an application, priority information 301 of one or more frame groups related to the RAN entity 400 (e.g., shown in FIG. 4 or 6). Notably, each frame group comprises frames of multiple flows of the flow group. The control plane network entity 300 is further configured to provide the priority information 301 of the one or more frame groups to the related RAN entity 400.

Notably, in this disclosure, the frames or MUs are grouped into MU/frame group cross multiple QoS flows. This disclosure proposes an apparatus to determine cross flow frame priority information (may also named as X-Flow frame priority information in this application) in the 5G System (5GS).

Further, this disclosure proposes an apparatus for providing necessary information to the RAN entity 400 and thus may possibly assist the RAN entity 400 in a real-time resource management and scheduling. The RAN entity 400 may be the RAN entity shown in FIG. 4 or FIG. 8. This may be realized by introducing new functionality at the PCF or SMF.

In this disclosure, the control plane network entity 300 may obtain cross flow frame priority information from an application. Further, it may identify the involved RAN entity, and may derive the cross flow frame priority information per RAN entity. Then it may provide the cross flow frame priority information to each involved RAN entity. In a 5G mobile network, the control plane network entity 300 may be the PCF or SMF. It may interact with the application via AF. Details will be explained in the following description.

Optionally, the priority information 301 of the one or more frame groups related to the RAN entity 400 comprises first frame group information and first frame priority information. The first frame group information comprises information about the one or more frame groups related to the RAN entity 400. The first frame priority information comprises priority information of each frame of the one or more frame groups related to the RAN entity 400. According to an embodiment of the disclosure, the control plane network entity 300 may be configured to determine the first frame group information and the related RAN entity 400 based on second frame group information comprising information about one or more frame groups related to an application.

Optionally, the second frame group information comprises one or more of the following: an identity of the application, a group window and/or a group size of one or more frame groups related to the application, an identity of a flow group related to the application, an identity of a flow of the flow group related to the application, an indication of a baseline flow of the flow group related to the application.

Optionally, the first frame group information comprises one or more of the following:

- the identity of the application, a group window and/or a group size of the one or more frame groups related to the RAN entity 400, an indication of a baseline flow of the flow group related to the RAN entity 400, an identity of a flow group related to the RAN entity 400, an identity of a flow of the flow group related to the RAN entity 400.

According to an embodiment of this disclosure, determining the first frame group information and the related RAN entity 400 based on the second frame group information may comprise:

- identifying flows of a same flow group based on an identity of the flow group related to the application or an identity of a flow of the flow group related to the application;

- identifying one or more RAN entities serving the flow group related to the application;

- identifying a baseline flow based on an identity of a baseline flow or a priority level of a flow of the flow group related to the application; and calculating information about the flow group related to each of the one or more RAN entities. For example, the one or more RAN entities serving the flow group related to the application may be identified based on the associated serving RAN information of the identified flows in the flow group.

According to an embodiment of the disclosure, the control plane network entity 300 may be configured to determine the first frame priority information based on second frame priority information related to the application and the first frame group information.

For instance, this functionality can be performed by the PCF, or the PCF together with the SMF based on the information from the application layer. It may comprise the following two types of processing:

1. Conversion from per application frame priority information (i.e., frame group and frame priority) to per RAN frame priority info: a. Determine sub frame group(s)/sub flow group per RAN (details will be explained in a later part of this application, e.g., see FIG. 16), b. Determine the baseline flow in each sub frame group/sub flow group (e.g., the flow with the highest priority in the sub flow group), c. Normalize the x-flow priority information of each sub frame group to its baseline flow.

2. Conversion between per flow frame priority information representation and per group frame priority information representation.

The control plane of 5GS (i.e., the control plane network entity 300, e.g., PCF/SMF) obtains the X-flow priority information of a frame group per application, e.g., from AF or from UDR. Based on that, the control plane network entity 300 determines the X-flow priority information of a frame group for each RAN node for related QoS treatment at RAN.

The control plane network entity 300 performs also conversion between “flow-based” and “group-based” information representation in different scenarios. For example, a video layer/flow can be added or deleted dynamically by the AR/VR server using per-flow QoS interaction with 5GS (flow-based). In such cases, the control plane network entity 300 needs to combine the QoS information received for individual flows into a group to determine the X- flow priority information of a frame group. Alternatively, the application may provide a default codec configuration (e.g., GOP structure, periodicity) as X-flow priority information. In such cases, the X-flow priority information is for a group of flows, therefore called “group-based”. When providing the determined X-flow priority information of a frame group per RAN node to RAN, the control plane network entity 300 may covert “group-based” information again to “flow-based” information so that the current 3GPP QoS procedure could be reused and avoid the additional message.

For example, the detailed procedure is as follows in the 5GS:

At first, PCF/SMF determines the Frame group information per RAN according to the following steps

- PCF obtains Frame group information per application, e.g.,

• [application ID, group window/group size*, baseline flow ID/indication, flow group ID/flow ID(s) in the group per application]

- PCF/SMF determines Frame group information in 5GS per RAN node, e.g.,

• [RAN ID, application ID, group time window/group size, baseline flow ID, flow group ID/ flow ID(s) in the group per RAN]

SMF calculates the timing information for RAN in Frame group information in 5GS, e.g.,

• [RAN ID, application ID, group time window for RAN/group size, flow group ID, flow ID(s) in the group per RAN]

SMF provides Frame group information with the calculated timing information to RAN.

Secondly, PCF/SMF or RAN calculates the Frame priority per group according to the following steps:

PCF/SMF or RAN may obtain Frame priority information per flow, e.g.,

• [flow ID: flow group ID, flow priority in the flow group, (set of) frame priorities in the flow],

- PCF/SMF or RAN calculates the Frame priority information per group based on frame group information in 5GS and Frame priority information per flow, e.g.,

• Frame priority information per group = frame priority in the flow + flow priority in the flow group. Notably, the group window can be indicated by burst starting time or the type of the first/last frame in the baseline flow of the frame group. Group size could be represented by the number of burst in baseline flow of the frame group. Flow priority could be implemented using Address Resolution Protocol (ARP). Flow priority could be used to implicitly indicate the baseline flow (e.g., the one with the highest priority in the group, or the one with priority “1” in the group).

Optionally, the second frame priority information may comprise one or more of the following: an identity of a flow group related to the application, an identity of a flow of the flow group, a flow priority of each flow in the flow group, a set of indicators indicating the different importance levels and/or different dependencies of the plurality of frames in the flow.

Optionally, the first frame priority information may comprise one or more of the following: an identity of a frame, and a priority of the frame in a flow group related to the RAN entity 400.

For instance, the control plane network entity 300 may calculate the priority of the frame based on a frame priority of that frame in the flow, and the set of indicators.

Optionally, the control plane network entity 300 may be configured to obtain the second frame group information and/or the second frame priority information from an AF, or via a NEF, and/or a UDR.

Optionally, the control plane network entity 300 may be configured to split the flow group into a first sub flow group related to a first RAN entity and a second sub flow group related to a second RAN entity. Accordingly, the control plane network entity 300 may be further configured to determine priority information of one or more frame groups related to the first RAN entity, and provide the priority information of the one or more frame groups to the first RAN entity. Likewise, the control plane network entity 300 may be further configured to determine priority information of one or more frame groups related to the second RAN entity, and provide the priority information of the one or more frame groups to the second RAN entity. Optionally, the control plane network entity 300 comprises a PCF or a PCF together with a SMF.

FIG. 4 shows a RAN entity 400 adapted for handling a flow group. Each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies. In particular, the flow group comprises a baseline flow and one or more other flows depending on the baseline flow.

The RAN entity 400 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the RAN entity 400 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field- programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The RAN entity 400 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the RAN entity 400 to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non- transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the RAN entity 400 to perform, conduct or initiate the operations or methods described herein.

In particular, the RAN entity 400 is configured to obtain priority information 301 of one or more frame groups related to the RAN entity 400, possibly from a control plane network entity 300 (e.g., as shown in FIG. 3). Each frame group comprises frames of multiple flows of the flow group. The priority information indicates the different importance levels and/or different dependencies of the plurality of frames of each frame group. The RAN entity 400 is further configured to perform resource scheduling for the one or more frame groups based on the priority information 301 of one or more frame group.

This disclosure further proposes a solution for performing resource management and scheduling on frame groups based on the cross flow frame priority information. Such information may be obtained from a control plane network entity 300. This solution may be realized by introducing new functionality at a Radio Access Node. The control plane network entity 300 shown in FIG. 4 may be the control plane network entity 300 shown of FIG. 3.

Optionally, the priority information 301 of the one or more frame groups related to the RAN entity 400 comprises first frame group information and first frame priority information. The first frame group information comprises information about the one or more frame groups related to the RAN entity 400. The first frame priority information comprises priority information of each frame of the one or more frame groups related to the RAN entity 400.

The RAN entity 400 may require the following X-flow priority information of a frame group for priority-based resource allocation and scheduling:

1. X-flow frame group (detection) information to detect an X-flow frame group, which may require one or more of the following:

- Flow ID(s), or a Flow group ID (used to identify a group of flows),

- Baseline flow ID,

X-flow Frame group ID, or Flow ID(s) + Frame group ID(s) in each flow (used to uniquely identify a group of frames),

Group window, which could be represented by one of the following:

• Burst starting time of the first frame and/or burst starting time of the last frame and/or group size (i.e., number of burst/frames) in baseline flow,

• Burst starting time of the first frame and/or burst starting time of the last frame and/or group size (i.e., number of burst/frames) of all flows in the flow group,

• Frame ID/frame type of the first and/or the last frame in baseline flow,

• Frame ID/frame type of the first and/or the last frame in all flows in the flow group.

2. Frame priority information, which may comprise:

- Frame identity, which could be presented by one of the following:

• Frame ID, or frame type, or frame order, or frame type + frame order.

- Frame priority, which could be presented by one of the following:

• Priority of each frame in the frame group of each flow + flow priority, or Priority of each frame in the x-flow frame group.

For instance, the implementation of X-flow priority INFO of a frame group could be:

- Frame group ID; (sets of) [flow ID, frame ID, frame priority]

[Flow group ID, baseline flow ID, frame ID/type of the first frame of the group in baseline flow, group window ; (sets of) [flow ID, frame type, frame priority]

Notably, the frame type could be “I”, “P”. Flow priority and frame priority may be indicated by an integer, for instance, a lower value indicates a higher priority.

FIG. 5 shows two examples of X-flow frame group (detection) information according to embodiments of the disclosure. In these two examples, a flow group includes flows x, y, z, wherein the baseline flow = flow x.

The first example use “type based” frame group information, i.e., Starting frame type = “I”, which may be indicated as shown in FIG. 5 (a). Optionally, frame information may include a “Frame type “using a type indication, e.g., type 1, type 2, or “I”, “P”, “B” . “Frame type” may be derived by the PCF based on the information provided by the AF about the service and its traffic characteristics. Possibly, the “frame type” may also be referred to as the “application layer type” of the frame.

The second example use “time based” frame group information, i.e., Burst starting time of the first frame in the group= tl, Burst starting time of the last frame in the group= t2/group size = 3, may be indicated as shown in FIG. 5 (b).

As discussed in previous embodiments, the priority information 301 of the one or more frame groups related to the RAN entity 400 comprises first frame group information and first frame priority information. The first frame group information comprises information about the one or more frame groups related to the RAN entity 400. The first frame priority information comprises priority information of each frame of the one or more frame groups related to the RAN entity 400.

According to an embodiment of the disclosure, performing resource scheduling for the one or more frame groups comprises one or more of the following: scheduling a resource for packet transmissions in a frame group together; scheduling a resource for packet transmission in a frame group in the order of frame priority in the frame group; dropping a remaining transmission of a frame group if a packet in the transmission is not successfully transmitted; dropping or preempting a transmission of frames with lower priorities in a frame group in case of resource shortage.

Examples of resource allocation and scheduling will be discussed in a later part of the application, e.g., see FIG. 6 and FIG. 7. It may be worth mentioning that the RAN entity 400 may determine to drop all packets of dependent frames with lower priorities in a frame group which are useless for the application due to the failed transmission of a reference frame, thus avoiding the waste of resources.

According to an embodiment of the disclosure, dropping the remaining transmission comprises:

- identifying a frame, to which the packet belongs, based on the first frame group information; determining priority information of the frame based on the first frame priority information, and determining a frame group, to which the frame belongs, based on the first frame group information;

- identifying other packets that belong to the frame and other frames in the frame group with a lower priority than a priority of the frame; and dropping the identified packets and frames.

This aspect of the disclosure describes how the RAN entity 400 processes based on X-flow priority information. This may include the following steps:

1. RAN identifies frames in a flow using Frame information (E.g., Frame ID, Frame type, Frame sequence number) carried in the packet header or by observing the time interval between consecutive packets.

2. RAN identifies the frame group of a frame using Cross flow frame group information, may including:

RAN obtains the flow ID, flow/frame group ID and Frame information from the video packets header (e.g., flow ID (QFI), a bit indicating the frame type or start of a frame, Frame ID) and/or by counting the burst (e.g., Frame sequence number, Frame order).

- RAN measures the burst starting/ending time of certain frames in multiple flows.

- RAN compares the measured time and/or the obtained ID/type information with the Cross flow frame group information to drive a frame group.

3. For each frame in a frame group, RAN performs resource scheduling and admission control using Frame priority information. For example, RAN may admit/schedule only the high priority frames in case of resource shortage.

FIG. 6 shows examples of resource allocation and scheduling with and without considering frame priority according to an embodiment of this disclosure.

FIG. 6 (a) shows resource blocks for flow transmission without considering the flow priority. It can be seen that once a packet transmission fails, i.e., packet 2 of Baseline flow, resources for transmission packet 3 of Baseline flow are released.

Notably, the numbering here may indicate an order of priority or importance of the packets in a frame. For example, packet 2 has a higher priority than packet 3 in the same frame. This may indicate that packet 3 may depend on packet 2. Therefore, once packet 2 of a frame fails, resource blocks for transmission packet 3 of the same frame can be released, as even if packet 3 is successfully transmitted, it may not be correctly decoded as packet 2 is missing. Latency of successful transmission of all the packets in a frame is as indicated in FIG. 6 (a).

FIG. 6 (b) shows a resource block for flow transmission considering the cross flow priority. It can be seen that once the same packet 2 of Baseline flow fails, resource blocks for transmission of packet 3 of Baseline flow, and also the transmission of packet 3 and packet 4 of Enhanced layer flow, are released. Latency of successful transmission of all the packets in a frame is as indicated in FIG. 6 (b).

Notably, Enhanced layer flow has a dependency on Baseline flow. Considering the cross flow priority, once a packet with higher priority from a Baseline flow frame fails, packets with lower priorities from an Enhanced layer flow frame may not be correctly decoded even if they are successfully transmitted. Therefore, resource blocks scheduled for these packets can be released to save resources.

FIG. 6 (c) shows a resource block for flow transmission considering the cross flow priority and also an order of frames. In this case, resource blocks are first scheduled for packet 1 (with the highest priority) from Baseline flow, then scheduled for packet 2 from Enhanced layer flow (with the highest priority among packets from Enhanced layer flow). Similar as FIG. 6 (b), once the same packet 2 of Baseline flow fails, resource blocks for transmission of packet 3 of Baseline flow, and also the transmission of packet 3 and packet 4 of Enhanced layer flow, are released. It can be seen that in such a way of resource allocation, not only more resources can be saved, but also a lower latency is achieved.

In this way, a better service experience for the user in case of radio resource shortage or disturbances can be assured. For instance, this disclosure allows for selective packet dropping based on frame dependency cross flows instead of random dropping, temporary resource coordination between packets with Frame dependency cross flows, and less delay and jitter. According to the proposed approach, radio resource usage in case of radio resource shortage is more efficient. Transmission of useless packets can be avoided, therefore the radio resource can be saved without impacts to the application Quality of Experience (QoE).

FIG. 7 shows resource blocks for flow transmission without considering synchronizing the transmission of the packets of the same group. In particular, the RAN entity 400 can schedule a resource for packet transmissions in a frame group together. In this way, the packets of the same group but different flows can be transmitted in the same time slots, thereby reducing the total transmission time of a frame group. As shown in FIG. 7, this approach allows the UE to go to Discontinuous Reception (DRX) / Discontinuous Transmission (DTX) sleeping mode during the saved time.

It should be noted that the proposed frame grouping and prioritizing mechanism reuses the existing QoS control procedure in 3GPP 5GS. Such design minimizes the system impacts and avoids additional signal overhead.

FIG. 8 shows a high-level system view of this disclosure in one example scenario. The AR/VR server located at an edge cloud is streaming the video packets in multiple flows to a client located at the UE via the 5G System (5GS). 5GS comprises the Application Function (AF), NEF/UDR, PCF/SMF, RAN, UPF(s), and UE, e.g., as specified in TS23.501. The AR/VR server interacts with the control plane NEs of 5GS (i.e., PCF, SMF, NEF, UDR, etc.) via AF. The AR/VR server sends the video data to AR/VR client via the data plane NEs of 5GS (i.e., UPF, RAN, UE, etc ).

This disclosure includes two aspects. The first aspect is about the methods to group, synchronize, identify and prioritize the MUs in multiple flows in a mobile network. This is realized by introducing new functionality in the mobile network (e.g., at PCF/SMF). This aspect includes also the methods and related enhancements of mobile network entities (e.g., AF, NEF, UDR) to obtain the related information from the application layer for x-flow MU grouping and prioritizing.

The second aspect describes how RAN could perform resource management and scheduling using the x-flow MU group and MU priority information. This aspect includes also the methods and related enhancements of RAN to obtain the x-flow MU group and priority information.

The PCF/SMF shown in FIG. 8 may be the control plane network entity 300 of FIG. 3. The RAN shown in FIG. 8 may be the RAN entity 400 of FIG. 4. The corresponding signaling between AF, PCF, and RAN are discussed in a later part of the description. FIG. 9 and FIG. 10 describe two options for the control plane network entity 300, e.g., the PCF, to obtain the X-Flow priority information from the application and related messages and procedures in a 5G mobile network, according to embodiments of this disclosure.

Option 1 : obtain the X-Flow priority information from AF/NEF:

AF provides X-flow frame group information and/or Frame priority information to PCF using the existing procedure of “Setting up an AF session with required QoS“ per-flow per application. This may include: PCF identifies the flows of the same flow group using Flow group ID and the baseline flow using baseline flow indication, and PCF calculates the X-flow frame group information per group per RAN and also the Frame priority information per group per RAN.

FIG. 9 shows signaling for setting up an AF session with the required QoS procedure. AF provides X-flow frame group information and Frame priority information to the PCF using the existing procedure.

1. The AF sends a request to reserve resources for an AF session using Nnef AFsessionWithQoS Create request message (AF Identifier, UE address, Flow description(s), QoS reference, (optional) Alternative Service Requirements (containing one or more QoS reference parameters in prioritized order), Flow group ID, baseline flow indication, Flow priority, Frame group window, (set of) Frame priority information to the NEF. Optionally, a period of time or a traffic volume for the requested QoS can be included in the AF request. The NEF assigns a Transaction Reference ID to the Nnef AFsessionWithQoS Create request.

2. The NEF authorizes the AF request and may apply policies to control the overall amount of pre-defined QoS authorized for the AF. If the authorization is not granted, steps 3 and 4 are skipped and the NEF replies to the AF with a Result value indicating that the authorization failed.

3. The NEF interacts with the PCF by triggering a Npcf PolicyAuthorization Create request and provides AF Identifier, UE address, Flow description(s), the QoS reference, and the optional Alternative Service Requirements (containing one or more QoS reference parameters in a prioritized order, Flow group ID, baseline flow indication, Flow priority, Frame group window, (set of) Frame priority information. Any optionally received period of time or traffic volume is also included and mapped to sponsored data connectivity information (as defined in TS 23.203).

The AF may send Nnef AFsessionWithQoS Revoke request to NEF in order to revoke the AF request. The NEF authorizes the revoke request and triggers the Npcf PolicyAuthorization Delete and the Npcf PolicyAuthorization Unsubscribe operations for the AF request.

Option 2: obtain the X-Flow priority information from both the AF/NEF and UDR:

FIG. 10 shows signaling of setting a policy for a future AF session. The control plane entity 300 (PCF) may obtain some of the X-Flow priority information from the application via NEF and UDR (e.g., if that information is relatively static for that application, or if that information applies to a group of flows). AF provides some of the Frame group information, Frame priority information for a future AF session in UDR. PCF subscribes to UDR on certain application using application ID. PCF may combine information received via UDR and information received directly from AF via NEF (as indicated in Option 1).

Table 1 lists Frame QoS criteria and frame dependency information for application A.

Table 1 Option 3 : PCF obtains the X-Flow priority information from UDR only.

In this option, X-Flow priority information can also be completely pre-configured at the UDR (e.g., by a management entity). In such a case, the interaction between UDR and AF is not needed.

In the following, procedure and signaling for the provision of X-Flow priority information from PCF to RAN (in a 5G mobile network) are discussed.

The control plane entity 300 (i.e., PCF) provides the X-Flow priority information per group per RAN of the flow group to the RAN entity 400 with the QoS profile of each QoS flow using the existing Session management (SM) policy association procedure.

SMF obtains the X-Flow frame priority information from the PCF using the SMF policy association establishment/modification procedure as shown in FIG. 11.

In step 1, PCF gets the trigger message from AF (possibly via NEF) (step la) or UDR (step lb). In step 2, PCF decides to provide SMF the X-Flow frame priority information. In step 3, the X- Flow frame priority information with the associated QoS flow ID (QFI) is sent to SMF using a Npcf_SMPolicyControl_UpdateNotify request message.

SMF further provides X-Flow priority information to RAN using PDU session establishment/modification procedure as shown in FIG. 12.

Step 1 may use the procedure described above in FIG. 11, i.e., SMF gets the policy (including the X-Flow frame priority information) from PCF on the PDU session. In step 2, SMF may trigger UPF resource adjustment according to the policy from PCF (including X-flow frame priority information for the related QFI(s)). In steps 3-6, SMF triggers RAN resource adjustment according to the policy from PCF. For instance, in step 3, SMF provides (set of) X- flow frame priority information together with the corresponding QFI(s) to AMF as part of N2 SM information, AMF provides the N2 SM information further to RAN in step 4. In steps 5 and 6, RAN adjusts the resource accordingly and provides the response to AMF. In alternative implementations, SMF may also obtain the X-flow frame priority information from the PCF using SMF policy association establishment (FIG. 13 (a)) or modification (FIG. 13 (b)) procedure as shown in FIG. 13. In alternative implementations, SMF may also provide the X-flow frame priority information to RAN via AMF using the PDU session establishment procedure.

According to an embodiment of the disclosure, some of the X-Flow priority information (perflow) (e.g., frame group, frame priority per-flow) could be provided by application in Time Sensitive Communications (TSC) Assistance Information (TSCAI) to the RAN. Some of the information in the TSCAI can be further adjusted by PCF (e.g., frame priority) or SMF (e.g., frame group starting time) when passing to the RAN. For example, the X-Flow priority information may be implemented as parameters in TSCAI, as shown in Table 2.

Table 2 According to an embodiment of this disclosure, the frame group can be set to different sizes based on the application requirements as examples shown in FIG. 14. For instance, group size can be 1 as shown in FIG. 14 (a), or maybe the size of GOP as shown in FIG. 14 (b). Possibly, the number of frames included in a frame group could be different in different flows, i.e., the frame group may have different frames rate in each flow, as shown in FIG. 14 (c).

According to an embodiment of this disclosure, a 5G system may split one application traffic flow into multiple QoS flows according to different importance of the packets and aggregate multiple QoS flows into one traffic flow again when the traffic flow leaves the 5G network. As the example shown in FIG. 15, the QoS flow of P-frames may be separated from the QoS flow of I-frames.

In this case, PCF instead of the application may decide on how to split the application traffic flow into multiple flows, and instructs SMF to configure the traffic split, marking and aggregation. RAN obtains the cross flow priority information of a frame group from the PCF/SMF (e.g., as part of PCF policy instead of a transparent container from the AF).

Optionally, PCF/SMF may split one x-flow group into multiple sub X-flow groups, where each sub-x-flow group is processed at the same RAN resource managem ent/scheduling entity. FIG. 16 shows an example that two sub flow groups, one related to BS1 and the other one related to BS2, are obtained from one flow group.

As discussed in the previous embodiments, with the related priority information of the one or more frame groups, the RAN entity 400 may perform resource management and scheduling based thereof. Examples are discussed as follows.

According to an embodiment of the disclosure, the RAN entity 400 (i.e., RAN) may use the related priority information of the one or more frame groups for downlink radio resource scheduling.

For instance, a stream with 3 video flows is transmitted from the AR/VR server to the UE, where flow 1 comprises base layer frames (i.e., the baseline flow), flow 2 and 3 comprises enhanced layer frames with the same frame rate of flow 1. RAN may get the burst starting time, and periodicity of each flow from the SMF (e.g., using TSCAI). RAN may get the X-flow priority information [Frame group; frame priority] from the PCF via SMF, e.g.,

[Flow group = (flow 1, flow 2, flow 3), baseline flow = 1, type of the first frame of the group in the flow = “I” or “El”, group window = 3;

[flow 1, frame ID = 1, priority=l; frame ID =2, priority = 2; frame ID = 3, priority = 3]

[flow 2, frame ID = 1, priority=2; frame ID =2, priority = 3; frame ID = 3, priority = 4]

[flow 3, frame ID = 1, priority=2; frame ID =2, priority = 3; frame ID = 3, priority = 4]

Step 1 :

For each downlink video packet in a flow, RAN obtains the flow ID in the packet header. RAN identifies whether it is an I-frame by intercepting the packet header. For example, in Real-time Transport Protocol (RTP), a bit may be used for indicating an I-frame. When UPF detects an I- firame, it may also mark that in the GTP-U header). RAN identifies the frame ID by counting the burst starting from the I-frame.

Step 2:

RAN maps the obtained flow ID, frame type, frame ID to a frame group using the Frame group information from the PCF. RAN identifies the priority of a group of video packets using the Frame priority information from the PCF.

Step 3 :

RAN schedules the resource for downlink transmission of a frame group (e.g., including corresponding frames in 3 video flows) based on X-flow priority information, burst starting time, and periodicity information. In case of resource variation or shortage, RAN may adjust the resource scheduling of the corresponding flows to drop/preempt the transmission of low priority frames in a frame group.

According to an embodiment of the disclosure, the RAN entity 400 (i.e., RAN) may use the related priority information of the one or more frame groups for uplink radio resource scheduling.

Step 1 :

For each UL video flows in a flow group, RAN calculates the timing information of each frame in a frame group based on Frame group information from the PCF and TSCAI from SMF. RAN maps the timing information of each frame in a group to flow ID(s) and frame ID(s). RAN identifies the priority of a group of video packets using the Frame priority information from the PCF.

Step 2:

RAN schedules the resource for uplink transmission of a frame group (e.g., including corresponding frames in 3 video flows) based on X-flow priority information, and frame timing information. RAN provides the scheduling information of multiple flows to UE using RRC (e.g., semi-persistence scheduling). In case of resource variation or shortage, RAN may adjust the resource scheduling of the corresponding flows to drop/preempt the transmission of low priority frames in a frame group, and update the UE accordingly.

According to an embodiment of the disclosure, the RAN entity 400 (i.e., RAN) may use the related priority information of the one or more frame groups for making packet transmission decisions.

For instance, in case of failed transmission of downlink packet(s) in a flow (e.g., no ACK received in a pre-defined time period or after a maximum allowed Automatic Repeated Request (ARQ) is exceeded), RAN can drop the transmission of the not yet transmitted packets (e.g., in the transmission queue or even not received yet) in the same X-flow frame group to save the radio resource. FIG. 17 shows an example flow chart of such implementation. FIG. 18 shows a method 1800 according to an embodiment of the disclosure, particularly for assisting the handling of a flow group by one or more RAN entities. Notably, each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies, and the flow group comprises a baseline flow and one or more other flows that depend on the baseline flow. In a particular embodiment, the method 1800 is performed by the control plane network entity 300 shown in FIG. 3. The method 1800 comprises a step 1801 of determining, based on the different importance levels and/or different dependencies of the plurality of frames, priority information 301 of one or more frame groups related to the RAN entity 400. Each frame group comprises frames of multiple flows of the flow group. The method 1800 further comprises a step 1802 of providing the priority information 301 of the one or more frame groups to the related RAN entity 400. Possibly, the RAN entity 400 is the RAN entity shown in FIG. 4 or FIG. 8.

FIG. 19 shows a method 1900 according to an embodiment of the disclosure, particularly for handling of a flow group by one or more RAN entities. Notably, each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies, and the flow group comprises a baseline flow and one or more other flows that depend on the baseline flow. In a particular embodiment, the method 1900 is performed by a RAN entity 400 shown in FIG. 4. The method 1900 comprises a step 1901 of obtaining priority information 301 of one or more frame groups related to the RAN entity 400. Each frame group comprises frames cross multiple flows of the flow group, and the priority information indicates the different importance levels and/or different dependencies of the plurality of frames of each frame group. Possibly, the priority information 301 of one or more frame groups related to the RAN entity 400 is obtained from a control plane network entity 300. The method 1900 comprises a step 1902 of performing resource scheduling for the one or more frame groups based on the priority information of one or more frame groups. Possibly, the control plane network entity 300 is the control plane network entity shown in FIG. 3 or FIG. 8.

In the disclosure, network entities and methods for supporting cross flow dependent frame treatment are proposed. This disclosure proposes apparatus (PCF/SMF/RAN) and methods to determine X-Flow frame priority information in 5GS. This disclosure further proposes a method to group, synchronize and identify frames cross multiple flows per RAN using base line flow and group window. The proposed X-flow synchronization, grouping, and prioritizing mechanism enables frame-level resource coordination cross multiple flows in 5GS. In this way, a better service experience for the user in case of radio resource shortage or disturbances can be assured. For instance, this disclosure allows for selective packet dropping based on frame dependency cross flows instead of random dropping, temporary resource coordination between packets with Frame dependency cross flows, and less delay and jitter. According to the proposed approach, radio resource usage in case of radio resource shortage is more efficient. Transmission of useless packets can be avoided, therefore the radio resource can be saved without impacts to the application Quality of Experience (QoE). This disclosure further proposes a method to convert between flow-based and group-based X-Flow frame priority information representation, and an apparatus (RAN) and methods for resource allocation/ scheduling based on X-Flow frame priority information.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed embodiments of the disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Furthermore, any method according to embodiments of the disclosure may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer-readable medium of a computer program product. The computer-readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive.

Moreover, it is realized by the skilled person that embodiments of the control plane network entity 300, or the RAN entity 400, comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, trellis-coded modulation (TCM) encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Especially, the processor(s) of the control plane network entity 300, or the RAN entity 400 may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Claims

1. A control plane network entity (300) for assisting the handling of a flow group by one or more radio access network, RAN, entities, wherein each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies, and wherein the flow group comprises a baseline flow and one or more other flows that depend on the baseline flow, wherein the control plane network entity (300) is configured to, for each RAN entity (400) of the one or more RAN entities: determine, based on the different importance levels and/or different dependencies of the plurality of frames, priority information (301) of one or more frame groups related to the RAN entity (400), wherein each frame group comprises frames of multiple flows of the flow group; and provide the priority information (301) of the one or more frame groups to the related RAN entity (400).

2. The control plane network entity (300) according to claim 1, wherein the priority information (301) of the one or more frame groups related to the RAN entity (400) comprises first frame group information and first frame priority information, wherein the first frame group information comprises information about the one or more frame groups related to the RAN entity (400), and the first frame priority information comprises priority information of each frame of the one or more frame groups related to the RAN entity (400).

3. The control plane network entity (300) according to claim 2, configured to: determine the first frame group information and the related RAN entity (400) based on second frame group information comprising information about one or more frame groups related to an application.

4. The control plane network entity (300) according to claim 2 or 3, wherein: the second frame group information comprises one or more of the following: an identity of the application, a group window and/or a group size of one or more frame groups related to the application, an identity of a flow group related to the application, an identity of a flow of the flow group related to the application, an indication of a baseline flow of the flow group related to the application, and/or the first frame group information comprises one or more of the following: the identity of the application, a group window and/or a group size of the one or more frame groups related to the RAN entity (400), an indication of a baseline flow of the flow group related to the RAN entity (400), an identity of a flow group related to the RAN entity (400), an identity of a flow of the flow group related to the RAN entity (400).

5. The control plane network entity (300) according to claim 4, wherein the group window of a frame group is indicated by using one or more of the following: a burst starting time of a first frame of the frame group, a burst starting time of a last frame of the frame group, an identity of a first frame in a baseline flow of the frame group, an identity of a last frame in a baseline flow of the frame group, a type of a first frame in a baseline flow of the frame group, a type of a last frame in a baseline flow of the frame group, an identity of a first frame in all flows of the frame group, an identity of a last frame in all flows of the frame group, a type of a first frame in all flows of the frame group, a type of a last frame in all flows of the frame group.

6. The control plane network entity (300) according to one of the claims 3 to 5, wherein determining the first frame group information and the related RAN entity (400) based on the second frame group information comprises: identifying flows of a same flow group based on an identity of the flow group related to the application or an identity of a flow of the flow group related to the application; identifying one or more RAN entities serving the flow group related to the application; identifying a baseline flow based on an identity of a baseline flow or a priority level of a flow of the flow group related to the application; and calculating information about the flow group related to each of the one or more RAN entities.

7. The control plane network entity (300) according to one of the claims 3 to 6, configured to: determine the first frame priority information based on second frame priority information related to the application and the first frame group information.

8. The control plane entity according to claim 7, wherein: the second frame priority information comprises one or more of the following: an identity of a flow group related to the application, an identity of a flow of the flow group, a flow priority of each flow in the flow group, a set of indicators indicating the different importance levels and/or different dependencies of the plurality of frames in the flow; and/or the first frame priority information comprises one or more of the following: an identity of a frame, a priority of the frame in a flow group related to the RAN entity (400).

9. The control plane network entity (300) according to claim 7 or 8, wherein determining the first frame priority information based on second frame priority information and the first frame group information comprises: calculating the priority of the frame based on a frame priority of that frame in the flow, and the set of indicators.

10. The control plane network entity (300) according to one of the claims 3 to 9, configured to: obtain the second frame group information and/or the second frame priority information from an application function, or via a Network Exposure Function, and/or a User Data Repository.

11. The control plane network entity (300) according to one of the claims 1 to 10, configured to: split the flow group into a first sub flow group related to a first RAN entity and a second sub flow group related to a second RAN entity; determine priority information of one or more frame groups related to the first RAN entity, and provide the priority information of the one or more frame groups to the first RAN entity; and determine priority information of one or more frame groups related to the second RAN entity, and provide the priority information of the one or more frame groups to the second RAN entity.

12. The control plane network entity (300) according to one of the claims 1 to 11, wherein the control plane network entity (300) comprises a Policy Control Function or a Policy Control Function together with a Session Management Function.

13. A radio access network, RAN, entity (400) for handling a flow group, wherein each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies, and wherein the flow group comprises a baseline flow and one or more other flows depending on the baseline flow, wherein the RAN entity (400) is configured to: obtain priority information (301) of one or more frame groups related to the RAN entity (400), wherein each frame group comprises frames of multiple flows of the flow group, and wherein the priority information indicates the different importance levels and/or different dependencies of the plurality of frames of each frame group; and perform resource scheduling for the one or more frame groups based on the priority information (301) of one or more frame groups.

14. The RAN entity (400) according to claim 13, wherein the priority information (301) of the one or more frame groups related to the RAN entity (400) comprises first frame group information and first frame priority information, wherein the first frame group information comprises information about the one or more frame groups related to the RAN entity (400), and the first frame priority information comprises priority information of each frame of the one or more frame groups related to the RAN entity (400).

15. The RAN entity (400) according to claim 14, wherein the first frame group information comprises one or more of the following: an identity of an application, a group window and/or a group size of the one or more frame groups related to the RAN entity (400), and an indication of a baseline flow of the flow group related to the RAN entity (400), an identity of a flow group related to the RAN entity (400), an identity of a flow of the flow group related to the RAN entity (400).

16. The RAN entity (400) according to claim 14 or 15, wherein the first frame priority information comprises one or more of the following: an identity of a frame, a priority of the frame in a flow group related to the RAN entity (400).

17. The RAN entity (400) according to one of the claims 13 to 16, wherein performing resource scheduling for the one or more frame groups comprises one or more of the following: scheduling a resource for packet transmissions in a frame group together; scheduling a resource for packet transmission in a frame group in the order of frame priority in the frame group; dropping a remaining transmission of a frame group if a packet in the transmission is not successfully transmitted; dropping or preempting a transmission of frames with lower priorities in a frame group in case of resource shortage.

18. The RAN entity (400) according to claim 17, wherein dropping the remaining transmission comprises: identifying a frame, to which the packet belongs, based on the first frame group information; determining priority information of the frame based on the first frame priority information, and determining a frame group, to which the frame belongs, based on the first frame group information; identifying other packets that belong to the frame and other frames in the frame group with a lower priority than a priority of the frame; and dropping the identified packets and frames.

19. A method (1800) for a control plane network entity (300) for assisting the handling of a flow group by one or more radio access network, RAN, entities, wherein each flow of the flow group comprises a plurality of frames with different importance levels and/or different dependencies, and wherein the flow group comprises a baseline flow and one or more other flows that depend on the baseline flow, wherein the method (1800) comprises, for each RAN entity (400) of the one or more RAN entities: determining (1801), based on the different importance levels and/or different dependencies of the plurality of frames, priority information (301) of one or more frame groups related to the RAN entity (400), wherein each frame group comprises frames of multiple flows of the flow group; and providing (1802) the priority information (301) of the one or more frame groups to the related RAN entity (400).

20. A method (1900) for a radio access network, RAN, entity (400) for handling a flow group, each flow of the flow group comprising a plurality of frames with different importance levels and/or different dependencies, wherein the flow group comprises a baseline flow and one or more other flows depending on the baseline flow, wherein the method (1900) comprises: obtaining (1901) priority information (301) of one or more frame groups related to the RAN entity (400), wherein each frame group comprises frames cross multiple flows of the flow group, and wherein the priority information indicates the different importance levels and/or different dependencies of the plurality of frames of each frame group; and performing (1902) resource scheduling for the one or more frame groups based on the priority information of one or more frame groups.

21. A computer program product comprising a program code for carrying out, when implemented on a processor, the method (1800, 1900) according to claim 19 or 20.

22. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method (1800, 1900) of claim 19 or 20.