Techniques for discard mechanism

Abstract

The present application relates to apparatus and components including apparatuses, systems, and methods for discarding packet data units (PDUs).

Description

Technology for discarding mechanisms

[0001] Cross-reference to other applications This application claims priority to U.S. Provisional Application No. 63 / 542,711, filed October 5, 2023, entitled “TECHNOLOGIES FOR DISCARDING MECHANISM,” the entire contents of which are incorporated herein by reference for all purposes. Technical Field

[0002] This application relates generally to communication networks, and more specifically to techniques for discarding packet data units (PDUs). Background Technology

[0003] Congestion control is designed to prevent network overload by regulating the amount of data being transmitted over the network. The goal of congestion control can be to maintain high-level network performance, even under heavy load conditions. The network can monitor its performance. When congestion is detected, the system can take appropriate actions to alleviate it.

[0004] Networks can implement packet dropping mechanisms to control congestion. In packet dropping, the network selectively discards packets when congestion is detected. However, excessive packet dropping can lead to information loss and degrade overall network performance and user experience. Attached Figure Description

[0005] Figure 1 illustrates a network environment according to some implementation schemes.

[0006] Figure 2 illustrates various aspects of a user equipment (UE) according to some implementation schemes.

[0007] Figure 3 illustrates a signaling diagram according to some implementation schemes.

[0008] Figure 4 illustrates a signaling diagram according to some implementation schemes.

[0009] Figure 5 illustrates various aspects of supporting information based on some implementation schemes.

[0010] Figure 6 illustrates the operational flow / algorithm structure according to some implementation schemes.

[0011] Figure 7 illustrates the operational flow / algorithm structure according to some implementation schemes.

[0012] Figure 8 illustrates user equipment according to some implementation schemes.

[0013] Figure 9 illustrates network nodes according to some implementation schemes. Detailed Implementation

[0014] The following detailed description refers to the accompanying drawings. The same reference numerals may be used to identify the same or similar elements in different drawings. In the following description, specific details, such as particular structures, architectures, interfaces, and / or techniques, are set forth for illustrative and non-limiting purposes to provide a thorough understanding of various aspects of some embodiments. However, it will be apparent to those skilled in the art that various aspects may be practiced in other examples departing from these specific details. In some instances, descriptions of well-known devices, circuits, and methods have been omitted so as not to obscure the description of the aspects with unnecessary detail. For the purposes of this document, the phrase “A or B” means (A), (B), or (A and B), and the phrase “based on A” means “at least partially based on A,” for example, it can be “based solely on A” or it can be “partially based on A.”

[0015] The following is a glossary of terms that may be used in this disclosure.

[0016] As used herein, the term "circuit" means, is part of, or includes the following: hardware components such as electronic circuits, logic circuits, processors (shared, dedicated, or grouped) or memories (shared, dedicated, or grouped), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable system-on-chips (SoCs)), and / or digital signal processors (DSPs) configured to provide the described functionality. In some aspects, a circuit may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuit" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) and program code for executing the functionality of that program code. In these aspects, the combination of hardware elements and program code may be referred to as a particular type of circuit.

[0017] As used herein, the term "processor circuit" means, is part of, or includes the following: circuitry capable of sequentially and automatically performing a series of arithmetic or logical operations; or recording, storing, or transmitting digital data. The term "processor circuitry" may also refer to an application processor; a baseband processor; a central processing unit (CPU); a graphics processing unit; a single-core processor; a dual-core processor; a triple-core processor; a quad-core processor; or any other device capable of executing or otherwise operating computer-executable instructions (such as program code); a software module; or a functional process.

[0018] As used herein, the term "interface circuit" refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term "interface circuit" can refer to one or more hardware interfaces; for example, a bus, I / O interface, peripheral component interface, or network interface card.

[0019] As used herein, the term "user equipment" or "UE" refers to a device with radio communication capabilities and can describe network resources in a communication network. The terms "user equipment" or "UE" are considered synonymous and can refer to a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term "user equipment" or "UE" can include any type of wireless / wired equipment or any computing device that includes a wireless communication interface.

[0020] As used herein, the term "computer system" means any type of interconnected electronic device, computer device, or component thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to each other and configured to share computing resources or network resources.

[0021] As used herein, the term "resource" refers to physical or virtual devices, physical or virtual components within a computing environment, or physical or virtual components within a specific device, such as computer equipment, mechanical equipment, memory space, processor / CPU time, processor / CPU utilization, processor and accelerator load, hardware time or utilization, power supply, input / output operations, port or network sockets, channel / link allocation, throughput, memory utilization, storage, network, databases and applications, units of workload, etc. "Hardware resource" can refer to computer, storage, or network resources provided by physical hardware components. "Virtualized resource" can refer to computer, storage, or network resources provided by virtualization infrastructure to applications, devices, systems, etc. The terms "network resource" or "communication resource" can refer to resources that computer equipment / systems can access via a communication network. The term "system resource" can refer to any kind of shared entity providing services and can include computing or network resources. System resources can be considered as a coherent set of functions, network data objects, or services that can be accessed through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.

[0022] As used herein, the term "channel" refers to any tangible or intangible transmission medium used to transmit data or data streams. The term "channel" may be synonymous or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term indicating a means or medium through which data is transmitted. Additionally, as used herein, the term "link" refers to a connection between two devices for the purpose of sending and receiving information.

[0023] As used in this article, the terms "instantiate" and "instantiate" refer to the creation of an instance. "Instance" also refers to the concrete occurrence of an object, which may occur, for example, during the execution of program code.

[0024] The term "connection" can refer to an established signaling relationship between two or more elements at a common communication protocol layer through a communication channel, link, interface, or reference point.

[0025] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as networked computers, network hardware, network equipment, network nodes, virtualized network functions, etc.

[0026] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to a single piece of content within an information element or a data element that contains content. An information element may include one or more additional information elements.

[0027] Figure 1 illustrates a network environment 100 according to some embodiments. Network environment 100 may include a user equipment (UE) 104 communicatively coupled to a base station (BS) 108 of a radio access network (RAN) 110. In some embodiments, base station 108 is a next-generation node B (gNB) providing one or more 3GPP New Radio (NR) cells. In other embodiments, base station 108 is an evolved Node B (eNB) providing one or more Long Term Evolution (LTE) cells. The air interface through which UE 104 and base station 108 communicate may be compatible with 3GPP Technical Specifications (TS), such as those defining fifth-generation (5G) NR or later system standards (e.g., sixth-generation (6G) standards). Base station 108 may provide user plane and control plane protocol termination to UE 104.

[0028] Network environment 100 may include a core network node (CNN) 106. For example, core network node 106 may include a 5th generation core network (5GC) or a newer generation core network. Core network node 106 may be coupled to base station 108 via fiber optic or wireless backhaul. Core network node 106 may provide functionality to UE 104 via base station 108. These functions may include managing subscriber profile information, subscriber location, service authentication, or switching between voice and data sessions.

[0029] The core network node 106 may include one or more network functions, such as Application Function (AF) 112 or Session Management Function (SMF) 116. Application Function 112 may be responsible for accessing Network Open Function (NEF), establishing interfaces between applications and application layers, interacting with Policy Control Function (PCF) for policy control, and providing application services to subscribers.

[0030] The application may have components that run on the application server 102. The application can interact with the UE 104 or RAN 110 through the application function 112 of the core network node 106.

[0031] The SMF 116 can handle interactions with the Access and Mobility Management Function (AMF), PCF, or User Plane Function (UPF). The SMF 116 can create, update, or remove PDU sessions and manage session contexts with the UPF.

[0032] In some instances, applications associated with the application layer can generate data for transmission, such as video streams or text messages. The data generated by the application can be organized into packets at the transport layer. These application-associated packets may be referred to as Service Data Streams (SDFs).

[0033] Each SDF can be mapped to a Quality of Service (QoS) flow. Each SDF can be associated with a QoS requirement. The QoS flow associated with an SDF can allocate network resources to provide the required QoS.

[0034] One or more QoS flows can be packetized into a Protocol Data Unit (PDU) session for transmission over the network. The PDU session provides Internet Protocol (IP) connectivity between the UE 104 and the data network.

[0035] UE 104 and base station 108 can establish a Data Radio Bearer (DRB) to support the transmission of data over a radio link between the two nodes. Each QoS stream can be mapped to a DRB. The DRB handles the transmission of data over the air interface. In one example, these DRBs can be used for services from extended reality (XR) applications, which involve delivering large amounts of data, including real and virtual images and audio, for presentation to a user. Data traffic (e.g., packets or PDUs) can be grouped into PDU sets. A PDU set may include one or more PDUs (or packets) carrying a payload of an information unit generated at the application layer. In one example, for an XR service, the information unit generated at the application layer may be one or more frames or video slices. All PDUs in a PDU set can be transmitted within the same QoS stream.

[0036] PDU set importance (PSI) can be a parameter associated with a PDU set, QoS flow, or DRB. PSI indicates the level or importance of an associated packet or PDU set. In one example, the lower the PSI level of a PDU set, the more important the PDU. PSI-based packet dropping can drop packets based on their associated PSI level.

[0037] UE 104 may discard packets. For example, the Packet Data Convergence Protocol (PDCP) sublayer of Layer 2 of the 3GPP protocol stack may discard packets mapped to QoS flows. The DRB may be configured to discard some or the entire PDU set when one packet in the PDU set is lost or discarded. For example, the DRB may discard the PDU set for the purpose of a PDU Set Integrity Disposal Indication (PSIHI). The PSIHI may indicate whether the application layer requires each packet in the PDU set. In some implementations, base station 108 may detect congestion and signal UE 104 to apply a packet discarding mechanism. Base station 108 may transmit configuration message 120 to instruct UE 104 to apply a PSI-based packet discarding mechanism.

[0038] Configuration message 120 configures a PSI-based packet dropping mechanism. In one instance, configuration message 120 configures one or more timers associated with the PSI-based dropping mechanism. For example, a PSI level can be associated with a timer. When the timer expires, one or more packets with the same PSI level as the PSI level associated with the timer can be dropped.

[0039] In another instance, configuration message 120 configures a PSI threshold. The PSI threshold can be associated with a QoS flow. Different QoS flows or different DRBs can have different PSI thresholds. Once the PSI-based packet dropping mechanism is activated, UE 104 can drop a set of packets or PDUs from a QoS flow or DRB that have a PSI level equal to or greater than the PSI threshold associated with the QoS flow.

[0040] Dropping packets can impact the UE's quality of experience. It is desirable to reduce the impact of congestion control on the UE's quality of experience through packet dropping. Providing PSI attributes (such as statistical parameters associated with the PSI of QoS flows, PDU sessions, or DRBs) can assist base station 108 in configuring PSI-based packet dropping at UE 104 while taking quality of experience into consideration.

[0041] In one implementation, UE 104 may provide UE Auxiliary Information (UAI) 130 to RAN 110 and base station 108. UE Auxiliary Information 130 may include one or more PSI attributes, such as the range of PSI levels or the statistical distribution of PSI levels associated with QoS flows or DRBs.

[0042] Application server 102 may be communicatively coupled to core network node 106. In one embodiment, application server 102 may transmit application server auxiliary information (AS AI) 150 to base station 108 via application function 112. AS AI 150 may include one or more PSI attributes associated with QoS flows or DRBs of uplink services of UE 104. Application function 112 may configure base station 108 via N2 interface, core network node 106, or session management function 116.

[0043] In one implementation, session management function 116 may transmit auxiliary information (AI) 140 to base station 108. Auxiliary information 140 may include one or more PSI attributes associated with the QoS flow or DRB of uplink traffic of UE 104.

[0044] Figure 2 illustrates various aspects of UE 104 in more detail according to some implementation schemes. UE 104 may include application layer 204, which generates application services to be transmitted to another device via network environment 100. In some implementation schemes, application layer 204 may have XR applications that generate XR services. However, the implementation schemes are not limited to XR use cases.

[0045] For XR and other services, application layer 204 can generate PDU sets, where each PDU set includes one or more packets. Packets (also referred to as PDUs) can be Internet Protocol (IP) packets or non-IP packets. As shown in the diagram, PDU set #1 may include packets #1 through #5, while PDU set #2 includes packets #6 and #7. Each PDU set can be mapped to a different QoS flow. When different PDU sets correspond to different service flows or modalities, they can be mapped to different service flows.

[0046] A PDU set can be packetized to carry a payload of a single information element generated by the application layer. For example, the information element could be a frame or video slice used for XR services, such as those defined in 3GPP Technical Report (TR) 26.926 v18.0.0 (2023-09). In some implementations, the application layer at the destination node may require all PDUs in the PDU set to allow it to recover some or all of the information elements from the information element. In other implementations, the application layer at the destination node can still recover some or all of the information elements even if some PDUs in the PDU set are missing.

[0047] In some implementations, the data generated by the application layer of UE 104 may include multimodal data. Multimodal data may include input data from different kinds of devices / sensors or output data to different kinds of destinations (e.g., one or more UEs) desired for the same task or application. Multimodal data may include more than one monomodal data (e.g., one type of data), and there may be strong dependencies between each monomodal data associated with the multimodal data.

[0048] In some implementations, data generated by the application layer can be in data bursts. A data burst may include, for example, data generated by the application layer within a short period of time. A data burst may include PDUs from one or more PDU sets.

[0049] These PDU sets can be provided to transmitter 208 of UE 104. Transmitter 208 can be configured to execute a communication protocol stack (e.g., communication protocol stack 836 of Figure 8) to facilitate communication via network environment 100. Transmitter 208 can implement Layer 2 (L2) and Layer 1 (L1) functions. At the L2 level, transmitter 208 may include the Serving Data Adaptation Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer. At the L1 level, transmitter 208 may include the Physical (PHY) layer. In short, the SDAP layer manages QoS flow handling between QoS flows and DRBs. The PDCP layer manages robust header (de)compression and security between DRBs and RLC channels. The RLC layer manages (re)segmentation and error correction via Automatic Repeat Request (ARQ) between logical channels and RLC channels. The MAC layer manages the scheduling / priority handling, (de)multiplexing, and Hybrid Automatic Repeat Request (HARQ) processes between logical and transport channels. The PHY layer manages the processing of physical data and control channels.

[0050] In some implementations, core network node 106 may provide RAN 110 with various information to assist in the handling of QoS flows and PDUs. This information may be consistent with that described in 3GPP TR 23.700-60 v18.0.0 (2022-12-21). This information may include semi-static information for both uplink and downlink, QoS parameters for PDU sets, and dynamic information for downlink.

[0051] Semi-static information for both uplink and downlink can be provided via the control plane (NGAP). This information may include the periodicity of uplink and downlink traffic for QoS flows via Time-Sensitive Communication Auxiliary Information (TSCAI) / Time-Sensitive Communication Auxiliary Container (TSCAC), and traffic jitter information (e.g., jitter range) associated with each periodicity of the QoS flow.

[0052] PDU set QoS parameters may include the PDU set error rate (PSER), which defines the upper limit on the rate at which a link-layer protocol's transmitter has processed the PDU set but the corresponding receiver has failed to successfully deliver it to the upper layer. See, for example, 3GPP TR23.700-60. In some instances, a PDU set is considered successfully delivered when all PDUs in the set are successfully delivered. In other instances, different definitions of successful delivery may be made. In some instances, if one PDU in a PDU set is discarded, all remaining PDUs in that set are discarded.

[0053] The PDU set QoS parameter may also include the PDU set delay budget (PSDB), which defines the time between the reception of the first PDU in the PDU set and the successful delivery of the last arriving PDU. See, for example, 3GPPTR 23.700-60. In various implementations, the PSDB may be an optional parameter.

[0054] The PDU set QoS parameter may also include PDU set importance (PSI), which indicates the relative importance of the PDU set compared to other PDU sets within the same QoS flow.

[0055] A PDU set can be associated with the following information: PDU set sequence number (SN); PDU set size (in bytes); PDU SNs within the PDU set; the end PDU indication within the PDU set; PDU set importance (PSI); and the data burst end indication in the header of the last PDU in the data burst. The PSI can be used to identify the importance of a PDU set within a QoS flow. As described herein, RAN 110 can use PSI for PSI-based scrapping in the presence of congestion.

[0056] Applications, application servers 102, or application functions 112 can assign PSI levels to each packet or PDU set, or can define rules and policies for assigning PSI levels to a type of packet or PDU set. For example, an application can assign PSI levels to packets associated with audio data and assign different PSIs to packets or PDU sets associated with real-time video data. Within a video stream, an application can assign different PSIs to payloads associated with different video frame types. PSI level selection may be influenced by factors such as application type (e.g., video, audio, text), codec details (e.g., H.264 or High Efficiency Video Decoding (HEVC)), error propagation levels when a PDU set is discarded, or interdependencies between PDU sets (e.g., whether a PDU set is necessary to process some other PDU sets). PSI selection may be similar to the PSI selection described in 3GPP TS 26.522 v 0.1.1 (2023-09-23).

[0057] The PSI can have N levels, for example, levels 0 to N-1. Higher PSI level values ​​can be associated with lower importance. Some PSI levels can indicate no interdependence with other PDU sets. For example, there can be 16 PSI levels, such as levels 0 to 15. PSI levels 14 and 15 can indicate no interdependence with other PDU sets; for example, a PDU set with PSI level 14 may not be interdependent with other PDU sets. Other PDU sets with different PSI levels (e.g., levels 0 to 13) may be needed to handle other PDU sets. In other implementations, these values ​​can be different. The PSI-based drop mechanism can be configured in a way that balances congestion handling with user experience. Base station 108 may be able to achieve this balance by having knowledge of the PSI related to the UE's application.

[0058] PSI levels can be classified into one or more groups, such as one, two, or four groups. The UE can treat each PSI level group differently when the PSI-based drop mechanism is activated. For example, the UE can apply a specific drop timer value (or a separate drop timer) when processing packets with PSI levels associated with each group, or the UE can directly drop packets with PSI levels associated with one or more specific groups. For example, the 16 PSI levels in the example above can be classified into two groups, such as PSI levels 0-8 in one group and PSI levels 9-15 in another. Grouping can be done based on the specific UE implementation (e.g., the UE application server can interact with the UE application or the UE application layer to determine the groups). The network (e.g., RAN 110 or core network node 106) can configure PSI level groups. For example, RAN 110 can signal one or more PSI level thresholds to the UE to group the PSI levels accordingly.

[0059] Different applications (e.g., video, audio, text, metadata, or images) can have different PDU set labeling methods. Therefore, two different applications running on a UE can be assigned PSI levels in different ways. Consequently, service flows associated with different applications can have different distributions of PSI levels. Knowledge of the PSI distribution associated with a flow allows base station 108 to configure PSI-based dropping based on the PSI level associated with that flow.

[0060] In some implementations, the transmitting device may employ PDU set discarding. This PDU set discarding may be similar to the discarding described in 3GPPTR 38.835 v18.0.1 (2023-04-05). For example, in some instances, a threshold number of PDUs in the PDU set may be desired for use by the receiving application layer as information elements. If the transmitting device determines, for example, that the number of lost PDUs in the PDU set exceeds the threshold number, the transmitting device may discard the remaining PDUs in the PDU set without transmitting, thereby freeing up radio resources. In some implementations, a PDU may be determined to be lost if it is not successfully transmitted (e.g., within the required time budget) or is discarded before transmission. A PDU may be discarded as described herein or for other reasons, such as if the PDU depends on another lost PDU.

[0061] In some instances, the network can configure UE behavior for uplink PDU set dropping based on PSI. Specifically, a set of PDUs with a specific PSI level associated with a QoS flow or DRB can be dropped. This can reduce congestion in the network.

[0062] When the network is congested, PSI-based packet dropping can be more advantageous. When the network is not congested, PDU set dropping may not be very useful because radio resource optimization may be relatively less important, and excessive PDU set dropping can have some adverse effects on user experience.

[0063] In some instances, PSI-based packet dropping can be specifically associated with network congestion conditions. RAN 110 (e.g., base station 108) can activate PSI-based packet dropping at the UE via dedicated signaling. The activation command can be a Media Access Control (MAC) control element (CE), a PDCP control PDU, or RRC configuration signaling.

[0064] Figure 3 illustrates a signaling diagram 300 according to some implementation schemes. Signaling diagram 300 may be an example of providing PSI attributes to base station 108.

[0065] Signaling diagram 300 may include operations and signals between core network node 106 and base station 108, and between base station 108 and UE 104.

[0066] Signaling diagram 300 may include, at 320, a core network node 106 transmitting auxiliary information to a base station 108. The auxiliary information may include one or more PSI attributes associated with at least one QoS flow. An SMF (e.g., SMF 116) may transmit the information to the base station 108. The auxiliary information may be provided as attributes of QoS parameters for a set of PDUs. One or more PSI attributes may be added along with other auxiliary information transmitted from the core network node 106 to the base station 108. For example, PSI attributes may be added to a TSCAI or TSCAC message. The core network node 106 may use dedicated messages or procedures to transmit one or more PSI attributes to the base station. The SMF may receive the corresponding PSI attributes from application function 112 or from application server 102.

[0067] An application server (e.g., application server 102) may provide one or more PSI attributes to base station 108. Application server 102 may use application function 112 to configure base station 108, for example, via the N2 interface or via core network node 106 or SMF 116.

[0068] Signaling diagram 300 may include, at 330, base station 108 determining which DRB can (or should) be configured with a PSI-based drop mechanism. For example, based on congestion conditions or auxiliary information from core network node 106, base station 108 may determine which DRB or QoS flow can be applied to UE 104 with a PSI-based drop mechanism.

[0069] Signaling diagram 300 may include, at 340, a message transmitted by base station 108 to UE 104. This message may configure or activate a PSI-based drop mechanism. The message may identify one or more flows (flows may be DRBs, QoS flows, or PDU sessions) and activate a PSI-based drop mechanism for the identified flows. The UE may apply the PSI-based drop mechanism to the identified flows.

[0070] This message can configure a timer for each PSI level or group of PSI levels associated with each identified flow, one timer for each PSI level or group of PSI levels, one timer for each flow, or one timer for all identified flows. Base station 108 can configure or activate the PSI-based drop mechanism in multiple messages. UE 104, base station 108, or core network node 106 can trigger updates to the configuration or activation of the PSI-based drop mechanism associated with the flow. For example, a UE application, an application server at the UE, application server 102, SMF 112, or a function or entity associated with core network node 106 can trigger the update process.

[0071] Figure 4 illustrates a signaling diagram 400 according to some implementation schemes. Signaling diagram 400 may be an example of providing PSI attributes to base station 108. Signaling diagram 400 may include operations and signals between UEs 104.

[0072] Signaling diagram 400 may include, at 420, UE 104 transmitting auxiliary information to base station 108. The auxiliary information may include one or more PSI attributes associated with at least one QoS flow or DRB. For example, the UE may transmit auxiliary information with UE Auxiliary Information (UAI). An application server running in UE 104 may obtain PSI attributes based on its interaction with the UE's application layer. The UE application server may also obtain PSI attributes based on its interaction with application server 102 (e.g., message exchange).

[0073] Signaling diagram 400 may include at 430, where base station 108 determines which DRB can (or should) be configured with a PSI-based drop mechanism. For example, based on congestion conditions or auxiliary information from UE 104, base station 108 may determine which DRB or QoS flow UE 104 can apply a PSI-based drop mechanism to.

[0074] Signaling diagram 400 may include, at 440, a message transmitted by base station 108 to UE 104. This message may configure or activate a PSI-based drop mechanism. The message may identify one or more flows (flows may be DRBs, QoS flows, or PDU sessions) and activate a PSI-based drop mechanism for the identified flows. The UE may apply the PSI-based drop mechanism to the identified flows.

[0075] This message can configure a timer for each PSI level or group of PSI levels associated with each identified flow, one timer for each PSI level or group of PSI levels, one timer for each flow, or one timer for all identified flows. Base station 108 can configure or activate the PSI-based drop mechanism in multiple messages. UE 104, base station 108, or core network node 106 can trigger updates to the configuration or activation of the PSI-based drop mechanism associated with the flow. For example, a UE application, an application server at the UE, application server 102, SMF 112, or a function or entity associated with core network node 106 can trigger the update process.

[0076] Figure 5 illustrates various aspects of auxiliary information 500 according to some implementation schemes. Core network node 106, application server 102, or UE 104 may transmit a message to base station 108 to assist in the configuration of a PSI-based discarding mechanism. This message may include auxiliary information 500, which may contain one or more of PSI attributes 510-580.

[0077] In one implementation, auxiliary information 500 may include a PSI attribute, wherein the PSI attribute is a PSI-based drop permission indicator 510. The PSI-based drop permission indicator 510 may include one or more flow indicators. Each flow indicator may be associated with a flow (e.g., a PDU session, DRB, or QoS flow). Each flow indicator may indicate whether a PSI-based drop mechanism is allowed to be configured or activated for the corresponding flow. For example, the UE may determine that packets associated with an application may not be dropped, discarded, or processed with a different drop timer value, for example, due to QoS or quality of experience purposes or the specific nature of the application. The UE may notify the base station by setting the flow indicator associated with that flow in the PSI-based drop permission indicator 510 to indicate that a PSI-based drop mechanism is not allowed for that flow.

[0078] In some instances, the stream indicator can be an information bit associated with a stream. A value of '0' indicates that PSI-based dropping is not allowed for the corresponding stream. A value of '1' indicates that PSI-based dropping is allowed for the corresponding stream. In other implementations, these values ​​can be different.

[0079] In one implementation, the auxiliary information 500 may include preference information for the core network node 106, application server 102, or UE 104. The preference information may indicate whether, when needed (e.g., in the event of congestion), one or more flows, such as PDU sessions, DRBs, or QoS flows, are preferably configured for PSI-based dropping. The preference information may also indicate whether, when needed (e.g., in the event of congestion), PSI-based dropping is preferably activated for the indicated one or more flows.

[0080] The UE can notify the base station by setting a flow indicator associated with the flow in the PSI-based drop preference indicator 590 to indicate whether PSI-based drop is preferred or not preferred for that flow. In some instances, the flow indicator may be an information bit associated with the flow. A value '0' indicates that PSI-based drop is not preferred for the corresponding flow. A value '1' indicates that PSI-based drop is preferred for the corresponding flow. In other embodiments, these values ​​may be different.

[0081] In one implementation, the auxiliary information 500 may include a PSI attribute, wherein the PSI attribute is a dropable PSI availability indicator 520. The dropable PSI availability indicator 520 may indicate whether the UE has any packets associated with a dropable PSI level.

[0082] For example, a UE can be configured to discard a packet or apply a different drop timer value to a packet when the packet has a pre-configured PSI level and the packet is associated with a flow configured with a PSI-based drop mechanism. The UE can be configured with one or more pre-configured PSI levels that are considered dropable. The dropable PSI availability indicator 520 may have one or more fields, each associated with a flow (e.g., a PDU session, DRB, or QoS flow). Each field may have one or more PSI indicators, each associated with a pre-configured PSI level that indicates whether the flow includes packets or a set of PDUs with the corresponding pre-configured PSI level.

[0083] Each field in the dropable PSI availability indicator 520 may include additional information associated with the corresponding pre-configured PSI level. For example, the field may indicate the likelihood (e.g., probability) associated with the corresponding pre-configured PSI level. The field may indicate the frequency at which the corresponding pre-configured PSI level may occur. The field may indicate the portion of the PDU set expected to have the corresponding pre-configured PSI level on the associated flow.

[0084] In some instances, the UE can be configured to discard sets of PDUs with pre-configured PSI levels or apply different discard timer values ​​to these PDU sets upon detecting congestion or upon receiving an activation command for a PSI-based discard mechanism from a base station. The discardable PSI availability indicator 520 indicates whether any PDU sets with such a specific PSI level exist in the corresponding flow. In some instances, the pre-configured PSI level can be PSI level 14 or 15, as PDU sets with these PSI levels may not be necessary for processing any other PDU sets.

[0085] In one implementation, auxiliary information 500 may include a PSI attribute, where the PSI attribute is a maximum (or minimum) PSI 530. The maximum (or minimum) PSI 530 may indicate a range of PSI levels expected on a QoS flow. For example, the maximum (or minimum) PSI 530 may have one or more fields. Each field may be associated with a flow (e.g., a PDU session, DRB, or QoS flow). Each field may indicate a maximum / largest, minimum / smallest, or range of PSI levels associated with the flow (e.g., both minimum and maximum PSI levels). For example, the field may indicate a maximum PSI level that is the maximum PSI level of the packets or PDU set associated with the flow. The base station may use the maximum (or minimum) PSI 530 to determine a PSI threshold for the flow and configure the UE to drop sets of PDUs or packets with PSI levels greater than (or equal to) the associated PSI threshold of the flow, or to apply different drop timer values ​​to these sets of PDUs or packets.

[0086] In one implementation, auxiliary information 500 may include a PSI attribute, where the PSI attribute is a list 540 of available PSIs. This attribute may indicate a PSI level that can be expected on a flow. The base station may use this attribute to determine a PSI threshold for the flow and configure the UE to drop sets or packets of PDUs with PSI levels greater than (or equal to) the associated PSI threshold, or to apply different drop timer values ​​to these sets or packets.

[0087] For example, the list 540 of available PSIs may include one or more fields, each associated with a flow (e.g., a PDU session, DRB, or QoS flow). Each field may indicate the PSI level expected on that flow. For example, the field may have 16 bits, one bit for each PSI level; for instance, bit 1 may be associated with PSI level 0, and bit 16 may be associated with PSI level 15. A bit value of '0' may indicate that the corresponding PSI level is not expected on that flow, and a bit value of '1' may indicate that the corresponding PSI level is expected on that flow. In other embodiments, these values ​​may be different.

[0088] In one implementation, the auxiliary information 500 may include a PSI attribute, wherein the PSI attribute is a minimum dropable PSI 550. The minimum dropable PSI 550 may indicate the minimum PSI level that can be dropped or processed with a different drop timer value. The UE or network may determine the minimum PSI level that can be dropped or processed with a different drop timer value based on application layer purposes such as QoS, quality of experience, or tolerable performance degradation.

[0089] For example, the minimum dropable PSI 550 may include one or more fields, each associated with a flow (e.g., a PDU session, DRB, or QoS flow). Each field may indicate the minimum PSI level that can be dropped. The base station can use this attribute to determine the PSI threshold for a flow and configure the UE to drop sets or packets of PDUs with PSI levels greater than (or equal to) the associated PSI threshold, or to apply different drop timers to these sets or packets of PDUs.

[0090] In one implementation, auxiliary information 500 may include a PSI attribute, wherein the PSI attribute is a PSI distribution indicator 560. The PSI distribution indicator 560 may include distribution information associated with the PSI. The PSI distribution indicator 560 may indicate the number of PDUs, the number of PDU sets, or a portion (e.g., in bytes) of data size associated with different PSI levels on the stream.

[0091] For example, the PSI distribution indicator 560 may include one or more fields, each associated with a flow (e.g., a PDU session, DRB, or QoS flow). Each field may indicate the number of PDUs, the number of PDU sets, or a portion of the data size (e.g., in bytes) associated with a different PSI level on the corresponding flow (e.g., expressed as a percentage).

[0092] In one implementation, the auxiliary information 500 may include a PSI attribute, wherein the PSI attribute is a Real-Time Transport Protocol (RTP) header extension usage indicator 570. The RTP header extension usage indicator 570 can indicate whether the application implements RTP header extensions.

[0093] In some instances, applications may transmit the PSI in the RTP header extension. The UE may rely on the RTP header extension to identify the uplink PSI. However, it is assumed that the application does not use, adopt, or implement the RTP header extension. In this case, the UE may not be able to identify the PSI level of packets associated with the application. The Real-Time Transport Protocol (RTP) header extension uses indicator 570 to notify the base station about traffic flows in which the UE can identify the PSI.

[0094] For example, the Real-Time Transport Protocol (RTP) header extension indicator 570 may include one or more fields, each associated with a stream (e.g., a PDU session, DRB, or QoS stream). Each field may indicate whether the application implements RTP header extensions on that stream.

[0095] In one implementation, the auxiliary information 500 may include a PSI attribute, wherein the PSI attribute is a PSI identifiability indicator 580. The PSI identifiability indicator 580 indicates on which flow the UE can identify the uplink PSI.

[0096] For example, the PSI identifiability indicator 580 may include one or more fields, each associated with a flow (e.g., a PDU session, DRB, or QoS flow). Each field may indicate whether the UE is able to identify an uplink PSI on that flow. In another example, the PSI identifiability indicator 580 may be a single bit that, when set to '0', indicates that the UE cannot identify any uplink PSI on any flow.

[0097] In real-time applications, PSI attributes can be based on the PSI level associated with buffered traffic. The PSI level can be estimated based on time series data from past PSI levels.

[0098] Figure 6 illustrates the operation flow / algorithm structure 600 according to some implementation schemes. The operation flow / algorithm structure 600 is an example of the operation of base station 108. The operation flow / algorithm structure 600 may be implemented by a network node (e.g., network node 900) or a component therein (e.g., processor 904).

[0099] The operation flow / algorithm structure 600 may include receiving auxiliary information, including PSI attributes, at 610. The PSI attributes may be associated with a flow. This flow may be a service flow, a PDU session, a QoS flow, or a DRB.

[0100] PSI attributes can be PSI-based drop permission indicators, PSI-based drop preference indicators, dropable PSI availability indicators, maximum expected PSI indicators, minimum expected PSI indicators, expected PSI range indicators, lists of available PSIs, minimum dropable PSI indicators, PSI distribution indicators, Real-time Transport Protocol (RTP) header extension usage indicators, or PSI identifiability indicators associated with a flow.

[0101] Figure 7 illustrates an operation flow / algorithm structure 700 according to some implementation schemes. The operation flow / algorithm structure 700 is an example of the UE providing PSI attribute information to the base station. The operation flow / algorithm structure 700 can be implemented by the UE (e.g., UE 104 or UE 800) or a component therein (e.g., processing circuitry 804).

[0102] The operation flow / algorithm structure 700 may include transmitting auxiliary information including PSI attributes at 710. The UE may transmit a message including PSI attributes to the base station. The PSI attributes may be associated with a flow. This flow may be a service flow, a PDU session, a QoS flow, or a DRB.

[0103] PSI attributes can be PSI-based drop permission indicators, PSI-based drop preference indicators, dropable PSI availability indicators, maximum expected PSI indicators, minimum expected PSI indicators, expected PSI range indicators, lists of available PSIs, minimum dropable PSI indicators, PSI distribution indicators, Real-time Transport Protocol (RTP) header extension usage indicators, or PSI identifiability indicators associated with a flow.

[0104] The operation flow / algorithm structure 700 may include receiving configuration for the PSI-based discarding mechanism at 720. The UE may receive from the base station a message including configuration or activation associated with the PSI-based discarding.

[0105] The UE can detect triggers used to update PSI attributes. The UE can then transmit a message with the updated PSI attributes to the base station.

[0106] Figure 8 illustrates a UE 800 according to some implementation schemes. UE 800 may be similar to UE 104 of Figure 1 and is substantially interchangeable with that UE.

[0107] UE 800 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, computer, tablet, XR device, glasses, industrial wireless sensors (e.g., microphone, carbon dioxide sensor, pressure sensor, humidity sensor, thermometer, motion sensor, accelerometer, laser scanner, fluid level sensor, inventory sensor, voltmeter / ammeter, or actuator), video surveillance / monitoring device (e.g., camera or camcorder), wearable device (e.g., smartwatch), or Internet of Things device.

[0108] UE 800 may include a processor 804, RF interface circuitry 808, memory / storage device 812, user interface 816, sensor 820, drive circuitry 822, power management integrated circuit (PMIC) 824, antenna structure 826, and battery 828. Components of UE 800 may be implemented as integrated circuits (ICs), portions of such integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. The block diagram in Figure 8 is intended to show a high-level view of some of the components of UE 800. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the shown components may occur in other specific implementations.

[0109] The components of UE 800 can be coupled to various other components via one or more interconnects 832, which can represent any type of interface circuitry (e.g., processor interface or memory interface), input / output, bus (local, system, or extension), transmit line, trace, or optical connector, allowing various circuit components (on common or different chips or chipsets) to interact with each other.

[0110] Processor 804 may include processor circuitry, such as, for example, baseband processor circuitry (BB) 804A, central processing unit circuitry (CPU) 804B, and graphics processing unit circuitry (GPU) 804C. Processor 804 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional processes from memory / storage device 812) to cause UE 800 to perform the operations described herein.

[0111] In some implementations, the baseband processor circuit 804A can access the communication protocol stack 836 in the memory / storage device 812 to communicate over a 3GPP-compliant network. Generally, the baseband processor circuit 804A can access the communication protocol stack 836 to: perform user plane functions at the PHY layer, MAC layer, RLC sublayer, PDCP sublayer, SDAP sublayer, and upper layers; and perform control plane functions at the PHY layer, MAC layer, RLC sublayer, PDCP sublayer, RRC layer, and NAS layer. In some implementations, PHY layer operations may additionally / optionally be performed by components of the RF interface circuit 808.

[0112] The baseband processor circuit 804A can generate or process baseband signals or waveforms carrying information in a 3GPP-compliant network. In some implementations, the waveforms used for NR can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and Discrete Fourier Transform Extended OFDM (DFT-S-OFDM) in the uplink.

[0113] Memory / storage device 812 may include one or more non-transitory computer-readable media including instructions (e.g., communication protocol stack 836) that can be executed by one or more processors in processor 804 to cause UE 800 to perform the various operations described herein. Memory / storage device 812 includes any type of volatile or non-volatile memory that can be distributed throughout UE 800. In some embodiments, some memory / storage devices in memory / storage device 812 may be located on processor 804 itself (e.g., L1 cache and L2 cache), while other memory / storage devices 812 are external to processor 804 but accessible via a memory interface. Memory / storage device 812 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0114] RF interface circuitry 808 may include transceiver circuitry and a radio frequency front-end module (RFEM) that allows UE 800 to communicate with other devices via a radio access network. RF interface circuitry 808 may include various components arranged in the transmit or receive path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, and control circuitry.

[0115] In the receiving path, the RFEM can receive the radiated signal from the air interface via antenna structure 826, and continue to filter and amplify the signal (using a low-noise amplifier). This signal can be provided to the receiver of the transceiver, which down-converts the RF signal into a baseband signal, which is then provided to the baseband processor of processor 804.

[0116] In the transmission path, the transceiver's transmitter up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM amplifies the RF signal using a power amplifier before it is radiated across the air interface via antenna 826.

[0117] In various implementations, the RF interface circuit 808 can be configured to transmit / receive signals in a manner compatible with NR access technology.

[0118] Antenna 826 may include antenna elements to convert electrical signals into radio waves for propagation through the air and to convert received radio waves back into electrical signals. These antenna elements may be arranged in one or more antenna panels. Antenna 826 may have omnidirectional, directional, or combinations thereof antenna panels to enable beamforming and multiple-input multiple-output communication. Antenna 826 may include a microstrip antenna, a printed antenna fabricated on the surface of one or more printed circuit boards, a patch antenna, or a phased array antenna. Antenna 826 may have one or more panels designed for a specific frequency band, including bands in FR1 or FR2.

[0119] User interface circuitry 816 includes various input / output (I / O) devices designed to enable users to interact with UE 800. User interface 816 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual components for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a head-mounted device, etc. Output device circuitry includes any physical or virtual components for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). Output device circuitry may include any number or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary status indicators, such as light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs, such as display devices or touchscreens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, and projectors), wherein the output of characters, graphics, multimedia objects, etc., is generated or produced through the operation of UE 800.

[0120] Sensor 820 may include devices, modules, or subsystems designed to detect events or changes in their environment and transmit information about the detected events (sensor data) to other devices, modules, or subsystems. Examples of such sensors include: inertial measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEM) including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture sensors); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors); depth sensors; ambient light sensors; ultrasonic transceivers; and microphones or other similar audio capture devices.

[0121] The driving circuitry 822 may include software and hardware elements that operate to control specific devices embedded in, attached to, or otherwise communicatively coupled to the UE 800. The driving circuitry 822 may include individual drivers that allow other components to interact with or control various I / O devices that may exist within or be connected to the UE 800. For example, the driving circuitry 822 may include circuitry for facilitating the coupling of a Universal Integrated Circuit Card (UICC) or a Universal Subscriber Identity Module (USIM) to the UE 800. Furthermore, the driving circuitry 822 may include: a display driver for controlling and allowing access to a display device; a touchscreen driver for controlling and allowing access to a touchscreen interface; a sensor driver for obtaining sensor readings from sensor circuitry 820 and controlling and allowing access to sensor circuitry 820; a driver for obtaining actuator positioning of electromechanical components or controlling and allowing access to electromechanical components; a camera driver for controlling and allowing access to an embedded image capture device; and an audio driver for controlling and allowing access to one or more audio devices.

[0122] The PMIC 824 manages the power supplied to various components of the UE 800. Specifically, relative to the processor 804, the PMIC 824 controls power selection, voltage scaling, battery charging, or DC-DC conversion.

[0123] In some implementations, the PMIC 824 may be controlled or otherwise incorporated into various power-saving mechanisms of the UE 800, including DRX, as discussed herein.

[0124] Battery 828 can power UE 800, but in some examples, UE 800 may be installed and deployed in a fixed location and may have a power source coupled to the power grid. Battery 828 can be a lithium-ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, battery 828 can be a typical lead-acid automotive battery.

[0125] Figure 9 illustrates a network node 900 according to some implementation schemes. The network node 900 may be similar to or interchangeable with a base station 108, a device implementing a network hop, an integrated access and backhaul (IAB) node, a network control repeater, or a server in a core network or external data network.

[0126] Network node 900 may include processor 904, RF interface circuitry 908 (if implemented as an access node), core node (CN) interface circuitry 912, memory / storage device circuitry 916, and antenna structure 926.

[0127] The components of network node 900 can be coupled to various other components via one or more interconnectors 932.

[0128] The processor 904, RF interface circuit 908, memory / storage device circuit 916 (including communication protocol stack 910), antenna structure 926, and interconnect 932 may be similar to the similarly named elements shown and described with respect to FIG8.

[0129] The CN interface circuit 912 can provide connectivity to a core network (e.g., a 5GC using a 5G core network (5GC) compatible network interface protocol, such as Carrier Ethernet or some other suitable protocol). Network connectivity can be provided to / from network node 900 via fiber optic or wireless backhaul. The CN interface circuit 912 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 912 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0130] In some implementations, network node 900 may be coupled to transmit-receive point (TRP) using antenna structure 926, CN interface circuitry, or other interface circuitry.

[0131] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and disposed of to minimize the risk of unintentional or unauthorized access or use, and users should be clearly informed of the nature of authorized use.

[0132] For one or more aspects, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the Embodiments section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the embodiments described below. Similarly, circuitry associated with the UE, base station, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the embodiments described below in the Embodiments section.

[0133] Example Further exemplary aspects are provided in the following sections.

[0134] Example 1 includes a method implemented by a base station (BS), the method comprising: receiving from a network node auxiliary information including a protocol data unit (PDU) set importance (PSI) attribute associated with a flow; and transmitting to a user equipment (UE) a configuration associated with a PSI-based dropping mechanism.

[0135] Example 2 includes the method according to Example 1 or other embodiments herein, wherein the PSI attribute includes a PSI-based drop permission indicator, and the method further includes: determining whether PSI-based drop is permitted for the flow based on the PSI-based drop permission indicator.

[0136] Example 3 includes the method described in Example 1 or 2 or other embodiments herein, wherein the PSI attribute includes a discardable PSI availability indicator, and the method further includes: determining, based on the discardable PSI availability indicator, whether the flow is expected to include PDUs associated with a predetermined PSI.

[0137] Example 4 includes the method according to any one of Examples 1 to 3 or other embodiments herein, wherein the PSI attribute includes a PSI-based drop preference indicator, and the method further includes: determining, based on the PSI-based drop preference indicator, whether PSI-based drop is preferred for the stream.

[0138] Example 5 includes the method according to any one of Examples 1 to 4 or other embodiments herein, wherein the PSI attribute includes a minimum expected PSI indicator, and the method further includes: determining a minimum expected PSI level associated with the PDU of the stream based on the minimum expected PSI indicator.

[0139] Example 6 includes the method according to any one of Examples 1 to 5 or other embodiments herein, wherein the PSI attribute includes an expected PSI range indicator, and the method further includes: determining an expected PSI range associated with one or more PDUs of the flow based on the expected PSI range indicator.

[0140] Example 7 includes the method according to any one of Examples 1 to 6 or other embodiments herein, wherein the PSI attribute includes a list of available PSIs, and the method further includes: determining one or more expected PSI levels associated with one or more PDUs of the stream based on the list of available PSIs.

[0141] Example 8 includes the method according to any one of Examples 1 to 7 or other embodiments herein, wherein the PSI attribute includes a minimum discardable PSI indicator, and the method further includes: determining a first PSI level based on the minimum discardable PSI indicator; and determining that a PDU associated with the flow having a second PSI level greater than or equal to the first PSI level can be discarded by the PSI-based discarding mechanism.

[0142] Example 9 includes the method according to any one of Examples 1 to 8 or other embodiments herein, wherein the PSI attribute includes a PSI distribution indicator, and the method further includes: determining distribution information of the PSI level associated with the flow based on the PSI distribution indicator.

[0143] Example 10 includes the method according to any one of Examples 1 to 9 or other embodiments herein, wherein the distribution information is associated with: the number of PDUs of the stream having the PSI level; the number of PDU sets having the PSI level; or the data size associated with the stream having the PSI level.

[0144] Example 11 includes the method according to any one of Examples 1 to 10 or other embodiments herein, wherein the PSI attribute includes a Real-time Transport Protocol (RTP) header extension usage indicator, and the method further includes: determining, based on the RTP header extension usage indicator, whether an application associated with the flow implements RTP header extensions; and determining, based on the RTP header extension usage indicator, whether the UE is able to determine the PSI level of the PDU associated with the application.

[0145] Example 12 includes the method according to any one of Examples 1 to 11 or other embodiments herein, wherein the PSI attribute includes a PSI identifiability indicator associated with the flow, and the method further includes: determining, based on the PSI identifiability indicator, whether the UE is able to determine the PSI level associated with the flow.

[0146] Example 13 includes the method according to any one of Examples 1 to 2 or other embodiments herein, wherein the flow is a traffic flow, QoS flow, or data radio bearer (DRB) associated with the PSI attribute.

[0147] Example 14 includes the method according to any one of Examples 1 to 13 or other embodiments herein, wherein the network node is a core network node, an application server, or the UE.

[0148] Example 15 includes the method according to any one of Examples 1 to 14 or other embodiments herein, wherein the network node is a core network node and the attribute of the PSI is a parameter in the PDU set QoS parameters.

[0149] Example 16 includes the method according to any one of Examples 1 to 15 or other embodiments herein, wherein the network node is a core network node and the properties of the PSI are included in Time-Sensitive Communication Auxiliary Information (TSCAI) or Time-Sensitive Communication Auxiliary Container (TSCAC).

[0150] Example 17 includes the method according to any one of Examples 1 to 16 or other embodiments herein, wherein the network node is the UE and the auxiliary information is UE Auxiliary Information (UAI).

[0151] Example 18 includes the method according to any one of Examples 1 to 17 or other embodiments herein, wherein the PSI attribute includes a maximum expected PSI indicator, and the method further includes: determining a maximum expected PSI level associated with the PDU of the stream based on the maximum expected PSI indicator.

[0152] Example 19 includes a method implemented by a user equipment (UE), the method comprising: transmitting to a base station (BS) auxiliary information including a protocol data unit (PDU) set importance (PSI) attribute associated with a flow; and receiving from the BS a configuration associated with a PSI-based dropping mechanism.

[0153] Example 20 includes the method according to Example 19 or other embodiments herein, wherein the PSI attribute is: a PSI-based drop permission indicator; a PSI-based drop preference indicator; a dropable PSI availability indicator; a maximum expected PSI indicator; a minimum expected PSI indicator; an expected PSI range indicator; a list of available PSIs; a minimum dropable PSI indicator; a PSI distribution indicator; a Real-Time Transport Protocol (RTP) header extension usage indicator; or a PSI identifiability indicator associated with the stream.

[0154] Example 21 includes the method according to Example 19 or 20 or other embodiments herein, wherein the flow is a service flow, the QoS flow, or a data radio bearer (DRB).

[0155] Example 22 includes the method according to any one of Examples 19 to 21 or other embodiments herein, wherein: the PSI attribute is a PSI distribution indicator associated with distribution information at the PSI level; and the distribution information is associated with: the number of PDUs of the stream having the PSI level; the number of sets of PDUs having the PSI level; or the size of data associated with the PSI level and the stream.

[0156] Example 23 includes the method according to any one of Examples 19 to 22 or other embodiments herein, wherein the PSI attribute is a first PSI attribute, and the method further includes: detecting a trigger for updating the first PSI attribute; and transmitting a second PSI attribute to the BA based on the trigger.

[0157] Another embodiment may include an apparatus comprising one or more elements for performing the methods described or associated with any one of Embodiments 1 to 23 or any other methods or processes described herein.

[0158] Another embodiment may include a method, technique or process described or associated with any one of embodiments 1 to 23 or any part or component thereof.

[0159] Another embodiment may include an apparatus comprising: one or more processors, and one or more computer-readable media, the one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process described or associated with any one or more of embodiments 1 to 23.

[0160] Another embodiment includes signals described or associated with any one of embodiments 1 to 23, or a portion or component thereof.

[0161] Another embodiment may include a datagram, information element, packet, frame, segment, PDU, or message described or associated with any one of embodiments 1 to 23 or any part or component thereof, or otherwise described in this disclosure.

[0162] Another embodiment may include a signal encoded with data described or associated with any one of embodiments 1 to 23 or a part or component thereof, or otherwise described in this disclosure.

[0163] Another embodiment may include a signal encoded as a datagram, IE, packet, frame, segment, PDU, or message, as described or associated with any one of embodiments 1 to 23 or any part or component thereof, or otherwise described in this disclosure.

[0164] Another embodiment may include an electromagnetic signal carrying computer-readable instructions, wherein the computer-readable instructions are executed by one or more processors to cause one or more processors to perform a method, technique or process described or associated with any one or more of embodiments 1 to 23.

[0165] Another embodiment may include a computer program comprising instructions, wherein the processing element executes the program to cause the processing element to perform a method, technique, or process described or associated with any one or a portion thereof according to Embodiments 1 to 23.

[0166] Another embodiment may include signals in a wireless network as shown and described herein.

[0167] Another embodiment may include a method for communicating in a wireless network as shown and described herein.

[0168] Another embodiment may include a system for providing wireless communication as shown and described herein.

[0169] Another embodiment may include a device for providing wireless communication as shown and described herein.

[0170] Unless otherwise expressly stated, any embodiment described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the various aspects to the precise forms disclosed. In view of the teachings above, modifications and variations are possible, or may be obtained from practice in various aspects.

[0171] Although the foregoing aspects have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the foregoing disclosure is fully understood. It is intended that the following claims be construed as encompassing all such variations and modifications.

Claims

1. A method, the method comprising: Process auxiliary information received from network nodes, the auxiliary information including Protocol Data Unit Set Importance (PSI) attributes associated with the flow; And generate configurations for sending to user equipment (UE), which are associated with a PSI-based discarding mechanism.

2. The method of claim 1, wherein the PSI attribute includes a PSI-based drop permission indicator, and the method further comprises: Whether PSI-based dropping is allowed for the stream is determined based on the PSI-based drop permission indicator.

3. The method of claim 1, wherein the PSI attribute includes a PSI-based dropout preference indicator, and the method further comprises: The PSI-based drop preference indicator is used to determine whether PSI-based drop is preferred for the stream.

4. The method of claim 1, wherein the PSI attribute includes a discardable PSI availability indicator, and the method further comprises: The discardable PSI availability indicator is used to determine whether the flow is expected to include PDUs associated with a pre-determined PSI.

5. The method according to claim 1, wherein: The PSI attribute includes a maximum expected PSI indicator, and the method further includes: determining a maximum expected PSI level associated with a Protocol Data Unit (PDU) of the flow based on the maximum expected PSI indicator; the PSI attribute includes a minimum expected PSI indicator, and the method further includes: determining a minimum expected PSI level associated with a PDU of the flow based on the minimum expected PSI indicator; or the PSI attribute includes an expected PSI range indicator, and the method further includes: determining an expected PSI range associated with one or more PDUs of the flow based on the expected PSI range indicator.

6. The method of claim 1, wherein the PSI attribute includes a list of available PSIs, and the method further comprises: Based on the list of available PSIs, one or more expected PSI levels are determined to be associated with one or more Protocol Data Units (PDUs) of the stream.

7. The method of claim 1, wherein the PSI attribute includes a minimum discardable PSI indicator, and the method further comprises: The first PSI level is determined based on the minimum discardable PSI indicator; And determine that protocol data units (PDUs) associated with the stream and having a second PSI level greater than or equal to the first PSI level can be discarded through the PSI-based discarding mechanism.

8. The method of claim 1, wherein the PSI attribute includes a PSI distribution indicator, and the method further comprises: The distribution information of the PSI level associated with the flow is determined based on the PSI distribution indicator, wherein the distribution information is associated with the following: the number of Protocol Data Units (PDUs) of the flow having the PSI level; The number of PDU sets having the PSI level; or the data size associated with the stream having the PSI level.

9. The method of claim 1, wherein the PSI attribute includes a Real-time Transport Protocol (RTP) header extension usage indicator, and the method further comprises: The RTP header extension is used to determine whether the application associated with the stream has implemented the RTP header extension; And based on the RTP header extension usage indicator, determine whether the UE is able to determine the PSI level of the Protocol Data Unit (PDU) associated with the application.

10. The method of claim 1, wherein the PSI attribute includes a PSI identifiability indicator associated with the flow, and the method further comprises: The UE is determined based on the PSI identifiability indicator to determine whether it can determine the PSI level associated with the flow.

11. The method of claim 10, wherein: The flow is a Quality of Service (QoS) flow; and the network node is the UE.

12. The method of claim 1, wherein the network node is a core network node, and the attribute of the PSI is a parameter in the Protocol Data Unit (PDU) set Quality of Service (QoS) parameters.

13. The method of claim 1, wherein the network node is a core network node, and the attribute of the PSI is included in Time-Sensitive Communication Auxiliary Information (TSCAI) or Time-Sensitive Communication Auxiliary Container (TSCAC).

14. The method according to any one of claims 1 to 13, wherein the network node is the UE, and the auxiliary information is UE auxiliary information (UAI).

15. An apparatus comprising: The processing circuitry is configured to: generate auxiliary information for transmission to a base station (BS), the auxiliary information including a Protocol Data Unit Set Importance (PSI) attribute associated with a flow, wherein the flow is a service flow, a Quality of Service (QoS) flow, or a Data Radio Bearer (DRB); and process a configuration received from the BS, the configuration being associated with a PSI-based dropping mechanism.

16. The apparatus of claim 15, wherein the PSI attribute is: a PSI-based drop permission indicator; a PSI-based drop preference indicator; a dropable PSI availability indicator; a maximum expected PSI indicator; a minimum expected PSI indicator; an expected PSI range indicator; a list of available PSIs; a minimum dropable PSI indicator; a PSI distribution indicator; a Real-Time Transport Protocol (RTP) header extension usage indicator; or a PSI identifiability indicator associated with the stream.

17. The apparatus of claim 15, wherein the PSI attribute is a PSI distribution indicator associated with distribution information at the PSI level; and the distribution information at the PSI level is associated with: the number of Protocol Data Units (PDUs) of the stream having the PSI level, the number of PDU sets having the PSI level, or the size of data associated with the PSI level and the stream.

18. The apparatus of any one of claims 15 to 17, wherein the flow is a Quality of Service (QoS) flow, and the PSI attribute includes a PSI identifiability indicator to indicate whether the user equipment is capable of identifying the PSI level for the QoS flow.

19. One or more computer-readable media having instructions that, when executed, cause processing circuitry to: generate auxiliary information for transmission to a base station (BS), the auxiliary information including a Protocol Data Unit Set Importance (PSI) attribute associated with a flow, wherein the flow is a traffic flow, a Quality of Service (QoS) flow, or a Data Radio Bearer (DRB); and process configurations received from the BS associated with a PSI-based dropping mechanism.

20. The one or more computer-readable media of claim 19, wherein the stream is a Quality of Service (QoS) stream, and the PSI attribute includes a PSI identifiability indicator to indicate whether a User Equipment (UE) is able to identify the PSI level associated with the QoS stream.

Images