Data flow management

Abstract

Discussed herein is a method (700) for data flow management. The method comprises: detecting (s501) that a data flow is overloaded, wherein the data flow is an L4S enabled quality-of-service, (QoS), flow or a service data flow, (SDF), assigned to an L4S enabled QoS flow; and after detecting that the data flow is overloaded, providing (s704) an overload indication (m552, m554, m556, m559, m560 or m654) (e.g., information indicating that a QoS flow or SDF is overloaded) to a first core network function (404, 406 or 408) and / or performing a remedial action (s503, s505, s509, s511 or s513).

Description

DATA FLOW MANAGEMENTTECHNICAL FIELD

[0001] Disclosed are embodiments related to data flow management.BACKGROUND

[0002] Typical wireless networks of today, supporting 4G and earlier releases are mainly optimized for mobile broadband (MBB) and voice services. MBB traffic can be very throughput demanding, but, in general, not latency sensitive. For example, non-real-time streaming services handle long latency by using large buffers which efficiently hide the latency jitter through the network, still resulting in a good end-user experience. In later releases of 4G, and especially in 5G and beyond, other types of services have come into, or are coming into, focus. Examples of these new services are ultra-reliable low latency communication (URLLC) services (typically targeting industrial applications), gaming services, and extended reality (XR) applications, such as, for example, virtual reality (VR), mixed reality (MR), and augmented reality (AR) applications. Within 3GPP standardization, features are being developed to support these new URLLC services and use cases.

[0003] Tele-operated driving is one latency-sensitive use case, but gaming and XR are probably more common applications. To satisfy the end-user quality experience (QoE) for these applications, the end-to-end (E2E) latency must be considered, i.e., in addition to providing low latency through the radio access network (RAN), latency through the core network (CN) and all the way to the application server and / or client needs to be considered. With an edge cloud deployment of the application, the impact of latency from the CN and between the network and the application, can be reduced.

[0004] Another quality-of-service (QoS) aspect to consider for latency-sensitive services is reliability, measured as the probability of delivering the traffic within a specified time duration, i.e., fulfilling the latency requirement. The reliability is tightly coupled to the latency requirements, since without the latency requirement, the traffic can always be delivered by using sufficiently many retransmissions. Reliability is thus a very important criteria when tuning networks for latency-sensitive traffic.

[0005] Other parameters to be considered when certain QoS levels are to be ensured for a given service is the availability of resources. Ensuring that resources are available at the time when the service needs them ensures prompt data exchange and reduces the number of failures for a given bearer communication process.E2E congestion control and Active Queue Management (AQM)

[0006] End-to-end (E2E) congestion control allows for the nodes involved in a traffic path, such as, for example, routers, bridges, and gateways, to signal congestion to a traffic source. The signaling may be explicit or implicit, e.g., by dropping packets. The congestion signaling is detected by the source, which then adapts its transmission rate to the weakest link. Active Queue Management (AQM) is often used in combination with E2E rate adaptation to reduce latency jitter for long-lived transfers caused by bursty sources.Low Latency, Low Loss, Scalable throughput (L4S)

[0007] One way to manage latency, specifically queue delays, in E2E data flows is to make use of L4S(see, Internet draft RFC 9330: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture). A node receiving an L4S marked packets, i.e., Internet Protocol (IP) packets containing the L4S identifier in the Explicit Congestion Notification (ECN) field, may set ECN bits in the IP header for the flow if congestion is experienced. The receiver collects the congestion / ECN statistics and feeds this back to the source. Based on the reported congestion information, the source adapts its data rate to maintain low queue delays and short E2E latency. Thus, congestion indications are set in the forward direction, collected by the receiver (e.g., a client) and sent in a feedback protocol to the source (e.g., a server).

[0008] With L4S, packets may be marked "congested” even when queue delays are very low, which gives a prompt reaction to small signs of congestion, allowing the end hosts to implement scalable congestion control where the transmission rate (or congestion window) is changed proportional to the fraction of congestion-marked packets.

[0009] L4S enables real-time critical data applications to adapt their rate to the weakest link, providing minimal latency impact due to queue build up. The state-of-the-art L4S is typically triggered by thresholds in the transport node input queue and may be used to signal a congested situation. L4S gives good results given that most transport nodes have a fairly stable or slowly varying output rate. For radio networks, however, the output rate variations over the wireless link may be more frequent than in traditional wired solutions, which may lead to sudden latency peaks even when L4S is used.L4S in the 5G System (5GS)

[0010] In 5GS, ECN marking for L4S may be supported. ECN marking for L4S is enabled on a per QoS Flow basis in the uplink and / or downlink direction and may be used for guaranteed bit rate (GBR) and non-GBR QoS Flows. ECN marking for the L4S in the IP header is supported in either the Next Generation RAN (NG-RAN) or in the PDU session anchor (PSA) User Plane Function (UPF). Based on operator's network configuration and policies, a Session Management Function (SMF) decides whether NG-RAN or PSA UPF based ECN marking for L4S is used.

[0011] In the case of ECN marking for L4S by PSA UPF, the NG-RAN is instructed to perform congestion information monitoring and report to the PSA UPF the congestion information (i.e. a percentage of packets that UPF uses for ECN marking for L4S) of the QoS Flow on UL and / or DL directions via GTP-U header extension to PSA UPF.

[0012] As for any QoS Flow, QoS rules in the UE and PDRs in the PSA UPF control which packets are bound to the L4S enabled QoS flow. The Packet Filter Set in the QoS rule or PDR can use packet filter(s) to steer traffic to an L4S enabled QoS Flow.

[0013] A QoS Flow may be enabled with ECN marking for L4S requirement e.g. statically when a PDU session is established based on configuration in SMF or PCF, or dynamically based on detection of the L4S traffic in the IP header whereby SMF or PCF triggers a setup of a QoS Flow enabled for L4S, or by requests by an AF.

[0014] When serving PSA UPF or NG-RAN is changed e.g. due to inter-NG-RAN handover or PSA UPF relocation, target NG-RAN and target PSA UPF, if supported, should continue to perform ECN marking for L4S for the QoS Flow. However, if not available (i.e. ECN marking for L4S is not supported in both, target NG-RAN and target PSA UPF), AF should be notified when ECN marking for L4S had been enabled for the QoS Flow based on AF request.Support of ECN marking for L4S in NG-RAN

[0015] As specified by 3GPP, ECN marking for L4S may be supported in NG-RAN. To enable ECN marking for L4S in NG-RAN, dedicated QoS Flow(s) are used for carrying L4S enabled IP traffic. The SMF may be instructed, based on either dynamic or predefined PCC rule, to provide an indication for ECN marking for L4S to NG- RAN for a corresponding QoS Flow(s) in UL and / or DL directions. In the absence of such PCC rule, the use of ECN marking for L4S in NG-RAN on a QoS Flow is controlled by a coordinated configuration in NG-RAN and 5GC. The criteria based on which NG-RAN decides to mark ECN bits for L4S is NG-RAN implementation specific.Support of ECN marking for L4S in PSA UPF

[0016] To enable ECN marking for L4S by a PSA UPF, a QoS Flow level ECN marking for L4S indicator may be sent by SMF to PSA UPF over N4. SMF also indicates to NG-RAN to report the congestion information (i.e. a percentage of packets that UPF uses for ECN marking for L4S) of the QoS Flow on UL and / or DL directions via GTP- U header extension to PSA UPF. If there is no UL packet when report for DL and / or UL needs to be provided, NG- RAN may generate an UL Dummy GTP-U Packet for such a reporting. The SMF may be instructed, based on either dynamic or predefined PCC rule, to provide an indication for ECN marking for L4S to PSA UPF for a corresponding QoS Flow(s) in UL and / or DL directions. Upon successful activation of congestion information reporting for UL and / or DL directions, PSA UPF uses information sent by NG-RAN in GTP-U header extension to perform ECN bits marking for L4S for the corresponding direction.Higher layer split in the RANFigure 1

[0017] In the 5G standard, the base station (denoted "gNB”) can be divided into one Central Unit (CU) (denoted "gNB-CU” in FIG. 1) and one or more Distributed Units (DU) (denoted "gNB-DU” in FIG. 1), communicatively coupled to each by the “F1” interface as illustrated in FIG. 1. As further shown in FIG. 1, a Next Generation Radio Access Network (NG-RAN) can include multiple gNBs, and each gNB may be coupled to a 5G Core network (5GC) by the "NG” interface.

[0018] The F1 interface between the gNB-CU and a gNB-DU implies that the PDCP functionality is located in the CU, while the RLC and lower-layer functionality (e.g., MAC and PHY layers) are located in the DU.Figure 2

[0019] FIG. 2 shows the user plane protocol stack between a gNB and a user equipment (UE).Figure 3

[0020] FIG. 3 shows that, in the gNB CU-DU split architecture, the responsibility for RAN-UE protocol stack is divided between the CU and the DU, where the higher layers (Service Data Adaptation Protocol (SDAP) and Packet Data Convergence Protocol (PDCP)) are terminated in the CU and the remaining lower layers (Radio Link Control (RLC), Media Access Control (MAC), Physical (PHY)) are terminated in the DU. The UE is unaware of the internal gNB CU-DU split, which implies identical RAN-UE procedures regardless of gNB internal architecture.

[0021] The distributed termination of the RAN-UE protocol layers is enabled by the F1 interface which, for the user plane, provides methods to convey New Radio (NR) PDCP protocol data units (PDUs) between CU and DU.SUMMARY

[0022] Certain challenges presently exist. For instance, one issue with L4S is that L4S assumes that endpoints react to the L4S congestion signals in a defined manner, such as, for example, that the congestion control should follow a scalable principle where the transmission rate is scaled down proportional to the fraction of ECN-CE marked packets. There is no internet "police,” however, that controls each and every endpoint. The situation has been that common sense has ruled and most endpoints have complied to the use of a set of reasonably safe congestion control algorithms. Over the years, this has proven to work well and major internet problems generally occur for reasons other than congestion control related issues, such as, for example, distributed denial-of-service (DDos) attacks. The main reason is that congestion control algorithms that do not work well are very likely to cause issues for the user of the endpoint, such that the problem regulates itself.

[0023] The same thing is likely to happen with the emerging use of L4S. It is expected that initially there can be endpoints that implement a faulty (or "misbehaving”) congestion control algorithm, and, in a few cases, there is a possibility that a malicious endpoint may bloat the network by classifying packets as being L4S packets, e.g., set the ECT(1) codepoint in the packets, when the packets should not be L4S classified. The latter is actually nothing new, but that L4S can open a new attack vector. Network features, such as, for example, firewalls can serve to prevent these malicious attacks form causing harm.

[0024] Still, even though the problem of non-ideal scalable congestion control algorithms can be manageable, there can be cases where it is not. One such scenario is where 5G technology is used for fixed wireless access (FWA), such as where several tenants in an apartment building share a 5G wireless connection to a nearby 5G cell tower. In this scenario it is possible that a user may run an application that, by accident or on purpose, is faulty, such as, for example, non-reactive to L4S ECN marking, which can lead to the application starving out other L4S enabled traffic over the same connection.

[0025] Modest amounts of unfairness is likely inevitable as applications themselves can have different behavior, short / long lived, some applications are even application limited meaning that they have some upper limit in transmission bitrate, some are not. Furthermore, applications can experience different round-trip-times (RTTs) depending on physical distance between source and sink. These possible situations of unfairness are hard to fix without detailed knowledge about applications and their intentions.

[0026] Gross unfairness that occurs when an endpoint is non-reactive to L4S ECN marking, and, thereby, reacts very little to congestion should, however, be remedied.

[0027] Accordingly, in one aspect there is provided a method for data flow management. The method includes detecting that a data flow is overloaded, wherein the data flow is an L4S enabled quality -of-service, QoS, flow or a service data flow assigned to an L4S enabled QoS flow. The method further includes, after detecting that the data flow is overloaded, providing an overload indication to a core network function and / or performing a remedial action.

[0028] In another aspect there is provided a computer program comprising instructions which when executed by processing circuitry of an apparatus causes the apparatus to perform any of the methods disclosed herein. In one embodiment, there is provided a carrier containing the computer program wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium. In another aspect there is provided an apparatus that is configured to perform the methods disclosed herein. The apparatus may include memory and processing circuitry coupled to the memory.

[0029] An advantage of the embodiments disclosed herein is that they provide a notification when an L4S flow is overloaded so that remedial actions to solve this problem can be taken.BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.FIG. 1 illustrates a system according to an embodiment.FIG. 2 illustrates exemplifying protocol stacks.FIG. 3 illustrates that the responsibility for the RAN-UE protocol stack may be divided between a CU and a DU.FIG. 4 illustrates an exemplifying wireless communication system.FIG. 5 is a message flow diagram illustrating a process according to an embodiment.FIG. 6 is a message flow diagram illustrating a process according to an embodiment.FIG. 7 is a flowchart illustrating a process according to an embodiment.FIG. 8 is a block diagram of network node according to an embodiment.DETAILED DESCRIPTIONFigure 4

[0031] FIG. 4 illustrates an exemplifying wireless communication system 400 represented as a 5G network architecture comprising an Access Network (AN) 402 (e.g., a Radio AN (RAN)) and a Core network (CN) comprising network entities in the form of Network Functions (NFs). Typically, the AN 402 comprises base stations, e.g., such as evolved Node Bs (eNBs) or 5G base stations (gNBs) or similar.

[0032] As shown in FIG. 4, a user equipment (UE) 401 connects to AN 402 to communicate with another endpoint 490 via a UPF 404 and a data network (DN) (e.g., the internet). The UE also has a logical connection with an Access and Mobility Management Function (AMF). As further shown in FIG. 4, the 5G CN NFs further include: a Session Management Function (SMF) 406, a Policy Control Function (PCF) 408, a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), a Unified Data Management (UDM), an Access and Mobility Management Function (AMF), an Application Function (AF), a NF Repository Function (NRF), and a Network Exposure Function (NEF).

[0033] A number of 5G core network NFs of different types are typically instantiated per default in the 5G core network, e.g., such as an AMF, a NRF, a PCF and a SMF etc. Other 5G core network NFs may be instantiated as needed and several NFs of the same type can also be instantiated if required, e.g., to distribute load to additional NF(s) of the same type. Thus, an NF instance may be seen as an example or a specimen of a certain NF. Herein, theterms NF and NF instance are used interchangeably, unless otherwise expressly stated or is apparent from the context in which the terms are used. An NF instance exposes one or more NF Service Instances.

[0034] As noted above, unfairness may occur when an endpoint is non-reactive to L4S ECN marking, and, thereby, reacts very little to congestion notifications. Such a situation can lead to an "overloaded” QoS flow with L4S enabled (denoted "L4S QoS flow”), which is an L4S QoS flow that satisfies an overload condition, such as, for example, an increased queue delay, an ECN marking rate that is too high, and / or packet loss. On the other hand, an endpoint reactive to L4S should cause little added queue delay and no packet loss related to, for example, buffer overflow. Also, such a well behaved endpoint should not drive the ECN marking rate too high.

[0035] Accordingly, in one embodiment, this disclosure proposes detecting an overloaded L4S QoS flow, which is also known as a "misbehaving” L4S QoS flow, and, in response to the detection of an overloaded L4S QoS flow, provide a notification to a core network function, such as a policy function, so that a remedial action or actions can be undertaken.

[0036] In one embodiment, an overloaded L4S QoS flow (or "flow” for short) is detected if: the L4S ECN marking rate for the flow is too high value (e.g., close to 100%) over a long measurement period (e.g., a measurement period of at least about 1 second) and throughput exceeds a threshold (X), where X is K (e.g., K = 2) times the expected throughput given the packet marking rate, packet size and the estimated round-trip-time (rtt), the queue delay of the queue for the flow is higher than a threshold queue delay, and / or the queue for the flow has overflowed, thereby causing packet loss.

[0037] The notification to the policy function may be sent directly to the policy function using, for example, the control plane in NG-C, or indirectly via another core network function.

[0038] Requesting Reporting Overloaded of L4S QoS Flows

[0039] In one embodiment, a core network function (e.g., the SMF) provides the request for overload reporting to an NG-RAN CU via Control Plane (CP) signaling to request reporting back whether any L4S QoS flow is overloaded or whether a specific flow is overloaded. In one embodiment, the indication can be sent during a PDU Session setup, in an enhanced version of the ECN Marking or Congestion Information Reporting Request IE defined in 3GPP TS 38.413 V18.0.0 ("TS 38.413”), indicating the causes that NG-RAN should take into account when judging whether an L4S QoS flow is overloaded, either during the initial admission control or later. In one embodiment, the request indication for reporting L4S QoS flow overload status is signaled over the NG interface together with the causes which can be high usage of data rate, increased queue delay, and / or queue overflow. An example is to enhance the existing PDU Session Resource Setup Request Transfer message described in section 9.3.4.1 of TS 38.413 by adding a new request indicator as shown in Table 1 A below.TABLE 1A

[0040] As shown in the table, the new request indicator may be named "ECN misbehaving detection Request.”

[0041] In one embodiment, a core network function (e.g., the SMF) provides instructions to the UPF to monitor one or more L4S flows. As one example, the SMF may send to the UPF a PFCP Session Establishment Request as defined in 3GPP TS 29.244 V18.4.0 (“TS 29.244”) containing an enhanced version of an SRR IE, which is illustrated in Table 1 B1 below.TABLE 1B1 - Enhanced SRR IE

[0042] As shown in Table 1 B1 , the enhanced SRR IE includes a new IE, which is named "Service DataFlow Monitoring Control Information,” and this new IE shall be present if the SMF requests the UPF to monitor a QoS flow to identify one or more overloaded service data flows (SDFs) the QoS flows.

[0043] An example of the lEs that may be included in the Service Data Flow Monitoring ControlInformation IE are shown below in Table 1 B2.TABLE 1B2

[0044] In one embodiment, the gNB-CU signals to one or more gNB-DUs an instruction to report an overloaded L4S QoS flow, and this signaling may be performed over the F1 interface. For example, in one embodiment, the gNB-CU, in response to receiving a request from the CN function to report detection of an overloaded L4S flow, the gNB-CU notifies each DU serving the QoS flow identified in the request to report back if the DU detects that the QoS flow is overloaded. As one example, this can be done by providing to the DU an enhanced version of a UE Context request, such as a UE Context Setup Request or a UE Context Modification request defined in 3GPP TS 38.473 V18.0.0 (“TS 38.473”). An implementation example of an enhanced UE Context request is provided below in Table 1C. TABLE 1C

[0045] As illustrated in Table 1 C, the enhanced UE Context request includes a "ECN misbehaving detection Request.” In this example, this detection request is associated with a data radio bearer (DRB) and the gNB-DU will send a report if any of the QoS flows mapped to the DRB are detected as being overloaded.

[0046] Detecting Reporting an Overloaded Flow Figure 5

[0047] FIG. 5 is a message flow diagram illustrating a process reporting an L4S flow identified as being overloaded. The process may begin with step s501, in which a DU 502 of a base station 500 (e.g., a gNB-DU) determines that at least one L4S flow is overloaded.

[0048] In one embodiment, DU 502 monitors: 1) the L4S ECN marking rate (fraction of packets in QoS flow that are marked with "congestion experienced”), 2) queue delay (e.g., bytes in queue or longest time in queue), and / or 3) queue overflow, which is also called "buffer overflow.”

[0049] In response to detecting that at least one L4S flow is overloaded, such as, for example, when the L4S ECN marking rate is too high (e.g., exceeds a configured threshold), the queue delay is to long, and / or the queue has experienced overflow, DU 502 in this example sends to the UPF a message m552 with an overload indication. This overload indication may be sent using in-band signaling in the user plane in NG-U by adding new information in the GTP-U extension header. As an example, message m552 may have the format shown in Table 2 below.TABLE 2

[0050] In the example shown in Table 2, message m552 includes a QoS flow identifier for identifying a QoS flow and a "misbehaving QoS flow” indicator to indicate whether or not the QoS flow identified by the QoS flow identifier is overloaded. The message m552 shown in FIG. 2 is an enhanced version of the UL PDU SESSION INFORMATION frame defined in 3GPP TS 38.415 V18.0.0 (“TS 38.415”). Like the UL PDU SESSION INFORMATION frame defined in TS 38.415, the enhanced UL PDU SESSION INFORMATION frame is conveyed by GTP-U protocol means, more specifically, by means of the "PDU Session Container" GTP-U Extension Header.

[0051] The detection step (step s501) is likely done where the queue builds up in the RAN, which is most likely to occur in the RLC layer, but it is also possible that it occurs on the PDCP layer. In the case that the queue builds up on the RLC layer, it is not easy to identify the specific misbehaving flow(s) because of encryption of the IPheaders. To solve this another signaling mechanism can be used, such as QNC (QoS Notification Control) to indicate that a specific bearer is overloaded. Thus, message m552 may be a QNC message, and the UPF can use the bearer identifier included in the message to determine the QoS flows assigned to the bearer and then determine which one or more of these QoS flows is overloaded. For example, the UPF can determines the QoS flow associated with the bearer that has highest bitrate and can declare that this determined QoS flow it the overloaded QoS flow.

[0052] In some embodiments, in response to receiving message m552, UPF 404 transmits to SMF 406 a report message m554 with an overload indication indicating that a QoS flow is overloaded. This message may include the QoS flow identifier for the QoS flow that is overloaded.

[0053] In one embodiment, in response to receiving report message m554, SMF 406 sends to PCF 408 a report message m556 including the QoS identifier. For instance, in one embodiment, prior to SMF 406 receiving message m552, PCF 408 installed trigger in SMF 406 so that the SMF notifies the PCF whenever the SMF is notified about a overloaded L4S QoS Flow. In one embodiment, the message m556 includes a PCC rule that is bound to the overloaded L4S flow, or a PCC rule identifier that identifies said PCC rule, so that the PCF can use the PCC rules to make a decision about what action(s) to take and provisions this policy and charging control decision to the SMF by updating the PCC rule. In one embodiment, the PCC rule is enhanced with a new QoS Parameter to be able to request the PCC Rule traffic is bound to an L4S QoS Flow not shared with other SDFs.

[0054] In one embodiment, the PCF is able to request explicitly to SMF that a given PCC Rule is bound to QoS Flow that is not shared with other PCC rules, and SMF is able to consider this request during QoS Flow binding (i.e. when associating this PCC rule to a QoS Flow within a PDU Session).

[0055] In other words, the PCF may provide to SMF dynamic control over the policy and charging behavior. In a 3GPP mobile network that is done by creating an SM Policy Association (clause 4.16 of TS 23.502 [3]) in PCF and SMF which enables among other that: (1) the SMF can Request policy and charging control decision to the PCF when a Policy Control Request Trigger related to Session Management is met; and (2) PCF can Provision policy and charging control decision to the SMF (i.e. PCC Rules and other type of policies).

[0056] Accordingly, in one embodiment, in response to receiving notification message m556, PCF 408 provides instructions (e.g., a PCC rule) that instruct the SMF on which remedial actions it should take in view of the overloaded L4S flow. In another embodiment, however, rather than the PCF instructing the SMF to take an action to "fix” the overload issue, the SMF itself may take the decision and actions in step s503 (discussed below).

[0057] In one embodiment, in response to message m554 or in response to message m557, SMF 406 may take a remedial action in step s505. For example, rather than sending the report message m556 to PCF 408, in response to message m554, SMF 406 may obtain a local policy and then perform step s505 based on the local policy. That is, based on the local policy, SMF 406 determines which action(s) to take and then performs thoseactions. As another example, in response to message m557, SMF 406 obtains the policy provided by the PCF and then performs step s505 based on the policy from the PCF.

[0058] In another embodiment, in response to message m554 or in response to message m557, SMF 406 sends a request message m558 to UPF 404 instructing UPF 404 to identify an service data flow (SDF) that is assigned to and overloads the QoS flow (such an SDF is referred to as an "overloading SDF” or an "overloaded SDF”). In some embodiments, this request message m558 is or contains the enhanced version of the SRR IE described above. In some embodiments, however, message m558 is transmitted to UPF 404 before UPF receives message m552.

[0059] In response to message m558, UPF 404 identifies the SDF within the QoS flow that has caused the overload in the QoS flow as shown in step s507. The detection of the SDF causing the QoS flow overload can be implemented in various ways. One is to measure the actual bitrate for each SDF and the SDF with the highest bitrate is identified as the SDF causing the overload. Another solution is as follows: each SDF within the QoS flow is assigned a counter and the counter for an SDF is incremented each time UPF 404 receives a packet related to the SDF. A packet is related to an SDF if, for example, the packet's n-tuple, such as, for example source address, destination address, source port, destination port, and protocol identifier, matches an n-tuple for the SDF.Periodically, for each SDF, the SDF's counter is decremented if the counter is above 0. In response to receiving message m552 or message m558, UPF 404 identifies the overloaded SDF flow by determining the SDF flow having the highest counter value.

[0060] In some embodiments, in response to identifying an overloaded SDF, UPF 404 takes a remedial action (described further below) in step s509 and / or sends to SMF 406 a report message m559 comprising an overload indication, which indicates that there is an overloaded SDF, and further indicating, e.g., identifying, the overloading SDF, more specifically, for example, the filter (e.g., n-tuple) for the SDF that causes overload of the QoS Flow. An example of the information elements (lEs) that may be included in report message m559 are shown below in Table 3A.TABLE 3A

[0061] In the example shown, message m559 is an enhanced version of the Session Report defined in section 7.5.8.6 of TS 29.244. As noted in TS 29.244, the Session Report is included in a PFCP Session Report Request message. Accordingly, message m559 may be a PFCP Session Report Request message containing the enhanced version of the Session Report.

[0062] Table 3B below illustrates the information elements that may be included in the "Service Data Flow(SDF) Monitoring Report” IE included in the enhanced Session Report.TABLE 3B

[0063] In one embodiment, in response to receiving report message m559, SMF 406 sends to PCF 408 a report message m560 including the SDF information included in message m559. For instance, in one embodiment, prior to SMF 406 receiving message m559, PCF 408 installed a trigger in SMF 406 so that the SMF notifies the PCF whenever the SMF is notified about a overloading SDF. In one embodiment, the message m556 includes a PCC rule that is bound to the overloading SDF, or a PCC rule identifier that identifies said PCC rule, so that the PCF can use the PCC rules to make a decision about what action(s) to take and provisions this policy and charging control decision to the SMF by updating the PCC rule.

[0064] Accordingly, in one embodiment, in response to receiving notification message m560, PCF 408 provides instructions (e.g., a PCC rule) that instruct the SMF on which remedial actions it should take in view of the overloading SDF. In another embodiment, however, rather than instruct the SMF to take an action to "fix” the overload issue, the PCF itself may take the actions in step s511 .

[0065] In one embodiment, in response to message m559 or in response to message m562, SMF 406 may take a remedial action in step s513. For example, rather than sending the report message m560 to PCF 408, in response to message m559, SMF 406 may obtain a local policy and then perform step s513 based on the local policy. That is, based on the local policy, SMF 406 determine which action(s) to take with respect to the overloading SDF and then performs those actions. As another example, in response to message m562, SMF 406 obtains the policy provided by the PCF and then perform step s513 based on the policy from the PCF.Figure 6

[0066] FIG. 6 is a message flow diagram illustrating another process for reporting an overloaded L4S flow. This process shown in FIG. 6 is very similar to the one shown in FIG. 5. The DU 502, however, after it detects an overload condition, DU 502 provides to a CU 504 of base station 500 a message m652 comprising an overload indication, which indicates the existence of an overloaded data flow. CU 504 then provides to a SMF 506 (or another core network function) message m654 comprising an overload indication. The remainder of the process illustrated in FIG. 6 is identical to the process shown in FIG. 5.

[0067] Table 4 shows the information elements that may be included in the message m652. That is, message m652 may be an enhanced version of the UE CONTEXT SETUP RESPONSE message and / or UE CONTEXT MODIFICATION RESPONSE message and / or UE CONTEXT MODIFICATION REQUIRED message defined in TS 38.473.TABLE 4

[0068] Table 5 shows the information elements that may be included in the message m654 in one embodiment.TABLE S

[0069] In the embodiment shown in Table 5, message m654 is an enhanced version of the ECN Marking or Congestion Information Reporting Status Item defined in TS 38.413. That is, the enhanced version of the ECN Marking or Congestion Information Reporting Status Item includes a QoS flow identifier IE for containing an identifier to identify the misbehaving QoS flow and an overload status IE that indicates the reason why the identified flow is overloaded.

[0070] Table 6 shows the information elements that may be included in the message m654 in another embodiment.TABLE 6

[0071] In the embodiment shown in Table 6, message m654 is an enhanced version of the PDU Session Resource Setup Response Transfer message defined in TS 38.413. That is, the enhanced version of the PDU Session Resource Setup Response Transfer message includes a QoS flow identifier IE for containing an identifier to identify the misbehaving QoS flow and an overload status IE that indicates the reason why the identified flow is overloaded.TABLE 7

[0072] In the embodiment shown in Table 7, message m654 is an enhanced version of the PDU SessionResource Notify Transfer message defined in TS 38.413. That is, the enhanced version of the PDU SessionResource Notify Transfer message includes a QoS flow identifier IE for containing an identifier to identify the misbehaving QoS flow and an overload status IE that indicates the reason why the identified flow is overloaded.

[0073] Remedial Actions Performed by PCF, SMF, and / or UPF

[0074] As described above, the PCF, the SMF, the UPF, or any other core network function may take one or more remedials actions in response to being notified about an overloading SDF and / or overloaded L4S QoS flow. These remedial actions include:

[0075] 1) applying throttling on overloading SDF flow;

[0076] 2) moving the overloading SDF to another L4S enabled QoS flow and this another QoS flow does not have any other SDF (e.g., the SMF may send a message to the PCF and then PCF to SMF and then SMF to RAN, UE, and UPF to indicate the QoS flow to which the SDF is being reassigned -- use existing messages);

[0077] 3) demoting the overloading SDF flow to a non-L4S enabled QoS Flow (e.g., the SMF may sends a message to the CU and the UPF and the UE using standard messages);

[0078] 4) disabling L4S (e.g., SMF may send a the CU to disable L4S marking on the overloaded L4S enabled QoS flow); and / or

[0079] 5) downgrading the priority of the overloaded QoS flow (e.g., the SMF may send a QoS flow downgrade request message to the CU to modify the QoS profile to lower priority).

[0080] Other Embodiments

[0081] In one embodiment, the indication for reporting L4S enabled QoS flow misbehaving status is signaled over the Xn interface from gNB-CU to another gNB-CU, e.g., during mobility procedure and admission control at target node. In one embodiment, the target gNB indicates in the Xn signalling to the source gNB the L4S enabled QoS that has been detected to misbehave / overloaded and the reason of it during admission control. In one embodiment, the indication for reporting L4S enabled QoS flow misbehaving status is signaled over E1 interface from gNB-CU-CP to gNB-CU-UP to let gNB-CU-UP aware of the QoS flow status.Figure 7

[0082] FIG. 7 is a flow chart illustrating a process 700, according to an embodiment, for data flow management. Process 700 may begin in step s 702. Step s702 comprises detecting that a data flow is overloaded, wherein the data flow is an L4S enabled quality-of-service, QoS, flow or a service data flow assigned to an L4S enabled QoS flow. Step s704 comprises, after detecting that the data flow is overloaded, providing an overload indication to a core network function and / or performing a remedial action.Figure 8

[0083] FIG. 8 is a block diagram of network node 800, according to some embodiments, which can be used to implement any one of the network function (NF) described above (e.g., SMF, PCF, UPF). For instance, in embodiments where an NF consists of software, network node 800 may run (or execute a virtual machine that runs) the NF. As shown in FIG. 8, network node 800 may comprise: processing circuitry (PC) 802, which comprises one or more processors (P) 855 (e.g., one or more general purpose microprocessors and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (e.g., network node 800 may be a distributed computing apparatus comprising two or more computers or a monolithic computing apparatus consisting of a single computer); at least one network interface 848 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 845 and a receiver (Rx) 847 for enabling network node 800 to transmit data to and receive data from other nodes connected to network 110 (e.g., an Internet Protocol (IP) network) to which network interface 848 is connected (physically or wirelessly) (e.g., network interface 848 may be coupled to an antenna arrangement comprising one or more antennas for enabling network node 800 to wirelessly transmit / receive data); and a storage unit (a.k.a., "data storage system”) 808, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where PC 802 includes a programmable processor, a computer readable storage medium (CRSM) 842 may be provided. CRSM 842 may store a computer program (CP) 843 comprising computer readable instructions (CRI) 844. CRSM 842 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 844 of computer program 843 is configured such that when executed by PC 802, the CRI causes network node 800 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, network node 800 may be configured to perform steps described herein without the need for code. That is, for example, PC 802 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.Summary of Various Embodiments

[0084] Some of the embodiments that have been described above may be summarized in the following enumerated manner:A1 . A method (700) for data flow management, the method comprising: detecting (s501, s702) that a data flow is overloaded, wherein the data flow is an L4S enabled quality-of- service, QoS, flow or a service data flow, SDF, assigned to an L4S enabled QoS flow; andafter detecting that the data flow is overloaded, providing (s704) an overload indication (m552, m554, m556, m559, m560, m654) (e.g., information indicating that a QoS flow or SDF is overloaded) to a first core network function (404, 406, 408) and / or performing a remedial action (s503, s505, s509, s511, s513).A2. The method of embodiment A1, wherein the method comprises providing the overload indication to the first core network function, the method is performed by a base station (500), and the base station provides the overload indication (m552, m654) to the first core network function (404, 406) in response to detecting that the data flow is overloaded.A3. The method of embodiment A2, wherein the method is performed by a distributed unit, DU (502), of the base station (500).A4. The method of embodiment A3, wherein the first core network function is a user plane function, UPF (404), and providing the overload indication to the UPF (404) comprises sending in-band to the UPF a message (m552) comprising the overload indication.A5. The method of embodiment A4, wherein the method further comprises the UPF (404) determining an SDF that is overloading the data flow.A6. The method of embodiment A5, wherein the method further comprises: after determining an SDF that is overloading the data flow, the UPF performs a remediation process comprising: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.A7. The method of embodiment A5, wherein the method further comprises: after determining an SDF that is overloading the L4S enabled QoS flow, the UPF sending a report (m559) to a session management function, SMF (406).A8. The method of claim A7, wherein the method further comprises: in response to receiving the report (m559) from the UPF, the SMF performs a remediation process comprising: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.A9. The method of embodiment A2, wherein the method is performed by a control unit, CU (504), of the base station (500). the first core network function is a session management function, SMF (406), and providing the overload indication to the SMF comprises sending to the SMF a control plane message (m654) comprising the overload indication.A10. The method of embodiment A9, wherein the method further comprises the SMF (404) obtaining information identifying an SDF that is overloading the data flow, whereinA11. The method of embodiment A10, wherein the method further comprises: after determining an SDF that is overloading the data flow, the SMF performs a remediation process comprising: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.A12. The method of any one of embodiments A1 -A11 , wherein the method further comprises: determining a queue delay of a queue for the data flow; determining a congestion notification marking rate for the data flow; and / or determining whether the queue for the data flow has overflown; detecting that the data flow is overloaded comprises: determining that the queue delay exceeds a delay threshold;determining that the congestion notification marking rate for the data flow exceeds a marking threshold; and / or determining that the queue has overflown.A13. The method of embodiment A1, wherein the method is performed by a user plane function, UPF (404), and the first core network function is a session management function, SMF (406).A14. The method of embodiment A13, wherein the method further comprises: after providing the overload indication to the SMF, the UPF receiving a request (m558) from the SMF; and in response to receiving the request from the SMF, the UPF determining an SDF that is overloading the data flow.A15. The method of embodiment A14, wherein the method further comprises: after determining an SDF that is overloading the data flow, the UPF performs a remediation process comprising: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.A16. The method of embodiment A14, wherein the method further comprises: after determining an SDF that is overloading the data flow, the UPF sending a report (m559) to the SMF (406).A17. The method of embodiment A1, wherein the method is performed by a session management function, SMF (406), and in response to detecting that the data flow is overloaded, the SMF performs a remedial action (s505), or in response to detecting that the data flow is overloaded, the SMF transmits a request to a user plane function, UPF (404) requesting the UPF to report the identity of an SDF that is overloading the data flow.A18. The method of any one of embodiments A1, wherein the method comprises providing the overload indication to the first core network function, and providing the overload indication to the first core network function comprises sending to the first core network function (406, 408) a control plane message (m654, m556, m559) comprising the overload indication.A19. The method of embodiment A1, wherein the method is performed by a second core network function (404), and detecting that a data flow is overloaded comprises receiving a message (m552, m554, m556, m654) comprising information indicating that the data flow is overloaded.A20. The method of embodiment A1, wherein the method comprises performing the remedial action after detecting that the data flow is overloaded, and performing the remedial action comprises: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.B1 . A network node (800) for data flow management, the network node being configured to perform a method (700) comprising: detecting (s501, s702) that a data flow is overloaded, wherein the data flow is an L4S enabled quality -of- service, QoS, flow or a service data flow, SDF, assigned to an L4S enabled QoS flow; and after detecting that the data flow is overloaded, providing (s704) an overload indication (m552, m554, m556, m559, m560, m654) to a first core network function (404, 406, 408) or performing a remedial action (s503, s505, s509, s511, s513).B2. The network node of embodiment B1 , wherein the network node is further configured to perform the method of any one of embodiments A2-A20.C1. A computer program (843) comprising instructions (844) which when executed by processing circuitry (802) of a network node causes the network node (800) to perform the method of any one of claims A1-A20.C2. A carrier containing the computer program of embodiment C1, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (842).

[0085] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0086] As used herein transmitting a message "to” or "toward” an intended recipient encompasses transmitting the message directly to the intended recipient or transmitting the message indirectly to the intended recipient (i.e., one or more other nodes are used to relay the message from the source node to the intended recipient). Likewise, as used herein receiving a message "from” a sender encompasses receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Further, as used herein "a” means "at least one” or "one or more.”

[0087] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Claims

CLAIMSWhat is claimed is:1 . A method (700) for data flow management, the method comprising: detecting (s501 , s702) that a data flow is overloaded, wherein the data flow is an L4S enabled quality-of- service, QoS, flow or a service data flow, SDF, assigned to an L4S enabled QoS flow; and after detecting that the data flow is overloaded, providing (s704) an overload indication (m552, m554, m556, m559, m560, m654) (e.g., information indicating that a QoS flow or SDF is overloaded) to a first core network function (404, 406, 408) and / or performing a remedial action (s503, s505, s509, s511 , s513).

2. The method of claim 1, wherein the method comprises providing the overload indication to the first core network function, the method is performed by a base station (500), and the base station provides the overload indication (m552, m654) to the first core network function (404, 406) in response to detecting that the data flow is overloaded.

3. The method of claim 2, wherein the method is performed by a distributed unit, DU (502), of the base station (500).

4. The method of claim 3, wherein the first core network function is a user plane function, UPF (404), and providing the overload indication to the UPF (404) comprises sending in-band to the UPF a message (m552) comprising the overload indication.

5. The method of claim 4, wherein the method further comprises the UPF (404) determining an SDF that is overloading the data flow.

6. The method of claim 5, wherein the method further comprises: after determining an SDF that is overloading the data flow, the UPF performs a remediation process comprising: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.

7. The method of claim 5, wherein the method further comprises: after determining an SDF that is overloading the L4S enabled QoS flow, the UPF sending a report (m559) to a session management function, SMF (406).

8. The method of claim 7, wherein the method further comprises: in response to receiving the report (m559) from the UPF, the SMF performs a remediation process comprising: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.

9. The method of claim 2, wherein the method is performed by a control unit, CU (504), of the base station (500). the first core network function is a session management function, SMF (406), and providing the overload indication to the SMF comprises sending to the SMF a control plane message (m654) comprising the overload indication.

10. The method of claim 9, wherein the method further comprises the SMF (404) obtaining information identifying an SDF that is overloading the data flow, wherein11. The method of claim 10, wherein the method further comprises: after determining an SDF that is overloading the data flow, the SMF performs a remediation process comprising: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.

12. The method of any one of claim 1-11, wherein the method further comprises: determining a queue delay of a queue for the data flow; determining a congestion notification marking rate for the data flow; and / or determining whether the queue for the data flow has overflown; detecting that the data flow is overloaded comprises: determining that the queue delay exceeds a delay threshold; determining that the congestion notification marking rate for the data flow exceeds a marking threshold; and / or determining that the queue has overflown.

13. The method of claim 1, wherein the method is performed by a user plane function, UPF (404), and the first core network function is a session management function, SMF (406).

14. The method of claim 13, wherein the method further comprises: after providing the overload indication to the SMF, the UPF receiving a request (m558) from the SMF; and in response to receiving the request from the SMF, the UPF determining an SDF that is overloading the data flow.

15. The method of claim 14, wherein the method further comprises: after determining an SDF that is overloading the data flow, the UPF performs a remediation process comprising: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.

16. The method of claim 14, wherein the method further comprises: after determining an SDF that is overloading the data flow, the UPF sending a report (m559) to the SMF(406).

17. The method of claim 1, wherein the method is performed by a session management function, SMF (406), and in response to detecting that the data flow is overloaded, the SMF performs a remedial action (s505), or in response to detecting that the data flow is overloaded, the SMF transmits a request to a user plane function, UPF (404) requesting the UPF to report the identity of an SDF that is overloading the data flow.

18. The method of claim 1, wherein the method comprises providing the overload indication to the first core network function, and providing the overload indication to the first core network function comprises sending to the first core network function (406, 408) a control plane message (m654, m556, m559) comprising the overload indication.

19. The method of claim 1, wherein the method is performed by a second core network function (404), and detecting that a data flow is overloaded comprises receiving a message (m552, m554, m556, m654) comprising information indicating that the data flow is overloaded.

20. The method of claim 1, wherein the method comprises performing the remedial action after detecting that the data flow is overloaded, and performing the remedial action comprises: throttling the overloading SDF; moving the overloading SDF to another L4S enabled QoS flow; moving the overloading SDF flow to a non-L4S enabled QoS Flow; disabling L4S on the overloaded data flow; or lowering the priority of the overloaded data flow.

21. A network node (800) for data flow management, the network node being configured to perform a method (700) comprising: detecting (s501, s702) that a data flow is overloaded, wherein the data flow is an L4S enabled quality -of- service, QoS, flow or a service data flow, SDF, assigned to an L4S enabled QoS flow; and after detecting that the data flow is overloaded, providing (s704) an overload indication (m552, m554, m556, m559, m560, m654) to a first core network function (404, 406, 408) or performing a remedial action (s503, s505, s509, s511, s513).

22. The network node of claim 21, wherein the network node is further configured to perform the method of any one of claim 2-20.

23. A computer program (843) comprising instructions (844) which when executed by processing circuitry (802) of a network node causes the network node (800) to perform the method of any one of claims 1-20.

24. A carrier containing the computer program of claim 23, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (842).

Images