Apparatus and method for dynamic traffic handling of application triggers

Abstract

This invention relates to a control entity, a network entity, and an event-based processing (AF) for event-based traffic processing. The invention proposes a control entity for: acquiring application-related event-based processing information, wherein the event-based processing information indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event; determining an event-based processing configuration based on the event-based processing information; and providing the event-based processing configuration to a network entity, wherein the event-based processing configuration instructs the network entity to perform event-based traffic processing on traffic from the application. The invention also proposes a network entity for acquiring the event-based processing configuration and performing event-based traffic processing on traffic from the application according to the event-based processing configuration.

Description

Technical Field

[0001] This invention relates to communication networks, and more particularly to traffic processing in communication networks. The invention proposes control entities, network entities, application function (AF) entities, and corresponding methods for event-based traffic processing in networks. Background Technology

[0002] Haptic and multimodal communication services are used in many scenarios (e.g., industry, robotics, telepresence, virtual reality, augmented reality, healthcare, road traffic, serious gaming, education, etc.). These services typically involve mixed traffic (video / audio, sensor readings, and haptic data), requiring low latency and high reliability for interaction. Supporting this real-time (RT) media communication in mobile networks is extremely challenging due to the flexible and variable nature of wireless environments and the significant variations in traffic demands within specific areas. Applications treat RT traffic exceeding the packet delivery latency budget as lost. Packet loss (especially the loss of critical packets) can severely impact the user's experience, i.e., Quality of Experience (QoE).

[0003] The transport or application layer provides different mechanisms to recover media content in case of lost critical data packets during transmission. However, this transport / application layer packet retransmission / insertion is transparent to the mobile network and may therefore be inefficient, i.e., may introduce additional latency. For example, even though queued packets may no longer need to be transmitted, inserted Instantaneous Decoder Refresh (IDR) packets can only be transmitted after packets already in the mobile network's transmission queue. Retransmitted video frames or streaming frames, although they may have tighter deadlines due to retransmission, will still be transmitted after frames already in the mobile network's transmission queue.

[0004] Therefore, there is a need for an advanced solution that can improve both the efficiency of the application layer / transport mechanism (e.g., error recovery) and the user's QoE. Summary of the Invention

[0005] In view of the above limitations, the present invention aims to reduce traffic latency when transmitting through congested mobile networks. One objective is to implement customized traffic processing for different types of data packets in mobile networks. Another objective is to enable processing to quickly adapt to changes in application layer traffic characteristics. A further objective is to achieve accurate traffic processing to improve network resource utilization.

[0006] These and other objectives are achieved by the inventive solutions provided in the appended independent claims. Advantageous implementations are further specified in the dependent claims.

[0007] A first aspect of the present invention provides a control entity for controlling event-based traffic processing, configured to: acquire application-related event-based processing information, wherein the event-based processing information indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event; determine an event-based processing configuration based on the event-based processing information; and provide the event-based processing configuration to a network entity, wherein the event-based processing configuration instructs the network entity to perform event-based traffic processing on traffic from the application.

[0008] This invention also proposes a control entity that determines an event-based handling configuration (EbHC) based on an event-based handling configuration (EbHI) and provides the EbHC to the UP so as to instruct the UP to perform specific traffic processing on certain selected data packets or data packet sets when a specific application event is detected. It is worth noting that the traffic originates from the application's UP (i.e., the application server or application client). In this invention, a data packet can be a Protocol Data Unit (PDU), which is the basic unit of data packet transmission in a 3GPP network. A data packet set can be called a PDU set, comprising one or more PDUs carrying a payload of an information unit generated at the application layer (e.g., a frame or video slice for Extended Reality (XR) services).

[0009] In this way, the present invention proposes a scheme that supports customized event-based traffic processing, wherein the network can control traffic processing according to application configuration based on UP events (e.g., receiving a specific type of PDU / PDU set).

[0010] In one implementation of the first aspect, the control entity is further configured to obtain the event-based processing information from the AF via the network exposure function (NEF) and / or user data repository (UDR) function, or to obtain the event-based processing information according to information pre-configured in the control entity.

[0011] Control entities, such as Policy Control Functions (PCFs), can obtain event-based processing information from the application via NEF and UDR. In a specific example, the control entity can obtain event-based processing information or at least a portion of event-based processing information locally. In this example, the control entity could be a Session Management Function (SMF) within the PCF, with event-based processing information pre-configured within the SMF.

[0012] In one implementation of the first aspect, the event-based processing information includes one or more of the following: - A description of the triggering event and / or the event ID that indicates the triggering event; - One or more traffic processes corresponding to the triggering event or event ID; - One or more processing configurations corresponding to the triggering event or event ID.

[0013] For example, event-based processing information can be implemented as a mapping table, which consists of a list of application-triggered events specified by the application, the corresponding traffic processing, and the target PDUs.

[0014] In one implementation of the first aspect, the one or more triggering events include one or more of the following events: - A data packet or set of data packets carrying an event ID with a specific value. -Specific types of data packets or data sets - Data packets or sets of data packets with specific importance.

[0015] Optionally, the triggering event here can be a detected packet (e.g., in the packet header) carrying a specific event ID, a detected set of PDUs / PDUs of a specific type, or a detected set of PDUs / PDUs with a specific importance level. When such a packet or set of packets is detected, event-based traffic processing is triggered.

[0016] In one implementation of the first aspect, the type of data packet or data packet set includes: - Packets or sets of packets carrying instantaneous decoder refresh (IDR) frames. - A packet or set of packets carrying a full intra-frame request (FIR). - A data packet or set of data packets indicating a negative acknowledgment (NACK), or - Retransmit data packets or sets of data packets.

[0017] The type of a data packet (PDU) or data packet set (PDU set) is the type of application layer information it carries (e.g., I-frames or P-frames of a video). Examples of such PDU / PDU set types can be NACK, FIR, retransmission, IDR, etc. The PDU / PDU set type can be explicitly indicated by the application using a PDU / PDU set type ID in the data packet header or by using PDU Set Importance (PSI).

[0018] In one implementation of the first aspect, the one or more traffic processing corresponding to the triggering event includes one or more of the following: - Adjust one or more parameters related to the target data packet or target data set. - Adjust one or more parameters related to processing the target data packet or target data packet set. - Discard the target data packet or target data packet set. - Preempt the target data packet or target data packet set; - Manages queues that store target data packets or sets of target data packets.

[0019] Traffic processing includes parameter tuning (e.g., timer tuning, priority boosting / de-priority, etc.) and different actions (e.g., PDU dropping or preemption, clearing queues) that will be applied to one or more selected PDUs / PDU sets (referred to as target PDUs in this invention).

[0020] In one implementation of the first aspect, the one or more processing configurations corresponding to the triggering event include one or more of the following: - A standard used to select one or more target data packets or a set of target data packets. - The timer for dropping the one or more target data packets or sets of target data packets expires or is extended. - Increase or decrease the priority of one or more target data packets or sets of target data packets. - Adjust one or more Quality of Service (QoS) parameters associated with the one or more target data packets or target data sets.

[0021] To allow for customized PDU set processing, UP network entities are provided with processing configurations for different types of PDUs (sets), so that the UP network entity can enforce determined traffic processing / configuration on specific PDUs when a specific type of PDU / PDU set is detected.

[0022] In one implementation of the first aspect, the criteria for selecting one or more target data packets or sets of target data packets include one or more of the following: - Including flow-level standards that include flow information or flow descriptions. - Includes one or more of the following packet or packet set level criteria: transport status, QoS parameters, packet or packet set type, and packet or packet set importance. -A time standard including the waiting time and / or arrival time of data packets or sets of data packets in the queue. - A standard used to exclude packets or sets of packets that trigger triggering events. - A criterion for selecting the data packet or data set using parameters associated with the data packet or data set that triggered the triggering event.

[0023] It is worth noting that the target PDU may or may not include the triggering PDU / PDU set, i.e., the data packet or set of data packets that trigger the triggering event. For example, related processing can be defined for PDUs with a specific arrival time in the outbound queue. When the triggering PDU / PDU set (meeting the arrival time criteria) enters the same outbound queue, the triggering PDU / PDU set will also be processed accordingly.

[0024] In one implementation of the first aspect, the target data packet or the target data packet set includes one or more data packets or data packet sets that satisfy one or more of the criteria.

[0025] In one implementation of the first aspect, the event-based processing configuration instructs the network entity to perform one or more traffic processing and / or configurations on one or more target data packets or sets of target data packets when the one or more triggering events are detected.

[0026] In other words, when a UP network entity detects a specific type of PDU / PDU set, it performs determined traffic processing / configuration on that specific PDU.

[0027] In one implementation of the first aspect, the event-based processing configuration includes one or more of the following: - Configuration / rules for specific traffic handling - Configuration / rules used to detect the one or more triggering events. - Configuration / rules used to identify the one or more target data packets or sets of target data packets. - Configuration / rules used to mark one or more detected triggering events in the packet header. - Auxiliary information used to map a detected triggering event to an event ID. - Information used to map one or more traffic processing / configurations to network action IDs, and / or - Information used to map specific configurations / rules for specific traffic processing to event-based processing rule IDs.

[0028] Specifically, EbHC can be implemented as a configuration / rule / extended QoS template for UP entities, indicating specific traffic processing / configuration for a target PDU when a specified application-triggered event (e.g., a specific type of PDU / PDU set) is detected.

[0029] In one implementation of the first aspect, the network entity is an access network entity, wherein the control entity is further configured to provide the access network entity with the event-based processing information and / or the event-based processing configuration using a session modification procedure.

[0030] In one example, the control entity could be an SMF that can, for example, use a PDU session modification procedure to provide EbHI / EbHC to the Radio Access Network (RAN).

[0031] A second aspect of the invention provides a network entity for performing event-based traffic processing, configured to: obtain an event-based processing configuration from a control entity or management entity, wherein the event-based processing configuration instructs the network entity to perform event-based traffic processing on traffic from an application; and perform event-based traffic processing on traffic from the application according to the event-based processing configuration.

[0032] This invention proposes a network entity that, upon detecting a specific type of PDU / PDU set, implements determined traffic processing / configuration for a specific PDU. Event-based processing configuration can be provided by the CP entity (i.e., the control entity). Alternatively, event-based processing configuration can be configured locally on the network entity (by the management network entity).

[0033] In one implementation of the second aspect, the network entity is further configured to: upon detecting one or more triggering events, perform one or more traffic processing and / or configurations on one or more target data packets or target data packet sets according to the event-based processing configuration.

[0034] In one implementation of the second aspect, the event-based processing configuration includes one or more of the following: - Configuration / rules for specific traffic handling - Configuration / rules used to detect the one or more triggering events. - Configuration / rules used to identify the one or more target data packets or sets of target data packets. - Configuration / rules used to mark one or more detected triggering events in the packet header. - Auxiliary information used to map a detected triggering event to an event ID. - Information used to map one or more traffic processing / configurations to network action IDs, and / or - Information used to map specific configurations / rules for specific traffic processing to event-based processing rule IDs.

[0035] Specifically, EbHC can be implemented as a configuration / rule / extended QoS template for UP entities, indicating specific traffic processing / configuration for a target PDU when a specified application-triggered event (e.g., a specific type of PDU / PDU set) is detected.

[0036] In one implementation of the second aspect, the one or more triggering events include one or more of the following events: - A data packet or set of data packets carrying an event ID with a specific value. -Specific types of data packets or data sets - Data packets or sets of data packets with specific importance.

[0037] Optionally, the triggering event here can be a detected packet (e.g., in the packet header) carrying a specific event ID, a detected set of PDUs / PDUs of a specific type, or a detected set of PDUs / PDUs with a specific importance level. When such a packet or set of packets is detected, event-based traffic processing is triggered.

[0038] In one implementation of the second aspect, the type of data packet or data packet set includes: - Packets or sets of packets carrying IDR frames, - Packets or sets of packets carrying FIR. - A packet or set of packets indicating NACK, or - Retransmit data packets or sets of data packets.

[0039] The type of a data packet (PDU) or data packet set (PDU set) is the type of application layer information it carries (e.g., I-frames or P-frames of a video). Examples of this PDU / PDU set type can be NACK, FIR, retransmission, IDR, etc. The PDU / PDU set type can be explicitly indicated by the application in the data packet header using a PDU / PDU set type ID or using PSI.

[0040] In one implementation of the second aspect, the one or more traffic processing corresponding to the triggering event includes one or more of the following: - Adjust one or more parameters related to the target data packet or target data set. - Adjust one or more parameters related to processing the target data packet or target data packet set. - Discard the target data packet or target data packet set. - Preempt the target data packet or target data packet set; - Manages queues that store target data packets or sets of target data packets.

[0041] To allow for customized PDU set processing, UP network entities are provided with processing configurations for different types of PDUs (sets), so that the UP network entity can enforce determined traffic processing / configuration on specific PDUs when a specific type of PDU / PDU set is detected.

[0042] In one implementation of the second aspect, the network entity is further configured to: detect the one or more triggering events; and identify the one or more target data packets or one or more target data packet sets.

[0043] This invention proposes an enhanced UPF operation at network entities. The enhanced UPF operation may include, for example, detecting application-triggered events (i.e., identifying a PDU / PDU set of a specific type or importance, and identifying the event ID carried by the PDU / PDU set).

[0044] In one implementation of the second aspect, the network entity is a UP function (UPF), which is used to indicate the detected one or more triggering events to an access network entity by marking the detected one or more triggering events in the packet header.

[0045] Enhanced UPF operations may also include: marking detected triggering events in the GTP header, for example, with an index number; and performing event-based processing on the target PDU.

[0046] In one implementation of the second aspect, the network entity is further configured to mark the detected one or more triggering events in the packet header using one of the following implementations: - Expand existing packet type fields -Reuse PSI field - Use the new data set type field, or - Use the new event ID field.

[0047] Optionally, the detected triggering event can be indicated to the RAN by a network entity (e.g., UPF) in the GTP header via the options described above. It is understood that if the PSI is used as the triggering event, the UPF does not need to mark it.

[0048] In one implementation of the second aspect, the network entity is the access network entity, which is configured to: obtain event-based processing information related to the application from the control entity, wherein the event-based processing information indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event; and perform the event-based traffic processing according to the event-based processing information and / or the event-based processing configurations.

[0049] In one example, the network entity could be the RAN, and the control entity (i.e., the SMF) could provide EbHI / EbHC to the RAN, for example, using a PDU session modification procedure.

[0050] In one implementation of the second aspect, the network entity is further configured to provide an instruction to the control entity, wherein the instruction indicates that the network entity is capable of performing event-based traffic processing.

[0051] Optionally, when a network entity is capable of processing based on UP events, it can instruct a control entity, such as an SMF. The SMF can then use this instruction to select a UPF and determine the UPF configuration / rules for that UPF.

[0052] A third aspect of the invention provides an AF for assisting event-based traffic processing, for providing an application-related event-based processing information to a control entity, wherein the event-based processing information indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event.

[0053] The present invention also proposes an AF for providing event-based processing information to CP entities (i.e., control entities, such as PCF or SMF) to configure the network for event-based traffic processing.

[0054] In one implementation of the third aspect, the AF is further configured to provide the event-based processing information to the control entity via NEF and / or UDR functions.

[0055] In one implementation of the third aspect, the AF is further configured to send a request to the NEF during the establishment of an AF session, wherein the request includes the event-based processing information.

[0056] Possibly, the AF uses existing procedures for establishing AF sessions with the desired QoS to provide event-based processing information to the PCF via the NEF. In this case, the AF sends a request to the NEF to reserve resources for the AF session using the Nnef_AFsessionWithQoS_Create request message, which includes event-based processing information.

[0057] In one implementation of the third aspect, the AF is further configured to provide the UDR function with the event-based processing information for future AF sessions.

[0058] Optionally, AF can provide event-based processing information in UDR for future AF sessions based on the triggered event.

[0059] In one implementation of the third aspect, the AF is further used to mark the one or more triggering events in the packet header using an index.

[0060] Alternatively, AF can directly mark the triggering event at N6 using an index in the Real-time Transport Protocol (RTP) extended header.

[0061] A fourth aspect of the present invention provides a method for controlling event-based traffic processing performed by a control entity, comprising: acquiring application-related event-based processing information, wherein the event-based processing information indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event; determining an event-based processing configuration based on the event-based processing information; and providing the event-based processing configuration to a network entity, wherein the event-based processing configuration instructs the network entity to perform event-based traffic processing on traffic from the application.

[0062] The implementation of the method in the fourth aspect can correspond to the implementation of the control entity in the first aspect described above. The method and its implementation in the fourth aspect achieve the same advantages and effects as the control entity and its implementation in the first aspect described above.

[0063] A fifth aspect of the present invention provides a method for performing event-based traffic processing performed by a network entity, comprising: obtaining an event-based processing configuration from a control entity or a management entity, wherein the event-based processing configuration instructs the network entity to perform event-based traffic processing on traffic from an application; and performing event-based traffic processing on traffic from the application according to the event-based processing configuration.

[0064] The implementation of the method in the fifth aspect can correspond to the implementation of the network entity in the second aspect described above. The method and its implementation in the fifth aspect achieve the same advantages and effects as the network entity and its implementation in the second aspect described above.

[0065] A sixth aspect of the invention provides a method for assisting event-based traffic processing performed by an AF, comprising providing an application-related event-based processing information to a control entity, wherein the event-based processing information indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event.

[0066] The implementation of the method in the sixth aspect can correspond to the implementation of AF in the third aspect described above. The method and its implementation in the fifth aspect achieve the same advantages and effects as AF and its implementation in the third aspect described above.

[0067] A seventh aspect of the present invention provides a computer program product including program code for performing, when implemented on a processor, the program code according to the fourth aspect and any implementation thereof, the fifth aspect and any implementation thereof, or the sixth aspect and any implementation thereof.

[0068] An eighth aspect of the invention provides a computer-readable medium including instructions that, when executed by a computer, cause the computer to perform the method according to the fourth aspect and any implementation thereof, the fifth aspect and any implementation thereof, or the sixth aspect and any implementation thereof.

[0069] It should be noted that all devices, elements, units, and modules described in this application can be implemented in software or hardware elements or any combination thereof. All steps performed by the various entities described in this application, and the functions described as being performed by the various entities, are intended to indicate that the respective entities are suitable for or used to perform the respective steps and functions. Although in the following description of specific embodiments, the specific functions or steps to be performed by external entities are not reflected in the detailed description of the specific elements of the entities performing the specific steps or functions, those skilled in the art will understand that these methods and functions can be implemented by the corresponding software or hardware elements or any combination thereof. Attached Figure Description

[0070] The following detailed description of specific embodiments illustrates the above aspects and implementations of the present invention in conjunction with the accompanying drawings, in which: Figure 1 This demonstrates video error recovery using NACK feedback messages and a new reference image; Figure 2 This demonstrates video error recovery using NACK feedback messages and retransmissions; Figure 3 This shows the one-byte RTP header extension format; Figure 4 The control entity of an embodiment of the present invention is shown; Figure 5 The network entity of an embodiment of the present invention is shown; Figure 6 An AF embodiment of the present invention is shown; Figure 7 The proposed entity according to an embodiment of the present invention is deployed in a 3GPP network architecture; Figure 8 This illustrates the enhancements in CP interaction in an embodiment of the present invention; Figure 9 This illustrates an enhancement to the UPF rules according to an embodiment of the present invention; Figure 10 The operation flow of event-based processing at the UPF in an embodiment of the present invention is shown; Figure 11 The PDU session UP protocol is shown; Figure 12 This diagram illustrates the sequence of establishing an AF session according to an embodiment of the present invention. Figure 13 This diagram illustrates a sequence of steps for setting policies for future AF sessions according to an embodiment of the present invention. Figure 14 This illustrates the policy association modification process initiated by PCF according to an embodiment of the present invention; Figure 15 The PDU session modification process according to an embodiment of the present invention is illustrated; Figure 16 The RT media transport protocol configuration of an embodiment of the present invention is shown; Figure 17 The method of an embodiment of the present invention is shown; Figure 18 The method of an embodiment of the present invention is shown; Figure 19 The method of an embodiment of the present invention is illustrated. Detailed Implementation

[0071] The following describes illustrative embodiments of control entities, network entities, event handlers (AFs), and corresponding methods for event-based traffic processing with reference to the accompanying drawings. While this description provides detailed examples of possible implementations, it should be noted that these details are exemplary only and do not limit the scope of this application.

[0072] Furthermore, embodiments or examples may be referenced to other embodiments or examples. For instance, any descriptions (including but not limited to terms, elements, processes, explanations, and / or technical advantages) mentioned in one embodiment or example may also be applicable to other multiple embodiments or examples.

[0073] As mentioned earlier, the transport layer or application layer provides different mechanisms to recover media content in the event of loss of important data packets during transmission. One solution approach is a new transport at the application layer. This new transport can be based on the same content (e.g., selected retransmission of lost packets) or new content (e.g., IDR). The new transport can be for individual packets or groups of packets (e.g., Quick User Datagram Protocol (UDP) Internet Connections (QUIC) stream frames, video frames / slices).

[0074] For example, an encoder can inject an IDR frame to stop decoding errors propagating on the decoding side (e.g., lost packets attributed to previous IDRs or multiple reference frames). In H.264 / H.265, an IDR frame specifies that no frame following that IDR frame may reference any frame preceding it.

[0075] QUIC packets can contain multiple frames of different types (ACK-eliciting frames / NON-ACK-eliciting frames). QUIC acknowledges each ACK-eliciting packet. Application data sent in a stream frame is retransmitted in a new stream frame, preventing the current stream from being blocked by retransmitted stream frames.

[0076] Video error recovery also exists in other scenarios. Figure 1This illustrates video error recovery using a NACK feedback message and a new reference image. It can be understood that when one or more PDUs in the reference image are lost, the receiver detects the loss or partial reception of the reference image and returns an error report as NACK feedback. Accordingly, upon receiving the NACK message, the sender can generate another reference image and send the recovered image to the receiver.

[0077] In this situation, an IDR or reference image may be inserted from time to time due to packet loss events. Several images (e.g., video frames) that reference the lost reference image become useless, while PDUs belonging to those images that have not yet been transmitted may still occupy queues in the RAN.

[0078] Figure 2 This illustrates video error recovery using NACK feedback messages and retransmissions. It can be understood that when one or more PDUs in the reference image (blue) are lost, the receiver detects the lost data packet, sends a NACK message, and suspends decoding while buffering incoming data packets. Upon receiving a NACK message, the sender retransmits the requested data packet. The receiver resumes decoding after receiving the requested data packet.

[0079] In this scenario, other packets in the image, if still in the queue within the RAN, can remain in the queue for a longer period to be transmitted until the RAN receives the requested packet. In another implementation option, retransmitted packets in the image should be transmitted before those in the queue, as the retransmitted packets experience additional transmission delays due to the retransmission.

[0080] 3GPP Release 18 XR and Media Services (XRM) supports identifying the importance of PDU sets to applications based on RTP header extensions. In congested situations, the network can use this information to discard less important PDU sets (e.g., PDU sets carrying P frames).

[0081] 3GPP specifies PDU set information, including: PDU set sequence number (PSSN), indication of the end PDU of the PDU set (E), PDU sequence number (PSN) within the PDU set, PDU set size in bytes (PSSize), and PDU set importance (PSI). When each RTP packet enters the mobile network, the application adds an RTP extension header (such as...) to each RTP packet... Figure 3The PDU set information is provided in the diagram. The UPF in the mobile network can then identify the start / end of the PDU set, which PDU set it belongs to, and the importance of the PDU set by examining the RTP header extension of the downlink traffic. The UPF can further pass the identified PDU set information to the RAN by marking the network header (i.e., the GTP header). In the event of network congestion, the RAN can discard lower-importance PDUs in the media stream (those belonging to a lower-importance PDU set).

[0082] However, existing solutions do not support customized PDU set processing configurations from applications. The type of PDU can differ for different application protocols (e.g., PDU sets carrying IDR frames, PDU sets carrying FIR frames, PDU sets carrying Picture Loss Indication (PLI) frames, PDU sets carrying Redundant Encoding (RED) frames) and / or transport protocols (e.g., PDU sets carrying QUIC stream frames, PDU sets carrying QUIC Acknowledgment (ACK) frames, etc.). The processing required for each PDU set type in the network depends on the logic of the application / transport protocol. The network is typically unaware of the application / transport protocol logic, especially when application-layer traffic is encrypted. Therefore, the application must inform the network which type of PDU set requires which type of processing.

[0083] Existing solutions do not support the processing of multiple PDU set types within QoS flows. Application layer and transport layer protocols are highly diverse and can have very different sets of PDU set types, including those carrying application layer / transport layer control plane content (e.g., Real-Time Transport Control Protocol (RTCP), ACK / NACK) and those carrying application layer up content (e.g., RTP, retransmissions, video / audio I-frames, video / audio P-frames, haptic information, etc.). Different types of PDU sets require different types of processing. However, current 3GPP mobile networks only recognize the importance of PDU sets and support simple priority-based processing. This cannot meet the differentiated processing requirements of various PDU set types.

[0084] The PDU set differentiation processing in 3GPP Release 18 only supports processing each PDU based on its PDU set importance in the event of network congestion. It is not possible to influence / “control” the processing of other PDUs of the application in the network (e.g., removing PDU sets that are no longer needed from the transport queue). On the other hand, CP-based processing adjustments (e.g., QoS sessions requested by AF in the current 3GPP network [1]) are not suitable for very dynamic traffic processing due to the long signaling path from the application to the 5GC CP to the 5GC UP and the associated latency. That is, none of the existing schemes support “UP event-based processing” (e.g., clearing the transport queue based on the specific PDU set type detected in the UP).

[0085] The objective of this invention is to reduce end-to-end (e2e) latency of media type traffic when transmitted through congested mobile networks. Based on the PDU set QoS support in 3GPP Release 18, this invention solves the technical problems of how to support customized PDU set processing configurations for different types of PDU sets in mobile networks, and how to enable PDU set processing to quickly adapt to changes in application layer traffic characteristics.

[0086] This invention proposes a control entity, a network entity, and an event-based flow (AF) for controlling, executing, and assisting event-based traffic processing in application traffic flows.

[0087] Figure 4 A control entity 400 suitable for controlling event-based traffic processing according to an embodiment of the present invention is shown. Specifically, an "event" refers to a UP event that triggers a specific UP process in a mobile network.

[0088] Control entity 400 may include a processing circuitry system (not shown) for performing, conducting, or initiating various operations of control entity 400 as described herein. The processing circuitry system may include hardware and software. Hardware may include analog circuitry systems, digital circuitry systems, or both. Digital circuitry systems may include components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. Control entity 400 may also include a memory circuitry system storing one or more instructions that can be executed by a processor or processing circuitry system (specifically, under software control). For example, the memory circuitry system may include a non-transitory storage medium storing executable software code that, when executed by a processor or processing circuitry system, causes the various operations of control entity 400 to be performed. In one embodiment, the processing circuitry system includes one or more processors and non-transitory memory connected to the one or more processors. Non-transient memory may carry executable program code that, when executed by one or more processors, causes control entity 400 to perform, conduct, or initiate the operations or methods described herein.

[0089] Control entity 400 is used to acquire application-related event-based processing information 401. Specifically, the event-based processing information 401 indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event. A triggering event is a UP event that triggers a specific UP process in the mobile network.

[0090] The control entity 400 is further configured to determine an event-based processing configuration 402 based on the event-based processing information 401, and provide the event-based processing configuration 402 to the network entity 410. The event-based processing configuration 402 instructs the network entity 410 to perform event-based traffic processing on traffic from the application.

[0091] This invention proposes a control entity 400 that enables a network to control traffic processing based on application configurations based on UP events. Specifically, control entity 400 may be a CP network entity that determines the event-based handling configuration (EbHC) and provides it to the UPF, thereby instructing the UP to perform specific traffic processing, detect specific application events, and identify target PDUs. For example, control entity 400 may be a PCF or SMF in the CP. Network entity 410 may be a RAN or a UPF in the UP.

[0092] In one implementation, control entity 400 is used to obtain event-based processing information 401 from AF 420 via NEF and / or UDR functions. Alternatively, control entity 400 may be used to obtain event-based processing information 401 based on information pre-configured in control entity 400.

[0093] Optionally, the event-based processing configuration 402 instructs the network entity 410 to perform one or more traffic processing and / or configurations on one or more target packets or sets of target packets when one or more triggering events are detected.

[0094] Accordingly, the present invention also proposes a network entity that, upon detecting a specific type of PDU / PDU set, performs determined traffic processing / configuration on a specific PDU. It is worth noting that this network entity can be a UP network entity.

[0095] Figure 5 A network entity 410 adapted to perform event-based traffic processing according to an embodiment of the present invention is illustrated. Specifically, the network entity 410 is configured to obtain an event-based processing configuration 402 from a control entity 400 or a management entity, wherein the event-based processing configuration 402 instructs the network entity 410 to perform event-based traffic processing on traffic from applications. The network entity 410 is then further configured to perform event-based traffic processing on traffic from applications according to the event-based processing configuration 402. It is worth noting that the control entity 400 may be... Figure 4 The control entity 400 shown.

[0096] Network entity 410 may include a processing circuitry (not shown) for performing, conducting, or initiating various operations of network entity 410 as described herein. The processing circuitry may include hardware and software. Hardware may include analog circuitry systems, digital circuitry systems, or both. Digital circuitry systems may include components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. Network entity 410 may also include a memory circuitry storing one or more instructions that can be executed by a processor or processing circuitry system (specifically, under software control). For example, the memory circuitry may include a non-transitory storage medium storing executable software code that, when executed by a processor or processing circuitry system, causes the various operations of network entity 410 to be performed. In one embodiment, the processing circuitry includes one or more processors and non-transitory memory connected to the one or more processors. Non-transient memory may carry executable program code that, when executed by one or more processors, causes network entity 410 to perform, conduct, or initiate the operations or methods described herein.

[0097] According to one embodiment of the present invention, network entity 410 can also be used to: upon detecting one or more triggering events, perform one or more traffic processing and / or configurations on one or more target data packets or target data packet sets according to event-based processing configuration 402.

[0098] It is worth noting that the target data packet or target data packet set refers to the PDU or PDU set applicable to a specific UP process.

[0099] According to one embodiment of the present invention, network entity 410 can also be used to provide instructions to control entity 400, wherein the instructions instruct network entity 410 to perform event-based traffic processing.

[0100] In this embodiment, network entity 410 may be a UPF. A UPF capable of processing UP events can provide instructions to control entity 400 (e.g., SMF). Control entity 400 can then use these instructions to select a UPF and determine the UPF configuration / rules for that UPF.

[0101] Furthermore, the present invention proposes an application network entity (e.g., AF) that configures the network for event-based traffic processing by providing event-based processing information to a CP network entity. This event-based processing information defines specific traffic processing (e.g., packet dropping) for a specific PDU (e.g., target PDU) under a specific application event (e.g., sending a specific type of PDU / PDU set).

[0102] Figure 6 An embodiment of the present invention illustrates an AF 420 for assisting event-based traffic processing. Specifically, the AF 420 is used to provide application-related event-based processing information 401 to a control entity 400. Specifically, the event-based processing information 401 indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event. It is worth noting that the control entity 400 may be... Figure 4 The control entity 400 shown.

[0103] According to one embodiment of the present invention, AF 420 can also be used to provide event-based processing information 401 to control entity 400 via NEF and / or UDR functions.

[0104] Figure 7 This section illustrates exemplary deployments of network entities proposed in the 3GPP network architecture as enhanced AF, enhanced PCF / SMF, and enhanced RAN / UPF. The AF provides event-based processing information 401 to the PCF via NEF / UDR. Downlink traffic is discussed here.

[0105] In this embodiment, the control entity 400 can be the PCF or SMF in the CP. The network entity 410 can be the RAN or the UPF in the UP.

[0106] The PCF / SMF determines the EbHC based on the EbHI and provides the EbHC to the RAN / UPF (e.g., as part of UPF configuration / UPF rules). The UPF performs event-based traffic processing based on the EbHC. In another implementation, the SMF provides the EbHC to the RAN (e.g., as part of a QoS template). The RAN performs event-based traffic processing on behalf of the UPF. The UPF only performs the detection of application events and marks the application event in the downlink traffic (e.g., indicating the detected event ID in the network header) to pass the detected triggering event to the RAN.

[0107] Details regarding event-based processing information 401 (i.e., EbHI) and event-based processing configuration 402 (i.e., EbHC) will be discussed in the following sections.

[0108] Figure 8The required enhancements to CP interaction are shown, where the application provides 5GS traffic processing (e.g., packet transmission / queue management configuration) on an event-triggered basis.

[0109] In the first aspect, AF-NEF / PCF interaction can use a mapping table that indicates an EbHI. An EbHI indicates the mapping between a specific triggering event and the associated traffic processing, as well as the processing configuration. Exemplary contents of an EbHI are shown in detail in Table 1. Specifically, Table 1 shows a mapping table of triggering events, processing categories, and processing configurations.

[0110]

[0111] Table 1 According to one embodiment of the present invention, the event-based processing information 401 includes one or more of the following: - A description of the triggering event and / or the event ID that indicates the triggering event; - One or more traffic processes corresponding to the triggering event or event ID; - One or more processing configurations corresponding to the triggering event or event ID.

[0112] Optionally, the one or more triggering events include one or more of the following events: - A data packet or set of data packets carrying an event ID with a specific value. -Specific types of data packets or data sets - Data packets or sets of data packets with specific importance.

[0113] Optionally, the types of data packets or data sets include: - Packets or sets of packets carrying IDR frames, - Packets or sets of packets carrying FIR. - A packet or set of packets indicating NACK, or - Retransmit data packets or sets of data packets.

[0114] It is worth noting that the triggering event here can be a detected packet carrying a specific event ID (e.g., in the packet header), or a detected PDU / PDU set of a specific type. Examples of such PDU / PDU set types can be NACK, FIR, retransmission, IDR, etc. The PDU / PDU set type can be explicitly indicated by the application using a PDU / PDU set type ID in the packet header or using PSI. The PDU / PDU set type can also be derived by the network based on the traffic characteristics of this type of PDU / PDU set provided by the application. For example, the first 100 PDUs in a burst are type 1 PDUs. Another example is a PDU set of 5 to 10 bytes in size, which is a type 2 PDU set.

[0115] It is worth noting that the data packet set or PDU set discussed in this invention refers to a set of data packets that are of similar importance to the application and require similar Quality of Service (QoS) processing in the network. It is also noteworthy that the importance of a data packet or data packet set can be indicated by a value. It can be understood that when the importance level of data packet (or data packet set) A is higher than that of data packet (or data packet set) B, it means that data packet A is more important than data packet B.

[0116] According to one embodiment of the present invention, one or more traffic processing corresponding to the triggering event includes one or more of the following: - Adjust one or more parameters related to the target data packet or target data set. - Adjust one or more parameters related to processing the target data packet or target data packet set. - Discard the target data packet or target data packet set. - Preempt the target data packet or target data packet set; - Manages queues that store target data packets or sets of target data packets.

[0117] In other words, traffic processing or network processing may include parameter adjustments (e.g., timer adjustments, priority increase / decrease, etc.) and different actions (e.g., PDU dropping or preemption, or clearing the queue). Network processing is applied to one or more selected PDUs / PDU sets (referred to as target PDUs in this invention) according to PDU selection criteria. It is worth noting that a target packet or target packet set refers to a PDU or PDU set to which specific traffic processing is applied. It is understood that the target PDU may or may not include the triggering PDU / PDU set.

[0118] In one example, when an FIR (i.e., a triggering event) is detected in the RTCP feedback report in the uplink direction, the corresponding action could be to clear the blocking queue in the downlink direction within the RAN. In another example, when a new IDR is detected in the downlink direction, the corresponding action could be to clear the blocking queue in the downlink direction within the RAN. In yet another example, when a RED is detected in the downlink direction, the corresponding action could be to discard redundant PDU sets in the downlink, if necessary.

[0119] According to one embodiment of the present invention, one or more processing configurations corresponding to the triggering event include one or more of the following: - A standard used to select one or more target data packets or a set of target data packets. - Timeout or extension of the drop timer used for one or more target packets or sets of target packets. - Increase or decrease the priority of one or more target packets or sets of target packets. - Adjust one or more Quality of Service (QoS) parameters associated with one or more target packets or sets of target packets.

[0120] According to one embodiment of the present invention, the criteria for selecting one or more target data packets or sets of target data packets include one or more of the following: - Including flow-level standards that include flow information or flow descriptions. - Includes one or more of the following packet or packet set level criteria: transport status, QoS parameters, packet or packet set type, and packet or packet set importance. -A time standard that includes the waiting time and / or arrival time of packets or sets of packets in the queue. - A standard used to exclude packets or sets of packets that trigger triggering events. - A standard used to select a packet or set of packets by using parameters associated with the packet or set of packets that triggered the triggering event.

[0121] Possibly, the target data packet or target data packet set includes one or more data packets or data packet sets that satisfy one or more of the criteria.

[0122] When a specific PDU / PDU set type is identified based on traffic characteristics, the application can include such traffic characteristics in EbHI.

[0123] Figure 8 The second aspect provides PCF-SMF-RAN interaction to provide EbHC and QoS templates for QoS flows to the RAN and SMF.

[0124] This invention provides enhancements to CP-UP interactions. Specifically, for downlink, the SMF configures the UPF packet detection rule (PDR) to detect triggering events. The SMF configures the UPF forwarding action rule (FAR) based on event-based processing and detailed processing parameters based on EbHI. Optionally, the SMF can also configure the UPF rule to indicate the detected triggering event to the RAN (e.g., by marking it in the RTP header). For uplink, the SMF (via QoS rules) instructs the UE to detect the triggering event and indicates the triggering event to the Access Stratum (AS) layer according to EbHI.

[0125] Figure 9An enhanced UPF according to an embodiment of the present invention is shown. It is worth noting that the UPF shown here can be... Figure 4 Network entity 410 is shown. Embodiments of the present invention propose to enhance the UPF in two aspects to support event-based traffic processing at the UPF.

[0126] First, it was proposed that includes Figure 9 The diagram shows an enhanced UPF configuration / rules for event-based processing. Enhanced UPF configuration / rules include configuration / rules for detecting triggering events and / or target PDUs, configuration / rules for marking detected events in packet headers (e.g., GTP headers), and configuration / rules for specific processes (e.g., queue management, QoS parameter tuning, packet dropping / preemption, etc.). This type of enhanced UPF rule needs to be stored in the UPF after being received / updated from the SMF.

[0127] According to one embodiment of the present invention, the event-based processing configuration 402 includes one or more of the following: - Configuration / rules for specific traffic handling - Configuration / rules used to detect one or more triggering events. - Configuration / rules used to identify one or more target data packets or sets of target data packets. - Configuration / rules used to mark one or more detected triggering events in the packet header. - Auxiliary information used to map a detected triggering event to an event ID. - Information used to map one or more traffic processing / configurations to network action IDs, and / or - Information used to map specific configurations / rules for specific traffic processing to event-based processing rule IDs.

[0128] Second, an enhanced UPF operation was proposed. Figure 10 The diagram illustrates the operation flow of event-based processing at the UPF according to an embodiment of the present invention. Enhanced UPF operations may include, for example: detecting application-triggered events (i.e., identifying PDU / PDU sets of a specific type or importance, and identifying the event ID carried by the PDU / PDU set); marking the detected triggered events in the GTP header, for example, with an index number; and performing event-based processing on the target PDU.

[0129] Optionally, event-based processing may include one or more of the following: - Discard the selected PDU (i.e., the target packet or target packet set), for example, if the delay of the selected PDU is greater than the packet delay budget (PDB) / packet delay budget (PSDB), and / or if the selected PDU has low importance. - Set the discard timeout (in seconds) for the selected PDU to 0. - PDU transmission priority is increased (decreased), for example, the transmission is set to a different priority.

[0130] According to one embodiment of the present invention, network entity 410 can be used to: detect one or more triggering events; identify one or more target data packets or one or more target data packet sets.

[0131] According to one embodiment of the present invention, the network entity 410, as a UPF, can also be used to: indicate one or more detected triggering events to the access network entity by marking one or more detected triggering events in the packet header.

[0132] The detected triggering event can be indicated to the RAN by the UPF in the GTP header using the following options: extend the existing PDU Type field, reuse the PSI field, use the new PST field, or use the new EID field. It should be noted that if the PSI is used as the triggering event, the UPF does not need to mark it.

[0133] Optionally, network entity 410 can be used to mark one or more detected triggering events in the packet header using one of the following implementation methods: - Expand existing packet type fields -Reuse the data set importance field - Use the new data set type field, or - Use the new event ID field.

[0134] Figure 11 The TS 38.415 PDU Session UP protocol is illustrated. Specifically, the "PDU Type" field uses a value representing the PDU type it identifies; for example, 0 = DL PDU session information, 1 = UL PDU session information, and 2-15 = reserved for future PDU type expansion. The "PDU Set Importance [PSI]" field can include 4 bits and indicates the importance of this PDU set compared to other PDU sets in the same QoS flow.

[0135] Possibly, in this invention, a reserved value in the "PDU type" field can be used to indicate the PDU type from the application layer perspective as a triggering event. For example, for downlink applications, PDU type 1 is 2, where PDU type 1 is also a triggering event with ID 1. Optionally, the PSI value can be reused to indicate the PDU set type; for example, PSI = 1 indicates a PDU set of type 1, where the PDU set of type 1 is also a triggering event with ID 1.

[0136] In another example, a new information element for PST / EID could be introduced, such as the field "PDU / PDU set type [PST] / triggering event ID [EID]", which consists of 4 to 8 bits and includes an index indicating the type of the PDU / PDU set, or (from the application) the event ID carried by the PDU / PDU set. Here, "PST" represents the PDU set type ID, and "EID" represents the ID of the triggering event ID.

[0137] It is possible that the triggering PDU set can be marked only in the first or last PDU in the PDU set. Triggering PDUs / triggering PDU sets can be further distinguished using different PST / EID values.

[0138] According to one embodiment of the present invention, the criteria for selecting one or more target data packets or sets of target data packets include any one or a combination of the following: - Including flow-level standards that include flow information or flow descriptions. - Includes one or more of the following packet or packet set level criteria: transport status, QoS parameters, packet or packet set type, and packet or packet set importance. -A time standard that includes the waiting time and / or arrival time of packets or sets of packets in the queue. - A standard used to exclude packets or sets of packets that trigger triggering events. - A standard used to select a packet or set of packets by using parameters associated with the packet or set of packets that triggered the triggering event.

[0139] Flow-level standards may include service data flow (SDF) (e.g., 5-tuple), QoS flow identifier (QFI), and QoS templates (e.g., 5G QoS identifier (5QI), flow priority). PDU / PDU set-level standards may include transmission status (e.g., latency > PDB, PSDB, number of retransmissions upon failure), QoS parameters (e.g., PDU / PDU set importance), and PDU / PDU set type.

[0140] Time metrics can include, for example, waiting time in a queue, and arrival time.

[0141] Examples of PDU selection criteria include PDU / PDU set type, PSI, traffic description / flow ID, waiting time in the queue (e.g., beyond PDB / PSDB), arrival time (e.g., within a fixed time range relative to the triggering event, starting / ending at a specific event), etc. The selection can also be based on different queues within the UP entity.

[0142] The target PDU may or may not include triggering PDUs / PDU sets. For example, the relevant processing is for PDUs in the outbound queue that have a specific arrival time. When a triggering PDU / PDU set (meeting the arrival time criterion) enters the same outbound queue, that triggering PDU / PDU set will also be processed accordingly.

[0143] According to one embodiment of the present invention, the AF (i.e., AF 420) can use the existing process of "establishing an AF session with the required QoS" triggered by an application event to provide the PCF with event-based processing information of the flow via the NEF.

[0144] Figure 12 An embodiment of establishing an AF session with the desired QoS provided by the present invention is shown. It is worth noting that the PCF can be... Figure 4 The control entity 400 shown.

[0145] Specifically, perform the following steps: Step 1: The AF sends a request to reserve resources for the AF session using the Nnef_AFsessionWithQoS_Create request message. Specifically, this message may include the AF identifier, UE address, flow description, QoS reference, and optional alternative service requirements (containing one or more QoS reference parameters in priority order). Additionally, the message includes event-based processing information, i.e., Figure 4 or Figure 6 The event-based processing information 401 shown indicates to the NEF information about event triggering, event-based processing configuration, and target PDU.

[0146] Optionally, the AF request may include the time period or traffic volume of the requested QoS. NEF assigns a transaction reference ID to the Nnef_AFsessionWithQoS_Create request.

[0147] According to this embodiment, AF 420 is used to send a request to NEF during the establishment of an AF 420 session, wherein the request includes event-based processing information 401.

[0148] Step 2: The NEF authorizes the AF request and can apply policies to control the total amount of predefined QoS authorized to the AF. If authorization is not granted, steps 3 and 4 are skipped, and the NEF replies to the AF with a result value indicating authorization failure.

[0149] Step 3: The NEF interacts with the PCF by triggering an Npcf_PolicyAuthorization_Create request, providing the PCF with information such as the AF identifier, UE address, flow description, QoS reference, optional alternative service requirements (containing one or more QoS reference parameters in priority order), and event-based processing information 401. Any optionally received time periods or traffic volumes are also included and mapped to sponsored data connection information, for example, as defined in TS 23.203.

[0150] Steps 4 and 5 are the same as the standard AF setup procedure.

[0151] It is worth noting that the AF can send an Nnef_AFsessionWithQoS_Revoke request to the NEF to revoke the AF request. The NEF authorizes the revocation request and triggers the Npcf_PolicyAuthorization_Delete and Npcf_PolicyAuthorization_Unsubscribe operations for the AF request.

[0152] In another embodiment, the control entity 400 (PCF) can obtain some event-based processing information from the application via NEF and UDR. Figure 12 The present invention illustrates a process for setting policies for future AF sessions according to an embodiment of the present invention.

[0153] According to one embodiment of the present invention, AF 420 can also be used to provide the UDR function with event-based processing information 401 for future AF sessions, as shown in step 1.

[0154] Specifically, AF 420 can provide event-based processing information 401 in the UDR for future AF sessions, triggered by specific events. The PCF subscribes to the UDR on a specific application using an application ID. The PCF can then combine information received via the UDR with information received directly from the AF via the NEF (e.g., forced event triggers can be stored in the UDR, and optional or newly defined event triggers can be added via AF interaction). Default processing configurations can be stored in the UDR, while dedicated / dynamic configurations can be provided via AF interaction.

[0155] Table 2 shows an example of event-based processing information 401 stored in the UDR.

[0156]

[0157] Table 2 According to one embodiment of the present invention, the control entity 400 (PCF) can use existing SM policy association processes to provide event-based processing information 401 (and QoS templates for each QoS flow) on an event-by-event basis.

[0158] Specifically, SMF uses SMF policy associations to establish / modify processes locally and / or obtain event-based processing information from PCF 401. Figure 13 This illustrates the policy association modification process initiated by PCF according to an embodiment of the present invention.

[0159] Then, the SMF uses the PDU session modification procedure to provide the RAN with event-based processing information 401 and / or event-based processing configuration 402. Figure 14 The PDU session modification process according to an embodiment of the present invention is illustrated.

[0160] In one embodiment, the present invention provides enhancements to RAN CP-UP interactions. According to one embodiment of the invention, the RAN configures event-based transmissions (RAN AS layer / UE) based on an event trigger indication in the GTP header (for downlink traffic) or an event trigger indication detected by the UE (for uplink traffic). The RAN can also configure detailed transmission parameters / processes (e.g., priority, transmission timeout timer, packet drop / preemption) based on event-based processing information 401 and / or event-based processing configuration 402.

[0161] According to one embodiment of the invention, the application can directly mark the triggering event in the RTP extended header at N6 using an index. For example, the triggering event can be marked in a field (4 to 8 bits) indicating the PDU type, PDU set type, PST, or EID, particularly using an index indicating the type of the PDU / PDU set, or the event ID carried by the PDU / PDU set. In another example, the triggering PDU set can be marked only in the first or last PDU of the PDU set. Different index values ​​can be used to distinguish the triggering PDU / triggering PDU set.

[0162] exist Figure 16 Examples (a) and 10(b) show the one-byte RTP header extension format and the two-byte RTP header extension format.

[0163] Figure 17 A method 1700 according to an embodiment of the present invention is illustrated, specifically for controlling event-based traffic processing. In a particular embodiment, method 1700 is performed by... Figure 4 , Figure 5 and Figure 6The method 1700 is executed by a control entity 400 as shown in the figure. Method 1700 includes step 1701: obtaining application-related event-based processing information 401, wherein the event-based processing information 401 indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event. Method 1700 further includes step 1702: determining an event-based processing configuration 402 based on the event-based processing information. Furthermore, method 1700 includes step 1703: providing the event-based processing configuration 402 to network entity 410, wherein the event-based processing configuration 402 instructs network entity 410 to perform event-based traffic processing on traffic from the application. Possibly, network entity 410 may be... Figure 4 or Figure 5 The network entities shown.

[0164] Figure 18 A method 1800 according to an embodiment of the present invention is illustrated, specifically for performing event-based traffic processing. In a particular embodiment, method 1800 is performed by... Figure 4 or Figure 5 The network entity 410 shown is executed. Method 1800 includes step 1801: obtaining an event-based processing configuration 402 from a control entity 400 or a management entity, wherein the event-based processing configuration 402 instructs the network entity 410 to perform event-based traffic processing on traffic from the application. Then, method 1800 further includes step 1802: performing event-based traffic processing on the traffic from the application according to the event-based processing configuration 402. Possibly, the control entity 400 may be... Figure 4 , Figure 5 and Figure 6 One of the control entities shown.

[0165] Figure 19 A method 1900 according to an embodiment of the present invention is illustrated, specifically for assisting event-based traffic processing. In a particular embodiment, method 1800 is performed by... Figure 6 The AF 420 shown is executed. Method 1900 includes step 1901: providing application-related event-based processing information 401 to control entity 400, wherein the event-based processing information 401 indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event. Possibly, control entity 400 may be... Figure 4 , Figure 5 and Figure 6 One of the control entities shown.

[0166] In summary, this invention proposes a method and apparatus for supporting customized event-based traffic processing, wherein the network can control traffic processing based on application configurations based on UP events (i.e., the receipt of a specific type of PDU / PDU set). It includes: This application proposes the following embodiments: 1. Apply network entities (e.g., Figure 6 The AF 420 shown configures the network for event-based traffic processing by providing event-based processing information to CP network entities. This event-based processing information defines specific traffic processing (e.g., packet dropping) for a specific PDU (e.g., target PDU) under a specific application event (e.g., sending a specific type of PDU / PDU set).

[0167] 2. CP network entities (e.g., Figure 4 The control entity 400 shown determines the event-based processing configuration (EbHC) and instructs the UP to perform specific traffic processing, detect specific application events, identify target PDUs and provide them to the UPF.

[0168] 3. UP network entities (e.g., Figure 5 The network entity 410 shown implements determined traffic processing / configuration on a specific PDU when a specific type of PDU / PDU set is detected.

[0169] The relevant signaling includes interactions between AF and CP network entities, interactions between CP network entities, and interactions between CP network entities and UP network entities.

[0170] In one example, EbHI can be implemented as a mapping table consisting of a list of application-triggered events specified by the application, the corresponding traffic processing, and the target PDUs.

[0171] EbHC can be implemented as a configuration / rule / extended QoS template for UP entities, indicating specific traffic processing / configuration for a target PDU when a specified application-triggered event (e.g., a specific type of PDU / PDU set) is detected. More specifically, the content of EbHC includes configuration / rules for specific traffic processing, configuration / rules for detecting application-triggered events, configuration / rules for identifying the target PDU, and configuration / rules for marking the detected application-triggered event in the packet header. EbHC may also include auxiliary information for mapping the detected specific application-triggered event (e.g., a specific PDU / PDU set type) to event IDs, information for mapping specific traffic processing configuration sets to network action IDs, and / or information for mapping specific event-based traffic processing rules to event-based processing rule IDs.

[0172] As can be seen, this invention supports event-based processing triggered by the type / importance of the received PDU / PDU set (UP method). This scheme achieves low latency and rapid adaptation to changes in application traffic, while also reducing network signaling (i.e., no additional CP-UP interaction). Furthermore, this invention supports event-based processing of selected PDUs, as well as customized configurations of event-based processing (from application / transport). It achieves accurate traffic processing, better QoE, and also improves network resource utilization.

[0173] This invention has been described in conjunction with various embodiments as examples and implementations. However, based on a study of the drawings, the invention, and the appended claims, those skilled in the art will understand and implement other variations when practicing the claimed embodiments of the invention. In the claims and the specification, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" does not exclude a plurality. A single element or other unit may fulfill the function of several entities or items described in the claims. The fact that certain measures are enumerated in dissimilar dependent claims does not in itself imply that combinations of these measures cannot be used in advantageous implementations.

[0174] Furthermore, any method of the embodiments of the present invention can be implemented in a computer program having code modules, which, when run by a processing module, causes the processing module to perform the method steps. The computer program is included in a computer-readable medium of the computer program product. The computer-readable medium can substantially include any memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), flash memory, electrically erasable PROM (EEPROM), or a hard disk drive.

[0175] Furthermore, those skilled in the art recognize that embodiments of control entity 400 or network entity 410 include the necessary communication capabilities in the form of functions, devices, units, elements, etc., for executing the scheme. Examples of other such devices, units, elements, and functions include: processors, memories, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selection units, switches, interleavers, deinterleavers, modulators, modems, inputs, outputs, antennas, amplifiers, receiving units, transmitting units, DSPs, trellis-coded modulation (TCM) encoders, TCM decoders, power supply units, power feeders, communication interfaces, communication protocols, etc., which are suitably arranged together to execute the scheme.

[0176] Specifically, for example, the processor of control entity 400 or network entity 410 may include a central processing unit (CPU), processing unit, processing circuitry, processor, application-specific integrated circuit (ASIC), microprocessor, or one or more instances of other processing logic capable of interpreting and executing instructions. Therefore, the expression "processor" can refer to a processing circuitry system comprising multiple processing circuits, such as any, some, or all of the aforementioned processing circuits. The processing circuitry system can also perform data processing functions for inputting, outputting, and processing data, including data buffering and device control functions such as call processing control, user interface control, etc.

Claims

1. A control entity (400) for controlling event-based traffic processing, characterized in that, Used for: Obtain application-related event-based processing information (401), wherein the event-based processing information (401) indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event; The event-based processing configuration (402) is determined based on the event-based processing information (401). The event-based processing configuration (402) is provided to the network entity (410), wherein the event-based processing configuration (402) instructs the network entity (410) to perform event-based traffic processing on traffic from the application.

2. The control entity (400) according to claim 1, characterized in that, Used for: The event-based processing information (401) is obtained from the application function entity (420) through network open functions and / or user database functions; or The event-based processing information (401) is obtained based on the information pre-configured in the control entity (400).

3. The control entity (400) according to claim 1 or 2, characterized in that, The event-based processing information (401) includes one or more of the following: A description of the triggering event and / or the event ID that indicates the triggering event; One or more traffic processes corresponding to the triggering event or event ID; One or more processing configurations corresponding to the triggering event or event ID.

4. The control entity (400) according to claim 3, characterized in that, The one or more triggering events include one or more of the following events: A data packet or set of data packets carrying an event ID with a specific value. Specific types of data packets or data packet sets, Data packets or sets of data packets that have specific importance.

5. The control entity (400) according to claim 4, characterized in that, The types of data packets or data packet sets include: A data packet or set of data packets carrying an instantaneous decoder refresh (IDR) frame. A packet or set of packets carrying a full intra-frame request (FIR). The data packet or set of data packets indicating a negative acknowledgment, or Retransmit data packets or sets of data packets.

6. The control entity (400) according to any one of claims 3 to 5, characterized in that, The one or more traffic processing corresponding to the triggering event includes one or more of the following: Adjust one or more parameters related to the target data packet or target data set. Adjust one or more parameters related to the processing of the target data packet or target data packet set. Discard the target data packet or target data packet set. Preempt the target data packet or target data packet set; Manage queues that store target data packets or sets of target data packets.

7. The control entity (400) according to any one of claims 3 to 6, characterized in that, The one or more processing configurations corresponding to the triggering event include one or more of the following: Criteria for selecting one or more target data packets or sets of target data packets The timer for dropping the one or more target data packets or sets of target data packets times out or is extended. Increase or decrease the priority of one or more target data packets or sets of target data packets. Adjust one or more Quality of Service (QoS) parameters associated with the one or more target data packets or target data packet sets.

8. The control entity (400) according to claim 7, characterized in that, The criteria for selecting one or more target data packets or sets of target data packets include one or more of the following: Flow-level standards, including flow information or flow descriptions, A packet or packet set-level standard includes one or more of the following: transport status, QoS parameters, packet or packet set type, and packet or packet set importance. This includes a time standard for the waiting time and / or arrival time of data packets or sets of data packets in the queue. A standard used to exclude packets or sets of packets that trigger a triggering event. Criteria for selecting the data packet or data set using parameters associated with the data packet or data set that triggered the triggering event.

9. The control entity (400) according to claim 8, characterized in that, The target data packet or the target data packet set includes one or more data packets or data packet sets that satisfy one or more of the criteria.

10. The control entity (400) according to any one of claims 1 to 9, characterized in that, The event-based processing configuration (402) instructs the network entity (410) to perform one or more traffic processing and / or configurations on one or more target packets or target packet sets when the one or more triggering events are detected.

11. The control entity (400) according to claim 10, characterized in that, The event-based processing configuration (402) includes one or more of the following: Configuration / rules for specific traffic processing Configuration / rules used to detect the one or more triggering events. Configuration / rules used to identify the one or more target data packets or sets of target data packets. Configuration / rules used to mark one or more detected triggering events in the packet header. Auxiliary information used to map a detected triggering event to an event ID. Information used to map one or more traffic processing / configurations to network action IDs, and / or Information used to map specific configurations / rules for specific traffic processing to event-based processing rule IDs.

12. The control entity (400) according to any one of claims 1 to 11, characterized in that, The network entity (410) is an access network entity (410), wherein the control entity (400) is further configured to: The event-based processing information (401) and / or the event-based processing configuration (402) are provided to the access network entity (410) using the session modification procedure.

13. A network entity (410) for performing event-based traffic processing, characterized in that, Used for: Obtain an event-based processing configuration (402) from a control entity (400) or management entity, wherein the event-based processing configuration (402) instructs the network entity (410) to perform event-based traffic processing on traffic from the application; Event-based traffic processing is performed on the traffic from the application according to the event-based processing configuration (402).

14. The network entity (410) according to claim 13, characterized in that, Used for: When one or more triggering events are detected, one or more traffic processing and / or configurations are performed on one or more target packets or target packet sets according to the event-based processing configuration (402).

15. The network entity (410) according to claim 14, characterized in that, The event-based processing configuration (402) includes one or more of the following: Configuration / rules for specific traffic processing Configuration / rules used to detect the one or more triggering events. Configuration / rules used to identify the one or more target data packets or sets of target data packets. Configuration / rules used to mark one or more detected triggering events in the packet header. Auxiliary information used to map a detected triggering event to an event ID. Information used to map one or more traffic processing / configurations to network action IDs, and / or Information used to map specific configurations / rules for specific traffic processing to event-based processing rule IDs.

16. The network entity (410) according to claim 14 or 15, characterized in that, The one or more triggering events include one or more of the following events: A data packet or set of data packets carrying an event ID with a specific value. Specific types of data packets or data packet sets, Data packets or sets of data packets that have specific importance.

17. The network entity (410) according to claim 16, characterized in that, The types of data packets or data packet sets include: A data packet or set of data packets carrying an instantaneous decoder refresh (IDR) frame. A packet or set of packets carrying a full intra-frame request (FIR). The data packet or set of data packets indicating a negative acknowledgment, or Retransmit data packets or sets of data packets.

18. The network entity (410) according to any one of claims 14 to 17, characterized in that, The one or more traffic processing corresponding to the triggering event includes one or more of the following: Adjust one or more parameters related to the target data packet or target data set. Adjust one or more parameters related to the processing of the target data packet or target data packet set. Discard the target data packet or target data packet set. Preempt the target data packet or target data packet set; Manage queues that store target data packets or sets of target data packets.

19. The network entity (410) according to any one of claims 14 to 18, characterized in that, Used for: Detect one or more of the triggering events; Identify the one or more target data packets or one or more target data packet sets.

20. The network entity (410) according to claim 19, characterized in that, The network entity (410) is a user plane function, and the network entity (410) is used for: The one or more detected triggering events are indicated to the access network entity (410) by marking the one or more detected triggering events in the packet header.

21. The network entity (410) according to claim 20, characterized in that, Used for: Use one of the following implementation methods to mark the detected one or more triggering events in the packet header: Extend existing packet type fields, Reuse the data set importance field. Use the new data set type field, or Use the new event ID field.

22. The network entity (410) according to any one of claims 13 to 19, characterized in that, The network entity (410) is the access network entity (410), and the network entity (410) is used for: Obtain event-based processing information (401) related to the application function entity (420) from the control entity (400), wherein the event-based processing information (401) indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event; The event-based traffic processing is performed based on the event-based processing information (401) and / or the event-based processing configuration (402).

23. The network entity (410) according to any one of claims 13 to 22, characterized in that, Used for: An instruction is provided to the control entity (400), wherein the instruction instructs the network entity (410) to perform event-based traffic processing.

24. An application function entity (420) for assisting event-based traffic processing, characterized in that, Used for: Provide the control entity (400) with application-related event-based processing information (401), wherein the event-based processing information (401) indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event.

25. The application functional entity (420) according to claim 24, characterized in that, Used for: The event-based processing information (401) is provided to the control entity (400) through network open functions and / or user database functions.

26. The application functional entity (420) according to claim 25, characterized in that, Used for: During the establishment of the application function entity session, a request is sent to the network open function, wherein the request includes the event-based processing information (401).

27. The application functional entity (420) according to claim 25, characterized in that, Used for: The event-based processing information (401) for future application function entity (420) sessions is provided to the user database function.

28. The application functional entity (420) according to any one of claims 24 to 27, characterized in that, Used for: The one or more triggering events are marked with an index in the packet header.

29. A method (1700) for controlling event-based traffic processing, characterized in that, include: Obtain (1701) application-related event-based processing information (401), wherein the event-based processing information (401) indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event; The event-based processing configuration (402) is determined (1702) based on the event-based processing information (401). Provide the network entity (410) with the event-based processing configuration (402) (1703), wherein the event-based processing configuration (402) instructs the network entity (410) to perform event-based traffic processing on traffic from the application.

30. A method (1800) for performing event-based traffic processing executed by a network entity (410), characterized in that, include: Obtain (1801) an event-based processing configuration (402) from a control entity (400) or a management entity, wherein the event-based processing configuration (402) instructs the network entity (410) to perform event-based traffic processing on traffic from the application; (1802) Event-based traffic processing is performed on the traffic from the application according to the event-based processing configuration (402).

31. A method (1900) for assisting event-based traffic processing performed by an application functional entity (420), characterized in that, include: Provide (1901) application-related event-based processing information (401) to the control entity (400), wherein the event-based processing information (401) indicates one or more triggering events and one or more traffic processing and / or processing configurations corresponding to each triggering event.

32. A computer program product, characterized in that, Includes program code for executing the method (1700, 1800, 1900) according to any one of claims 29 to 31 when implemented on a processor.

Images