WO2023061555A1

WO2023061555A1 - Device and method for group qos control of multiple qos flows

Info

Publication number: WO2023061555A1
Application number: PCT/EP2021/078084
Authority: WO
Inventors: Qing Wei; Hanwen Cao; Mirko Schramm
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-10-12
Filing date: 2021-10-12
Publication date: 2023-04-20

Abstract

The present disclosure relates to entities and methods for handling a group of frames (wherein each frame comprising a plurality of packets) with inter-dependency in a network. The disclosure proposes a first network entity that is configured to obtain, from a second network entity, frame dependency information of the group and a plurality of dependency related instructions, wherein each dependency related instruction indicates at least one operation on one or more frames of the group, the at least one operation being based on the frame dependency information; and perform the at least one operation on the one or more frames, in response to one or more trigger events. Further, the disclosure proposes a second network entity being configured to provide the frame dependency information of the group and the plurality of dependency related instructions to the first network entity.

Description

DEVICE AND METHOD FOR GROUP QoS CONTROL OF MULTIPLE QoS FLOWS

TECHNICAL FIELD

The present disclosure relates to communication networks, and particularly to resource coordination for packets transmission in communication networks. In order to improve a radio resource usage efficiency, and to provide a better service experience for users, the disclosure proposes a real-time adaptation of packets transmission in a QoS flow.

BACKGROUND

Various new video-based media services are emerging with the advancing of telecommunication technologies: Cloud VR/AR, Cloud gaming, 4K/8K VoD, Video-based remote control, machine vision, etc. Such services require not only high bandwidth but also short End-to-End (E2E) latency and high communication reliability. For instance, consumption of VR content via tethered VR headset requires a maximum of 5-10 ms end-to-end latency, 0.1- lOGbit/s service bit rate, and 99.99% reliability (3GPP TS 22.261 vl8.2.0). 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 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 a video traffic. H.265 and other video codecs further improve video compression/coding efficiency. Still, the basic principle of video codec does not change and such dependency between video packets stays. For instance, some of the slices/pictures/frames (i.e., a group of video packets) in a video stream may be coded without reference to any other slices/pictures/frames (e.g., reference frames), while some of the slices/pictures/frames reference other slices/pictures/frames for decoding/prediction (e.g., dependent frames).For the sake of simplicity, all the “slices”, “pictures”, “group of packets”, are referred as “frame” in this disclosure. Due to such dependency between frames, Quality of Service (QoS) fulfillment of different packets in a video stream will cause different impairs to the service experience of the user. For instance, packet error/loss in a reference frame to which other frames reference will affect the decoding of the other dependent frames. Failed to deliver the packets of a reference frame on time would cause the decoding/predication error of the dependent frames.

The current mobile networks are not able to support differentiated QoS treatment of the packets within one video stream. It is defined that the QoS of mobile communication is managed and controlled per QoS flow.

Differentiated QoS treatment within a QoS flow could be explicitly defined per packet, such as 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 such 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 the unit of inter-frame dependency during the coding phase, 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 frame/slice) are dropped instead of high priority packets (e.g., reference frame/slice) in case of radio resource shortage. However, it is not possible for the immediate and accurate release of resources, which have already been scheduled for a dependent frame, after a detection failure of its reference frame, for improving the QoS fulfillment of the reference frame.

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

In view of the above, this disclosure is to introduce a solution for dynamic resource coordination for packets transmission. An objective is to propose a network-controlled packet treatment scheme based on inter-frame dependency between groups of data packets. Another objective is to enable a network entity to react to losses of packets of a reference frame so that the chances for a consecutive frame loss are reduced. A further objective is to improve the efficiency of radio resource usage. 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 first network entity for handling a group of frames with inter-dependency, wherein the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets, and wherein the first network entity is configured to: obtain, from a second network entity, frame dependency information of the group and a plurality of dependency related instructions, wherein each dependency related instruction indicates at least one operation on one or more frames of the group, the at least one operation being based on the frame dependency information; and perform the at least one operation on the one or more frames, in response to one or more trigger events.

In this disclosure, some of the frames from the group of frames with inter-dependency may refer to one or more other frames in the group for decoding/prediction. Such frames, i.e., frames of the second type, may also be referred to as dependent frames. Frames that other frames depend on, i.e., frames of the first type, may also 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. That is, a frame can be at the same time of the first type and also of the second type. Notably, a “parallel dependency structure”, “Recursive case”, or “hierarchical dependency structure” may exist in the group of frames. In the “parallel dependency structure”, a dependent frame may depend on two reference frames in parallel. Possibly, in the “parallel dependency structure”, or “hierarchical dependency structure”, multiple instructions may apply to the same frame. For instance, when one reference frame is an erroneous frame, some instructions may apply to the dependent frame; when the other one reference frame is also an erroneous frame, some other instructions may apply to the dependent frame as well. In such cases, the operations in a latter instruction should be performed based on the frame status after the operations in an earlier instruction have been performed.

This disclosure proposes a solution to support real time adaptation of packet transmission (i.e., dependency related instructions) in a QoS flow based on the frame dependency information (in response to certain trigger events). This solution may be realized by introducing new functionality at Radio Access Node (RAN), which can be referred as QoS Assurance Entity in this disclosure.

In an implementation form of the first aspect, the one or more trigger events include that one or more packets belonging to a specific frame are not successfully transmitted according to a predefined requirement, wherein the first network entity is further configured to determine that the specific frame of the group is an erroneous frame, when the one or more packets belonging to the specific frame are not successfully transmitted according to the predefined requirement.

The successful transmission of a packet may mean that the packet is successfully transmitted according to the requirements in a QoS profile of the QoS flow. In case of failure to successfully transmit a packet, the QoS Assurance Entity, i.e., the first network entity, identifies the frame this packet belongs to.

In an implementation form of the first aspect, performing the at least one operation on the one or more frames comprises: determining whether the type of the specific frame is the first type or the second type based on the frame dependency information; determining one or more instructions from the plurality of dependency related instructions based on the determined type of the specific frame; and performing at least one operation indicated by the determined one or more instructions on the specific frame.

The dependency related instructions may refer to instructions for the packet transmission at the RAN, and related resource allocation. Dependency related instructions may be separated into instructions for the erroneous frame itself, and instructions for dependent frames of that erroneous frame if the erroneous frame is a reference frame. Therefore, the first network entity may determine the instructions that are to be performed taking into account the type of the erroneous frame.

In an implementation form of the first aspect, the plurality of dependency related instructions includes a first set of instructions, wherein the determined one or more instructions that are performed on the specific frame are determined from the first set of instructions, and the first set of instructions includes one or more operations: - extended packet transmission for a duration determined based on the frame dependency information,

- duplication of packets of the extended packet transmission,

- dropping of remaining transmission,

- suspending of a notification about unsuccessful transmission to another network entity.

The first network entity determines which operation to perform on the erroneous frame according to the type of the specific frame. For instance, when the specific frame is of the first type, i.e., a reference frame, extended packet transmission for a certain duration and/or duplication of packets can be performed on the specific frame, to increase the transmission reliability for a reference frame.

In an implementation form of the first aspect, when the type of the specific frame is the first type, performing the at least one operation on the one or more frames further comprises: determining a set of frames of the group that have dependency on the specific frame based on the frame dependency information; determining one or more instructions from the plurality of dependency related instructions; and performing at least one operation indicated by the determined one or more instructions on the determined set of frames.

If the erroneous frame is a reference frame on which other frames have dependency, when the reference frame is not successfully transmitted, the dependent frames may not be able to be correctly decoded. The first network entity further determines certain operations to perform on the dependent frames.

In an implementation form of the first aspect, the plurality of dependency related instructions further includes a second set of instructions, wherein the determined one or more instructions that are performed on the determined set of frames are determined from the second set of instructions, wherein the second set of instructions includes one or more operations:

- dropping one or more frames from the set of frames,

- conditional dropping one or more frames from the set of frames,

- delaying one or more frames from the set of frames for a duration determined based on the frame dependency information,

- suspending of a notification about unsuccessful transmission of one or more frames from the set of frames to another network entity. Possibly, conditional dropping, delaying, or dropping packets of one or more dependent frames in the same group can compensate for the additional radio resources required for the extended transmission (with or without duplication of packets). Delaying the one or more frames means waiting with the initial packet transmission of the dependent frame until either the reference frame is successfully transferred or a time interval (e.g., defined by a time value or a reference to another frame listed in the frame dependency information) is passed.

In an implementation form of the first aspect, the frame dependency information of the group includes an order of the frames in the group, and/or one or more dependency relationships between the frames of the group.

Optionally, the order of the frames can be an index of the frames, which describes the sequence, order, or position of each frame in the group.

In an implementation form of the first aspect, the frame dependency information of the group further comprises one or more of:

- a frame identifier, and/or an application layer type,

- a position of each frame in the group,

- a frame group structure,

- a starting frame, an ending frame, or a size of the group,

- a mapping table/formula indicating the one or more dependency relationship between the frames in the group.

For example, the frame group structure can be parameters or a formula describing the different types of frames in a group.

In an implementation form of the first aspect, the first network entity is configured to: obtain frame information of the specific frame of the group, wherein the frame information includes a first indication that is indicative of an identifier of that frame; and identify the specific frame that the one or more packets belong to, based on the frame information. In an implementation form of the first aspect, the frame information further includes a second indication that is indicative of an application layer type of the specific frame which can be mapped to the first type and/or the second type.

In an implementation form of the first aspect, obtaining frame information of the specific frame comprises: deriving the frame information of the specific frame by processing the plurality of packets of the specific frame based on frame detection information, wherein the frame detection information is locally configured or obtained from the second network entity; or extracting the frame information of the specific frame from the plurality of packets of the specific frame; or obtaining the frame information by processing information derived based on the frame detection information and information extracted from the plurality of packet of the specific frame.

Notably, three options are provided as examples of how to obtain the frame information. In the third option, the frame information may be obtained using the combination of the first and second options. For example, the third option may comprise using the second option to get the I-frame information, and using the first option to get the P/B-frame information (e.g., using GOP structure to calculate that the second frame after the I-frame is a P-frame, and the third frame after the I-frame is a B-frame. Alternatively, if the information obtained from the first option shows that this frame is a P-frame, while the information obtained from the second option shows that this frame is an I-frame, then the information obtained from the second option takes precedence and this frame is considered as an 1-frame. The calculation in the first option should be reset accordingly for all the subsequence frames.

In an implementation form of the first aspect, the frame detection information comprises one or more of:

- a timestamp indicating a starting/ending of a frame, and/or a periodicity of the frame,

- a frame group structure.

The frame detection information may include direct indications or indirect indications of the frame information.

It should be understood that, frame dependency information and dependency related instructions may be implemented as an integrated form. For instance, dependency related instructions may integrate frame dependency information. This also works when the instruction is provided for each frame in the group.

In an implementation form of the first aspect, the group of frames comprises a sequence of video frames, and the group of frames includes an I-frame, a P-frame and a B-frame, wherein the I-frame has no dependency on other frames of the sequence, the P-frame has a dependency on the I-frame or a previous P-frame, and the B-frame has one or more dependency on one or more of the 1-frame and the P-frame.

In this implementation, 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 to both proceeding and subsequent frame(s) to be displayed.

In an implementation form of the first aspect, the first network entity is located at an access node.

Optionally, this disclosure can be realized by introducing new functionality at the RAN.

A second aspect of the disclosure provides a second network entity for assisting of handling a group of frames with inter-dependency, wherein the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets, and wherein the second network entity is configured to: obtain frame dependency information of the group, and a plurality of dependency related instructions; and provide, to a first network entity, the frame dependency information of the group and the plurality of dependency related instructions, wherein each dependency related instruction indicates the first network entity to perform at least one operation on one or more frames of the group, the at least one operation being based on the frame dependency information.

Another aspect of this disclosure proposes an approach for providing frame-dependency information and dependency related instructions to the RAN. This can be done by introducing the new functionality for the Policy Control Function (PCF) (which is referred to as QoS Control Entity in this disclosure).

In an implementation form of the second aspect, the frame dependency information of the group includes an order of the frames in the group, and/or one or more dependency relationships between the frames of the group.

In an implementation form of the second aspect, the frame dependency information of the group further includes one or more of:

- a frame identifier, and/or an application layer type,

- a position of each frame in the group,

- a frame group structure,

- a starting frame, an ending frame, or a size of the group,

In an implementation form of the second aspect, the frame dependency information of the group, and/or the set of dependency related instructions are obtained from an application layer entity directly or indirectly via other network entity.

Optionally, the application layer entity may provide the frame dependency information of the group, and/or the set of dependency related instructions to the PCF via Network Exposure Function (NEF) and/or Unified Data Repository (UDR). The frame dependency information of the group and/or the set of dependency related instructions may also be obtained via multiple other network entities.

In an implementation form of the second aspect, obtaining the frame dependency information of the group and/or the set of dependency related instructions includes: deriving the frame dependency information of the group and/or the set of dependency related instructions from one or more of the following: a formula, a plurality of parameters based on a group of picture structure, and a mapping table. In an implementation form of the second aspect, the second network entity is configured to: provide frame detection information to the first network entity, wherein the frame detection information comprises one or more of:

- a frame group structure.

It should be understood that, frame dependency information, frame detection information and dependency related instructions may be implemented as an integrated form. For instance, frame dependency information may integrate frame detection information such as the frame group structure. In another example, dependency related instructions may integrate frame dependency information. This also works when the instruction is provided for each frame in the group.

A third aspect of the disclosure provides a method for handling a group of frames with interdependency, wherein the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets, wherein the method comprises: obtaining, from a second network entity, frame dependency information of the group and a plurality of dependency related instructions, wherein each dependency related instruction indicates at least one operation on one or more frames of the group, the at least one operation being based on the frame dependency information; and performing the at least one operation on the one or more frames, in response to one of more trigger events.

Implementation forms of the method of the third aspect may correspond to the implementation forms of the first 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 first network entity of the first aspect and its implementation forms.

A fourth aspect of the disclosure provides a method for assisting of handling a group of frames with inter-dependency, wherein the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets, wherein the method comprises: obtaining frame dependency information of the group and a plurality of dependency related instructions, and providing, to a first network entity, the frame dependency information of the group and the plurality of dependency related instructions, wherein each dependency related instruction indicates the first network entity to perform at least one operation on one or more frames of the group, the at least one operation being based on the frame dependency information.

Implementation forms of the method of the fourth aspect may correspond to the implementation forms of the second network 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 second network 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.

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 a Group of Picture (GOP) structure example;

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

FIG. 4 shows a first network entity according to an embodiment of the disclosure;

FIG. 5 shows a frame transmission and decoding order according to an embodiment of the disclosure;

FIG. 6 shows a second network entity according to an embodiment of the disclosure;

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

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

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

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

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

FIG. 12 shows packets retransmission according to an embodiment of the disclosure;

FIG. 13 shows packets retransmission according to an embodiment of the disclosure;

FIG. 14 shows packets retransmission according to an embodiment of the disclosure;

FIG. 15 shows packets duplication according to an embodiment of the disclosure;

FIG. 16 shows packets duplication according to an embodiment of the disclosure;

FIG. 17 shows a method according to an embodiment of the disclosure; and

FIG. 18 shows a method according to an embodiment of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

Illustrative embodiments of a first network entity, a second network entity, and corresponding methods for handling a group of frames with inter-dependency are described 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/example may refer to other embodiments/examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment/example is applicative to the other embodiments/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. Moreover, the granularity of prediction types is brought down to the “slice level”. A slice is a spatially distinct region of a frame that is encoded separately from any other region in the same frame. I-slices, P-slices, and B-slices take the place of I, P, and B frames. This means a predicted P-slice in a frame may have dependency to certain P/I-slice(s) in the proceeding frames. FIG. 1 shows an example GOP structure with M = 10, N = 3. M refers to the distance between two full images (I-frames), it is the GOP size. N represents the distance between two anchor frames (I or P). For the example M = 10, N = 3, the GOP structure is IBBPBBPBBPI.

Due to such dependency between slices/frames, QoS fulfillment of different packets in a video stream will cause different impairs to the service experience of the user. For instance, packet error/loss in the I-frame/slice will affect the decoding of all the frames/slices in a GOP. Failed to deliver the packets of a reference P frame/ slice on time would cause the decoding/predication error of the dependent P/B frames/slices.

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., Radio Access Network (RAN), Session Management Function (SMF)) treat each QoS flow separately according to the corresponding QoS Profile.

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, FIG. 3 shows two cases of how the B/P frames are dropped. As shown in FIG. 3 (a), it may drop all the B/P frames in case of radio resource shortage, although drop the first P- firame 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 (as indicated in FIG. 3(a)), or would be more harmful comparing to drop a later P-frame. FIG. 3(b) shows a result when only drop the affected P-frame and its dependent frames. In this case, the first two B-frames should still be transmitted although the resource for the second P frame could not be guaranteed. In this way, the first P-frame and unaffected B-frame can be saved. 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.

This disclosure introduces a network-controlled packet treatment scheme for the RAN based on inter-dependencies between groups of data packets (e.g., video frames/video slices) and their transmission status, enabling RAN to react to losses of packets of a reference frame so that the chances for a consecutive frame loss are reduced. For simplicity, a group of data packets with inter-dependencies between the group are referred to as “frame” throughout this disclosure.

FIG. 4 shows a first network entity 400 adapted for handling a group of frames 401 with interdependency according to an embodiment of the disclosure. The group comprises frames of at least a first type and a second type. A frame (or each frame) of the second type has dependency on at least one frame of the first type. Each frame of the group comprises one or more packets.

In this disclosure, some of the frames from the group of frames with inter-dependency may refer to one or more other frames in the group for decoding/prediction. Such frames, i.e., frames of the second type, may also be referred to as dependent frames. Frames that other frames depend on, i.e., frames of the first type, may also be referred to as reference frames. As previously discussed, a reference frame on which another frame has dependency, may also have dependency on another reference frame. That is, a frame can be a reference frame and also a dependent frame at the same time. Namely, a frame may be of the first type and also of the second type. The first network entity 400 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the first network 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 first network 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 first network 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 first network entity 400 to perform, conduct or initiate the operations or methods described herein.

The first network entity 400 is configured to obtain, from a second network entity 600 (e.g., shown in FIG. 6), frame dependency information 402 of the group and a plurality of dependency related instructions 403. Each dependency related instruction 403 indicates at least one operation 404 on one or more frames of the group, the at least one operation 404 being based on the frame dependency information 402. The first network entity 400 is further configured to perform the at least one operation 404 on the one or more frames, in response to one or more trigger events.

Notably, the one or more trigger events may include that one or more packets belonging to a specific frame (or any one frame of the group) are not successfully transmitted according to a predefined requirement. Possibly, the predefined requirement may include a QoS requirement.

Optionally, the first network entity 400 may be further configured to determine whether the specific frame of the group is an erroneous frame. When the one or more packets belonging to the specific frame are not successfully transmitted according to the predefined requirement, the specific frame of the group is an erroneous frame. This disclosure proposes a solution to support real time adaptation of packet transmission (i.e., dependency related instructions) in a QoS flow based on the frame transmission status and the frame dependency information. This solution may be realized by introducing new functionality at Radio Access Node (RAN), which is referred as QoS Assurance Entity in this disclosure. The first network entity 400 shown in FIG. 4 may be the QoS Assurance Entity.

This disclosure further proposes a solution for providing frame-dependency information and dependency related instructions to the RAN. This may be realized by introducing new functionality at Policy Control Function (PCF), which is referred as QoS Control Entity in this disclosure. The second network entity 600 shown in FIG. 4 may be the QoS Control Entity. The corresponding signaling between AF, PCF and RAN are discussed in the latter of the description.

In case of failure to transfer a packet, the QoS Assurance Entity, i.e., the first network entity 400 as shown in FIG. 4, identifies the frame this packet belongs to with the help of the frame information and/or frame detection information. Notably, the successful transmission of a packet may mean that the packet is successfully transferred according to the requirements in the QoS profile of the QoS flow. The QoS Assurance Entity then executes the dependency related instructions it has received for this frame.

The dependency related instructions may refer to instructions for the packet transmission at the RAN and related resource allocation. Dependency related instructions may be separated into instructions for the erroneous frame itself (e.g., Extended packet transmission, Dropping) and instructions for dependent frames listed in the frame dependency information (e.g. Conditional dropping, Delaying or Dropping).

The QoS Assurance Entity may derive a Dependent Frame Group (DFG), e.g., the group of frames 401, transmission status from the frame dependency information 402 and maintains the status of the erroneous frame and status of the dependent frames of erroneous frame if any in the DFG transmission status based on the status of the transmission of the related packets.

Optionally, the QoS Assurance Entity performs one or more of the following actions until either the end of the DFG is reached or all erroneous frames of this DFG are transferred successfully: The QoS Assurance Entity identifies frame that a packet belongs to with the help of the frame information and/or frame detection information.

The QoS Assurance Entity checks whether the packet belongs to a frame that is an erroneous frame or a frame that is dependent on the erroneous frame or neither of the former two types of frame.

If the packet belongs to the erroneous frame, the QoS Assurance Entity executes the dependency related instructions for the erroneous frame itself.

If the packet belongs to a frame that is dependent on the erroneous frame, the QoS Assurance Entity executes the dependency related instructions that are relevant for the dependent frame of the erroneous frame.

According to an embodiment of the disclosure, the first network entity 400 may be configured to determine whether the type of the specific frame is the first type or the second type based on the frame dependency information 402. Notably, the specific frame here is an erroneous frame. Then, the first network entity 400 may be configured to determine one or more instructions from the plurality of dependency related instructions 403 based on the determined type of the specific frame. The first network entity 400 may be further configured to perform at least one operation indicated by the determined one or more instructions on the specific frame.

Notably, the plurality of dependency related instructions 403 indicate the actions that the mobile network/RAN should execute regarding the treatment of packets with inter-frame dependency. Dependency related instructions may be separated into instructions for the erroneous frame itself and instructions for dependent frames.

Optionally, the plurality of dependency related instructions 403 includes a first set of instructions, wherein the determined one or more instructions that are performed on the specific frame, i.e., the erroneous frame, are determined from the first set of instructions. The first set of instructions includes one or more operations:

- extended packet transmission for a duration determined based on the frame dependency information 402,

- duplication of packets of the extended packet transmission,

- dropping of remaining transmission,

- suspending of a notification about unsuccessful transmission to another network entity. The first network entity 400 determines which operation to perform on the erroneous frame according to the type of the specific frame. For instance, when the specific frame is of the first type, i.e., a reference frame, extended packet transmission (i.e., beyond the time given by the Packet Delay Budget (PDB) value of the QoS profile) for certain duration can be performed on the specific frame. The duration may be defined by an extended transmission time value or a reference to another frame listed in the frame dependency information. Further, duplication of packets during extended packet transmission can be performed on the specific frame (of the first type) to increase the transmission reliability for a reference frame.

Dropping of remaining packets that are not yet successfully transmitted can be performed when the specific frame is a reference frame or a dependent frame. Suspending/Disabling of the notification (e.g., Release of resources, QoS Notification Control with or without Alternative QoS Profile) to another network entity, e.g., Session Management Function (SMF), can be performed for both types of frames. For example, suspending/disabling of the notification may be set permanently when the specific frame is a dependent frame, or temporarily only for the duration of the extended transmission of a frame when the specific frame is a reference frame.

Further, the plurality of dependency related instructions 403 may include a second set of instructions for dependent frames. When the type of the specific frame is the first type, the first network entity 400 may be configured to determine a set of frames of the group that have dependency on that specific frame based on the frame dependency information 402. Then the first network entity 400 may be configured to determine one or more instructions from the plurality of dependency related instructions 403; and perform at least one operation indicated by the determined one or more instructions on the determined set of frames.

Notably, the determined one or more instructions that are performed on the determined set of frames are determined from the second set of instructions. Optionally, the second set of instructions includes one or more operations:

- dropping one or more frames from the set of frames,

- conditional dropping one or more frames from the set of frames,

- delaying one or more frames from the set of frames for a duration determined based on the frame dependency information 402, - suspending of a notification about unsuccessful transmission of one or more frames from the set of frames to another network entity.

Conditional dropping, delaying, or dropping packets of one or more dependent frames in the same DFG can compensate for the additional radio resources required for the extended transmission (with or without duplication of packets). Conditional dropping may include prioritization of packet transmission (of reference frame subject to extended packet transmission) over initial packet transmission (of dependent frame), and dropping of packets (of dependent frame) that cannot be transmitted initially within the time given by the PDB value of the QoS profile. Delaying the one or more frames means waiting with the initial packet transmission of the dependent frame until either the reference frame is successfully transferred or a time interval (e.g., defined by a time value or a reference to another frame listed in the frame dependency information) is passed. Dropping the one or more frames indicates that all packets of the reference frame are dropped (i.e. no initial packet transmission).

Optionally, the first network entity 400 may determine to drop all packets of dependent frames in the same DFG which are useless for the application due to the failed transmission of a reference frame. Optionally, the first network entity 400 may determine to suspend/disable the notification to SMF (e.g., the notification on release of resources, the notification used in QoS Notification Control with or without Alternative QoS Profile) caused by conditional dropping, delaying, or dropping.

In this disclosure, frame information contains information of at least one of the following:

- types of frames from the application layer,

- whether a frame is a reference frame or a dependent frame,

- how to identify the frame that a packet belongs to,

- an order of the frames.

It can be implemented as a direct indication via a “Frame identifier”, e.g.,

- a unique Frame identifier in the packet header,

- a Frame sequence number in the packet header.

Alternatively, it can be implemented as an indirect indication which indicates the starting/ending of a frame as following, e.g., - an indication of the first/last packet of a Frame in the packet header, e.g., a starting and/or ending flag.

- timestamps indicating the starting/ending of a Frame, and/or periodicity of the frame (e.g., frame rate).

Optionally, frame information may also 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 “application layer type” of the frame.

According to an embodiment of the disclosure, the first network entity 400 may be configured to obtain frame information of the specific frame of the group. In particular, the frame information includes a first indication that is indicative of an identifier of that frame. The first network entity 400 may be further configured to identify the specific frame that the one or more packets belong to, based on the frame information.

Possibly, the frame information may further include a second indication that is indicative of an application layer type of the specific frame (i.e., frame type) which can be mapped to the first type and/or the second type.

The first network entity 400 may obtain the frame information in different ways. Optionally, the first network entity 400 may derive the frame information of the specific frame by processing the plurality of packets of the specific frame based on frame detection information. The frame detection information is, for instance, locally configured or obtained from the second network entity 500.

Optionally, the first network entity 400 may extract the frame information of the specific frame from the plurality of packets of the specific frame. Optionally, the first network entity 400 may obtain the frame information by processing information derived based on the frame detection information and information extracted from the plurality of packets of the specific frame.

Typically, the frame transmission normally follows the order of frame decoding as the example shown in FIG. 5. In such cases, the reference frames such as “I” frames are transmitted before their dependent frames. In this example, it is assumed that the frame transmission order follows the decoding order. In the case of any other frame transmission order, the numbers and calculation can be adjusted accordingly.

Frame dependency information indicates dependency relationship between different frames. It may include at least one of the following information per reference/dependent frame:

- frame identifier and/or frame type,

- its dependent and/or reference frame(s).

It may also include the following one or more information in case Frame dependency information is provided per DFG:

- position in a DFG (i.e., the group of frames),

- starting/ending/size of the DFG.

In one implementation, the frame dependency information 402 of the group includes an order of the frames in the group, and/or one or more dependency relationships between the frames of the group.

Possibly, the frame dependency information 402 of the group may further comprise one or more of

- a frame identifier, and/or an application layer type,

- a position of each frame in the group,

- a frame group structure,

- a starting frame, an ending frame, or a size of the group,

- a mapping table/formula indicating the one or more dependency relationships between the frames in the group.

In one implementation, the frame dependency information of a dependent frame can be derived from the frame dependency information of its reference frame. For instance, the frame dependency information 402 of the group includes frame dependency information of each frame of the first type. The first network entity 400 is configured to derive the frame dependency information of the frames of the second type of the group from the frame dependency information of the frames of the first type. In another implementation, the frame dependency information is indicated per dependent frame which refers to the one or more reference frames. For instance, the frame dependency information 402 of the group includes frame dependency information of each frame of the second type. The first network entity 400 is further configured to derive the frame dependency information of the frames of the first type from the frame dependency information of the frames of the second type.

For example, it can be implemented using the following data structure per “Frame type” from the dependent frame point of view. A GOP structure with “I”, “P” and “B” frames is discussed as an example here.

An example data structure for a “P” frame may include:

- Frame type (e.g., “P”),

- Number of reference frames (e.g., 1),

- Dependency/reference Frame type (e.g., “I” or “P”), and

- Offset of reference frames (e.g., -1).

An example data structure for a “B” frame may include:

- Frame type (e.g., “B”),

- Number of reference frames (e.g., 2),

- Dependent Frame type (e.g., “I” or “P”), and

- Offset of dependent frames (e.g., +1, +2).

The examples above illustrate the frame dependency information for a “P” and “B” frame type:

- The “P” frame has one reference frame with the frame type of “I” or “P”, and the reference frame is the first “I” or “P” frame before this frame.

- The “B” frame has four dependent frames with frame type of “B”, which is the first and second “I” or “P” frame before this frame.

In case the “Frame type” is unknown at the QoS Assurance Entity (e.g., not included in the frame information), the frame dependency information can also be implemented as below from the reference frame point of view:

- Starting Frame of a DFG (e.g., “I” frame in a GOP),

- Frame position in a DFG (e.g., 5th frame in a GOP), - Number of dependent frames (e.g., 7), and

- Offset of dependent frames (e.g., +1, +2, +3, +4, +5, +7, +8).

In a third implementation, both representations in the first and second implementations are included, e.g., just to facilitate the real-time treatment, although some information may be redundant.

In a fourth implementation, frame dependency information can be represented by a formula that can be used to derive the information listed above. Details of this implementation is described in the following.

For instance, the frame dependency information can be indicated as a formula or parameters (e.g., M, N) which indicates the GOP structure, where M tells the distance between two anchor frames (I or P), and N tells the distance between two full images (I-frames). The QoS Control Entity (e.g., PCF) provides the formula or the parameters to the QoS Assurance Entity (e.g., RAN). The RAN calculates the frame dependency information by itself based on the provided formula or parameters.

Assuming the frames are transmitted using the frame display order, the reference/dependency frame(s) can be calculated based on the Mod operation, as below.

- Frame sequence number % N (i.e., Frame sequence number mod N) = 1 indicates a I- frame, Frame sequence number % M = 1 indicates a P-frame, otherwise B-frame.

- P frame has dependency to Nth preceding frame. B-frame has the dependency to (M - sequence number % M)th preceding frame and (sequence number % M)th subsequent frame.

- An inserted I-frame causes the offset (with the value of Frame sequence number of the inserted I-frame -1) of Frame sequence number in the calculation.

For example, the frame dependency information and/or frame type information may be implemented as DFG parameters in Time Sensitive Communications (TSC) Assistance Information (TSC Al), as shown in Table 1.

Table 1

According to an embodiment of the disclosure, the first network entity 400 may be configured to maintain at least one transmission status for each frame of the group. For example, the at least one transmission status includes one or more of: not received, queued, in transmission, in extended transmission, transmitted, failed, dropped.

Notably, DFG transmission status can be created by the QoS Assurance Entity based on the frame dependency information in case of failure or successful transfer of a packet (e.g., according to the requirements in the QoS profile of the QoS Flow). The DFG transmission status is maintained until either the end of the DFG is reached or all erroneous frames of this DFG are transferred successfully.

Based on the DFG transmission status, the QoS Assurance Entity knows which dependency related instructions to execute for an erroneous frame itself and for any dependent frames if listed in the frame dependency information.

The DFG transmission status may indicate the status of every frame in the DFG (starting with the first erroneous frame), which comprises frame information such as frame identifier (e.g., frame ID/sequence number) and frame type (optional), and frame status including unreceived, queued, transmission, extended transmission, transmitted, failed, dropped. In case a packet in a frame fails to fulfill the required QoS with the normal or extended transmission, that frame has the status of “failed”. Notably, some of the statuses can be used in parallel (e.g., transmitted with the extended transmission, failed with extended transmission). For extended transmission, frame status may indicate also the extended time compared to the original transmission.

Optionally, the first network entity 400 may be configured to determine the at least one transmission status for the frame based on the frame dependency information in case of failure or successful transfer of one or more packets belong to that frame.

Optionally, the first network entity 400 may be configured to perform the operation on the set of frames of the group, based on the at least one transmission status of each of the one or more frames.

Optionally, the first network entity 400 may be configured to update the at least one transmission status for each of the one or more frames after handling the one or more frames. Notably, the transmission status of a frame may be updated multiple times.

An example procedure of inter-frame dependent QoS treatment at the QoS assurance Entity is described here.

Step 0: Receive the dependency related instructions and/or frame dependency information from the QoS Control Entity.

Step 1 : For each data packet in the QoS flow, check its frame information and identify a “Frame”, i.e., a block of consecutive data packets, which should use the same frame-level QoS policy, and identify the applicable dependency related instructions.

In case of QoS unfulfillment of a “frame” (e.g., packet not correctly received within PDB): Step 2: (Optional) Identify the dependency/dependent frames based on the frame dependency information and the dependency related instructions.

Step 3: (Optional) Check the DFG transmission status (i.e., frame transmission status of the dependency/dependent frames). Step 4: Decide and perform the QoS treatment for the not yet successfully transmitted data packets in this frame (e.g., normal/extended transmission, delay, or packet dropping, etc.) according to the dependency related instructions, and (optional) DFG transmission status. Re- allocate/release the allocated resource in the dependent frames if that will be affected by the treatment of this data packet.

Step 5: Store/Update the frame transmission status (e.g., at a local cache) of this frame and/or dependent frame(s) based on the treatment of the data packets.

FIG. 6 shows a second network entity 600 adapted for assisting of handling a group of frames 401 with inter-dependency according to an embodiment of the disclosure. The group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type. Each frame of the group comprises a plurality of packets.

The second network entity 600 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the controller 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 multi-purpose processors. The second network entity 600 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 second network entity 600 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 controller 300 to perform, conduct or initiate the operations or methods described herein. In particular, the second network entity 600 is configured to obtain frame dependency information 402 of the group, and a plurality of dependency related instructions 403. The second network entity 600 is further configured to provide, to a first network entity 400 (e.g., as shown in FIG. 4), the frame dependency information 402 of the group and the plurality of dependency related instructions 403. Each dependency related instruction 403 indicates the first network entity 400 to perform at least one operation 404 on one or more frames of the group, the at least one operation 404 being based on the frame dependency information 402.

This disclosure further proposes a second network entity 600 for providing necessary information to the first network entity 400 and thus assisting the first network entity 400 in a real-time adaptation of packet transmission. The first network entity 400 may be the network entity shown in FIG. 4 or FIG. 6. As previously described, the second network entity 600, namely the QoS Control Entity, provides frame detection information, frame-dependency information, and dependency related instructions to the first network entity 400.

In this disclosure, the QoS Control Entity, i.e., the second network entity 600, may obtain the frame dependency information and/or dependency related QoS criterion from the application; identify the involved QoS Assurance Entities; derive the dependency related instructions per QoS Assurance Entity (e.g., RAN and SMF); and provide frame dependency information and dependency related instructions to each involved QoS Assurance Entity. In a 5G mobile network, the QoS control entity may be the PCF. It interacts with the application via AF.

As discussed in previous embodiments, the frame dependency information 402 of the group includes an order of the frames in the group, and/or one or more dependency relationships between the frames of the group.

Optionally, the frame dependency information 402 of the group further includes one or more of

- a frame identifier, and/or an application layer type,

- a position of each frame in the group,

- a frame group structure,

- a starting frame, an ending frame, or a size of the group,

- a mapping table/formula indicating the one or more dependency relationships between the frames in the group. According to an embodiment of the disclosure, the frame dependency information 402 of the group, and/or the set of dependency related instructions 403 are obtained from an application layer entity directly or indirectly via other network entity.

FIG. 7 and FIG. 8 describe two options for the second network entity 600 to obtain the frame dependency information and dependency related QoS criterion from the AF and related messages and procedures in a 5G mobile network.

Option 1 : obtain the information for a future PDU session:

FIG. 7 shows signaling of setting a policy for a future AF session. The second network entity 600 (PCF) may obtain the dependency related instructions and frame dependency information from the application via Network Exposure Function (NEF) and Unified Data Repository (UDR). AF provides dependency related instructions and frame dependency information for a future AF session in UDR. PCF subscribes to UDR on the certain application using application ID. Table 2 lists Frame QoS criteria and frame dependency information for application A.

Table 2 Option 2: obtain the information for the existing PDU session:

FIG. 8 shows signaling for setting up an AF session with the required QoS procedure. AF provides dependency related instructions and frame dependency information to the PCF using the following procedure.

1. The AF sends a request to reserve resources for an AF session using Nnef AFsessionWithQoS Create request message (e.g., including AF Identifier, UE address, Flow description(s), QoS reference, (optional) Alternative Service Requirements (containing one or more QoS reference parameters in prioritized order), dependency related instructions, frame dependency 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, dependency related instructions, frame dependency information. Any optionally received period of time or traffic volume is also included and mapped to sponsored data connectivity information (e.g., as defined in TS 23.203).

The AF may send a 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.

In the following, procedure and signaling for the provision of dependency related instruction and frame dependency information to RAN (in a 5G mobile network) are discussed. The second network entity 600 (i.e., QoS Control Entity, or PCF) provides the frame detection information (this information is optional, e.g., for Frame type, or to assistant RAN on obtaining the frame information), the dependency related instructions and the frame dependency information of the QoS flow to the first network entity 400 (i.e., QoS Assurance Entity, SMF or RAN) together with the corresponding QoS Flow Indication (QFI) using the PCF initiated Session management (SM) policy association modification procedure.

SMF obtains the frame detection information (optional), the dependency related instructions, and the frame dependency information from the PCF as shown in FIG. 9. In step 1, PCF gets the trigger message from AF (possibly via NEF) (option 2 as discussed in FIG. 8) or UDR (option 1 as discussed in FIG. 7) regarding the dependency related instructions and Frame dependency information of a traffic flow. In step 2, PCF decides to provide to SMF the dependency related instructions and frame dependency information for the involved QoS flows. In step 3, the dependency related instructions and frame dependency information with the associated QFI are sent to SMF using a Npcf SMPolicyControl UpdateNotify request message.

SMF further provides frame detection information (optional), the dependency related instructions, and the frame dependency information to RAN via AMF as part of Session Management (SM) information using PDU session modification procedure as shown in FIG. 10. Step 1 may use the procedure described above in FIG. 9, i.e., SMF gets the policy (including the dependency related instructions and the frame dependency information) from PCF on the PDU session. In step 2, SMF may trigger UPF resource adjustment according to the policy from PCF (including dependency related instruction(s) and frame dependency 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 the dependency related instruction(s) and frame dependency 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 frame detection information (optional), the dependency related instructions and the frame dependency information from the PCF using SMF policy association establishment (FIG. 11 (a)) or modification (FIG. 11 (b)) procedure as shown in FIG. 11. In alternative implementations, SMF may also provide the frame detection information (optional), the dependency related instructions, and the frame dependency information to RAN via AMF using PDU session establishment procedure.

As discussed in the previous embodiments, in case of QoS unfiilfillment in a reference frame (actual or predicted), RAN may extend the packet transmission time in this reference frame.

For instance, for a failed packet transmission in a reference frame within the allowed PDB, the first network entity 400 may perform the following steps in a first possible implementation:

1. Retransmit the packet if PDB + retransmission time <= Time interval to the last dependent frame until the retransmission is successful.

2. Shift the packets transmission in this frame and follow up dependent frames with the time interval to the next dependent frame of the successful retransmission.

3. Preempt/drop the packets of the follow up dependent frames whose transmission time would exceed the transmission time window of the last dependent frame due to the shift (i.e., time interval to the next dependent frame of the successful retransmission >= time interval to the last dependent frame of that dependent frame).

Following the first implementation, potentially saved frames in two examples are shown in FIG. 12. FIG. 12 shows examples of packet retransmission in a reference frame with the shifting of follow-up dependent frames ((a): packet retransmission in I-frame, (b): packet retransmission in a P-frame).

In the example shown in FIG. 12 (a), frame 1 (I-frame as indicated in the figure) is the erroneous frame. It is successfully transmitted at the transmission time slot of frame 6 (a B-frame as indicated in the figure) using extended transmission. All the follow-up dependent frames (frame 2-7) are shifted. Frame 8-12 can not be shifted (can only be preempt or dropped completely), since shifted frame 7 already reaches the end of GOP. Notably, without applying the method proposed in this disclosure, none of the frames in this GOP (frame 1-12) could be decoded due to the failure of the 1-frame. In other words, 7 frames (frame 1-7) are saved using the disclosed method. In the example shown in FIG. 12 (b), frame 5 (a P-frame as indicated in the figure) is the erroneous frame. It is successfully transmitted at the transmission time slot of frame 7. Using the same mechanism, all the follow-up dependent frames (frame 6-10) are shifted. Frame 11 and 12 are preempt or dropped. In this case, 6 frames (frame 5-10) are saved using the disclose method.

In a second possible implementation, all the follow-up dependent frames (e.g., P frames and B frames) in this DFG (e.g., GOP) are simply dropped without shifting (in step 2). Step 3 is not needed and skipped. Then the results would be as shown in FIG. 13, i.e., FIG. 13 (a) and FIG. 13 (b), respectively. In this implementation, the extended transmission may save the current “I” or “P” frame only. FIG. 13 shows the same examples as FIG 12 with the implementation of simply dropping all the follow-up dependent frames (left: packet retransmission in I-frame, right: packet retransmission in a P-frame).

In a third possible implementation, only the dependent frame which is also a reference frame for other dependent frames (e.g., “P” frame) are subject to the shift operation in step 2 as previously discussed. All the other dependent frames (e.g., “B” frame) are dropped. Consequently, step 3 applies only to the follow-up “P” frames. Potentially saved frames in two examples are shown in FIG. 14. Comparing to the first implementation, fewer frames are subject to the shift operation and the number of saved frames is similar. FIG. 14 shows examples of shifting only the dependent with type P ((a): packet retransmission in I-frame, (b): packet retransmission in a P-frame).

In the example shown in FIG. 14 (a), frame 1 (I-frame as indicated in the figure) is the erroneous frame. It is successfully transmitted at the transmission time slot of frame 6 (a B-frame as indicated in the figure) using extended transmission. Only the follow-up P-frames are shifted when necessary (frames 2, 5) and affected B-frames (frame 3, 4, 6, 7) are simply dropped. In case frame 8 could be transmitted with the original PDB without shifting, its follow up dependent frames (frame 9-12) will not be affected. This could potentially save 8 frames in the GOP (i.e., frame 1, 2, 5, 8, 8-12).

In the example shown in FIG. 14 (b), frame 5 (a P-frame as indicated in the figure) is the erroneous frame. It is successfully transmitted at the transmission time slot of frame 7. In this example, only frame 6, 7 (affected B-frames) are dropped. Other frames (frame 8-12) are not affected using extended transmission. Therefore, 6 frames could be saved (frame 5, 8-12) in the end.

This disclosure proposes a procedure at RAN for packet retransmission. Notably, preconditions of the procedure may be that frame information, frame dependency information, dependency related instruction, frame transmission status, should be available to RAN. The procedure may include a trigger condition, e.g., in case of a transmission failure of a packet with a maximum allowed ARQ (Automatic Repeated Request) consumed or PDB exceeded. The procedure may include the following steps.

Step 1 : If this packet belongs to a reference frame, continue with step 2. Otherwise, stop at this step.

Step 2: Identify the dependent frames of this frame based on the frame dependency information and time interval from the current frame to each of identified dependent frames. If the PDB + retransmission time < = time interval from the current frame to the identified last dependent frame, retransmit the packet. Otherwise, stop at this step.

Step 3: If the retransmission is not successful, go back to step 2. If the retransmission is successful, shift the transmission of the packet in this frame and also follow up dependent frames (with the time interval to the next dependent frame after the time of the successful retransmission). For each dependent frame, preempt/release the resource allocation if the time shift >= time interval to the last dependent frame of that dependent frame.

Step 4: Store/Update the Frame transmission status (e.g., at a local cache) of this frame and affected dependent frame(s) (e.g., resource allocation) based on the treatment of the data packet.

As discussed in the previous embodiments, in case of QoS unfulfillment in a reference frame, RAN may perform packet duplication in the reference frame to improve the transmission reliability.

In the transmission of a DFG, e.g., the group of frames 401 as shown in FIG. 4, the selective duplication of reference frames can be enabled. There are two options: Option 1 - statistically duplicate reference frame(s); Option 2 - dynamically duplicate for reference frame(s) based on the results of transmission in previous and/or current DFG(s). Notably, Option 2 may include two types of implementations.

FIG. 15 shows an example of dynamical duplication based on the transmission results in a previous DFG (GOP). In this implementation, whether to make duplication is determined according to the metric and threshold(s) of the quality of the previous transmission (e.g., previous DFG (s)).

The metrics of transmission quality includes at least one of the following:

- the percentage or number of successfully transmitted reference frames in the previous DFG, e.g., the higher the less need of the duplication,

- the percentage or number of the extended transmitted reference frame in the previous DFG, e.g., the higher the more need of the duplication,

- the percentage or number of retransmissions, e.g., the higher the more need of duplication,

- packet loss rate, etc.

FIG. 16 shows an example of dynamical duplication based on the transmission results in the current DFG (GOP). In this implementation, whether to make duplication is determined according to the frame status in the current DFG.

The retransmission of a failed reference frame can be duplicated. Besides, the subsequent reference frame in the same DFG can be also duplicated. The duplication of reference frames can be terminated when both copies of the reference frames are successfully transmitted.

Upon the activation of duplication in a reference frame, the transmission of some of the dependent frame(s) can be avoided for compensating the increase of data rate due to duplication.

The duplication and transmission avoidance in RAN can be done by PDCP layer with the following enhancement:

- In duplication activate status, instead of duplicating all packets in a QoS flow, the PDCP only duplicates selected packets according to the aforementioned criteria.

- The PDCP layer can avoid the transmission of packets in the corresponding one or more dependent frame(s) to compensate for the increased data rate. According to an embodiment of this disclosure, packet retransmission and duplication for a reference frame can be used as a combination. For instance, in case of a failed packet transmission in a reference frame, RAN may extend the packet transmission time and duplicated the packet in the retransmission. In such implementation, the number of retransmission can be reduced with the cost of a temporary increased transmission data rate. Comparing to the pure duplication solution discussed in the previous embodiment, only the failed packet instead of all the packets in a reference frame will be duplicated.

Optionally, RAN/QoS Assurance Entity may obtain the frame information from the data packet (e.g., Frame INFO included in the packet header) and/or derive the frame information based on frame detection information (locally configured or from the PCF). For instance, the frame detection information can be represented as a mapping table between the timestamp or packet sequence number to a frame (e.g., as starting/ending packet). RAN obtains such mapping table from PCF. Then RAN gets the packet sequence number/time stamp from each data packet and uses the mapping table to derive the frame information for each data packet. In this case, the same procedure as described in one of the previous embodiments discussed in FIG. 10 - FIG. 12 can be used for RAN to obtain the frame detection information from PCF.

The frame information can also be provided to RAN via a combination of the packet header and PCF signaling. For example, RAN obtains the frame ID from the packet header and obtains the frame type from PCF. In another example, RAN obtains frame ID and some frame type (e.g., “I” frame) from the packet header and other frame type from PCF. In a further example, RAN obtains frame ID and occasionally also frame type (e.g., a dynamically inserted “I” frame from the application) from the packet header. The frame type information obtained from the packet header takes precedence over the frame type information obtained from the PCF.

FIG. 17 shows a method 1700 according to an embodiment of the disclosure, particularly for handling a group of frames 401 with inter-dependency. Notably, the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets. In a particular embodiment, the method 1700 is performed by the first network entity 400 shown in FIG. 4. The method 1700 comprises a step 1701 of obtaining from a second network entity 600, frame dependency information 402 of the group and a plurality of dependency related instructions 403. Each dependency related instruction 403 indicates at least one operation 404 on one or more frames of the group, the at least one operation 404 being based on the frame dependency information 402. The method 1700 further comprises a step 1702 of performing the at least one operation on the one or more frames, in response to one of more trigger events. Possibly, the second network entity 600 is the second network entity shown in FIG. 4 or FIG. 6.

FIG. 18 shows a method 1800 according to an embodiment of the disclosure, particularly for assisting of handling a group of frames 401 with inter-dependency. Notably, the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets. In a particular embodiment, the method 1800 is performed by a second network entity 600 shown in FIG. 6. The method 1800 comprises a step 1801 of obtaining frame dependency information 402 of the group and a plurality of dependency related instructions 403. The method 1800 comprises a step 1802 of providing, to a first network entity 400, the frame dependency information 402 of the group and the plurality of dependency related instructions 403. Each dependency related instruction 403 indicates the first network entity 400 to perform at least one operation 404 on one or more frames of the group, the at least one operation 404 being based on the frame dependency information 402. Possibly, the first network entity 400 is the network entity shown in FIG. 4 or FIG. 6.

In the disclosure, network entities and methods for handling and assisting in handling a group of frames with inter-dependency are proposed. This disclosure enables correlated packet group/frame level QoS treatment (i.e., extended packet transmission with or without packet duplication for important packets) in a QoS flow in mobile networks. In this way, a better service experience for the user in case of radio resource shortage or disturbances can be assured. The transmission reliability of important packets in a QoS flow (e.g., packets in the dependency/reference frame) via packet extended transmission (with or without packet duplication) can be improved. Further, this disclosure allows for real-time resource coordination between packets with frame dependency in a QoS flow via controlling the actions for the handling of dependent frames. This disclosure also allows for controlled packet dropping (based on frame dependency and importance of packets) instead of random/prioritized packet dropping. According to the proposed approach, radio resource usage in case of radio resource shortage is more efficient. Transmission of packets which are useless or less important for the application (e.g., due to failure to deliver the reference/dependency packets) is avoid, therefore the radio resource can be saved without impacts to the application Quality of Experience (QoE).

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 first network entity 400, or the second network entity 600, 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 first network entity 400, or the second network entity 600 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 first network entity (400) for handling a group of frames (401) with inter-dependency, wherein the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets, and wherein the first network entity (400) is configured to: obtain, from a second network entity (500), frame dependency information (402) of the group and a plurality of dependency related instructions (403), wherein each dependency related instruction (403) indicates at least one operation (404) on one or more frames of the group, the at least one operation (404) being based on the frame dependency information (402); and perform the at least one operation (404) on the one or more frames, in response to one or more trigger events.

2. The first network entity (400) according to claim 1, wherein the one or more trigger events include that one or more packets belonging to a specific frame are not successfully transmitted according to a predefined requirement, wherein the first network entity (400) is further configured to: determine that the specific frame of the group is an erroneous frame, when the one or more packets belonging to the specific frame are not successfully transmitted according to the predefined requirement.

3. The first network entity (400) according to claim 2, wherein performing the at least one operation (404) on the one or more frames comprises: determining whether the type of the specific frame is the first type or the second type based on the frame dependency information (402); determining one or more instructions from the plurality of dependency related instructions (403) based on the determined type of the specific frame; and performing at least one operation (404) indicated by the determined one or more instructions on the specific frame.

39

4. The first network entity (400) according to claim 3, wherein the plurality of dependency related instructions (403) includes a first set of instructions, wherein the determined one or more instructions that are performed on the specific frame are determined from the first set of instructions, and the first set of instructions includes one or more operations:

- extended packet transmission for a duration determined based on the frame dependency information (402),

- duplication of packets of the extended packet transmission,

- dropping of remaining transmission,

5. The first network entity (400) according to claim 3, wherein, when the type of the specific frame is the first type, performing the at least one operation (404) on the one or more frames further comprises: determining a set of frames of the group that have dependency on the specific frame based on the frame dependency information (402); determining one or more instructions from the plurality of dependency related instructions (403); and performing at least one operation (404) indicated by the determined one or more instructions on the determined set of frames.

6. The first network entity (400) according to claim 5, wherein the plurality of dependency related instructions (403) further includes a second set of instructions, wherein the determined one or more instructions that are performed on the determined set of frames are determined from the second set of instructions, wherein the second set of instructions includes one or more operations:

- dropping one or more frames from the set of frames,

- conditional dropping one or more frames from the set of frames,

- delaying one or more frames from the set of frames for a duration determined based on the frame dependency information (402),

- suspending of a notification about unsuccessful transmission of one or more frames from the set of frames to another network entity.

40

7. The first network entity (400) according to one of the claims 1 to 6, wherein the frame dependency information (402) of the group includes an order of the frames in the group, and/or one or more dependency relationships between the frames of the group.

8. The first network entity (400) according to claim 7, wherein the frame dependency information (402) of the group further comprises one or more of:

- a frame identifier, and/or an application layer type, -a position of each frame in the group,

-a frame group structure,

- a starting frame, an ending frame, or a size of the group,

9. The first network entity (400) according to one of the claims 2 to 8, configured to: obtain frame information of the specific frame of the group, wherein the frame information includes a first indication that is indicative of an identifier of that frame; and identify the specific frame that the one or more packets belong to, based on the frame information.

10. The first network entity (400) according to claim 9, wherein the frame information further includes a second indication that is indicative of an application layer type of the specific frame which can be mapped to the first type and/or the second type.

11. The first network entity (400) according to claim 9 and 10, wherein obtaining frame information of the specific frame comprises: deriving the frame information of the specific frame by processing the plurality of packets of the specific frame based on frame detection information, wherein the frame detection information is locally configured or obtained from the second network entity (600); or extracting the frame information of the specific frame from the plurality of packets of the specific frame; or obtaining the frame information by processing information derived based on the frame detection information and information extracted from the plurality of packet of the specific frame.

41

12. The first network entity (400) according to claim 11, wherein the frame detection information comprises one or more of

- a frame group structure.

13. The first network entity (400) according to one of the claims 1 to 12, wherein the group of frames (401) comprises a sequence of video frames, and the group of frames (401) includes an I-frame, a P-frame and a B-frame, wherein the I-frame has no dependency on other frames of the sequence, the P-frame has a dependency on the I-frame or a previous P-frame, and the B-frame has one or more dependency on one or more of the I-frame and the P-frame.

14. The first network entity (400) according to one of the claims 1 to 13, wherein the first network entity (400) is located at an access node.

15. A second network entity (600) for assisting of handling a group of frames (401) with inter-dependency, wherein the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets, and wherein the second network entity (500) is configured to: obtain frame dependency information (402) of the group, and a plurality of dependency related instructions (403); and provide, to a first network entity (400), the frame dependency information (402) of the group and the plurality of dependency related instructions (403), wherein each dependency related instruction (403) indicates the first network entity (400) to perform at least one operation (404) on one or more frames of the group, the at least one operation being based on the frame dependency information (402).

16. The second network entity (500) according to claim 15, wherein the frame dependency information (402) of the group includes an order of the frames in the group, and/or one or more dependency relationships between the frames of the group.

17. The second network entity (500) according to claim 15 or 16, wherein the frame dependency information (402) of the group further includes one or more of - a frame identifier, and/or an application layer type,

- a position of each frame in the group,

- a frame group structure,

- a starting frame, an ending frame, or a size of the group,

18. The second network entity (500) according to one of the claims 15 to 17, wherein the frame dependency information (402) of the group, and/or the set of dependency related instructions (403) are obtained from an application layer entity directly or indirectly via other network entity.

19. The second network entity (500) according to one of the claims 15 to 18, wherein obtaining the frame dependency information (402) of the group and/or the set of dependency related instructions (403) includes: deriving the frame dependency information (402) of the group and/or the set of dependency related instructions (403) from one or more of the following: a formula, a plurality of parameters based on a group of picture structure, and a mapping table.

20. The second network entity (500) according to one of the claims 15 to 19, configured to: provide frame detection information to the first network entity (400), wherein the frame detection information comprises one or more of:

- a frame group structure.

21. A method for handling a group of frames (401) with inter-dependency, wherein the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets, wherein the method comprises: obtaining, from a second network entity (500), frame dependency information (402) of the group and a plurality of dependency related instructions (403), wherein each dependency related instruction (403) indicates at least one operation (404) on one or more frames of the group, the at least one operation being based on the frame dependency information (402); and performing the at least one operation (404) on the one or more frames, in response to one of more trigger events.

22. A method for assisting of handling a group of frames (401) with inter-dependency, wherein the group comprises frames of at least a first type and a second type, wherein each frame of the second type has dependency on at least one frame of the first type, wherein each frame of the group comprises a plurality of packets, wherein the method comprises: obtaining frame dependency information (402) of the group and a plurality of dependency related instructions (403), and providing, to a first network entity (400), the frame dependency information (402) of the group and the plurality of dependency related instructions (403), wherein each dependency related instruction (403) indicates the first network entity (400) to perform at least one operation (404) on one or more frames of the group, the at least one operation being based on the frame dependency information (402).

23. A computer program product comprising a program code for carrying out, when implemented on a processor, the method according to claim 21 or 22.

44