Congestion marking in mobile networks
Technical Field
The present application relates to a method for operating a user plane entity and to the corresponding user plane entity. Furthermore, a method for operating a system comprising the user plane entity and at least one other node is provided together with the system itself. In addition, a computer program and a carrier comprising the computer program are provided.
Background
Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol (TCP) and is defined in RFC 3168. When ECN is successfully negotiated, an ECN-aware router may set a mark in the IP header instead of dropping a packet in order to signal impending congestion. The receiver of the packet echoes the congestion indication to the sender, which reduces its transmission rate as if it detected a dropped packet. ECN can be also applied to mobile networks, as for instance considered in the patent US8923115B2 (Using The ECN Mechanism To Signal Congestion Directly To The Base Station) which presents the idea that a UE uses the ECN mechanism to signal to the wireless network to adjust the scheduling and instantaneous allocation of L1/L2 (radio) resources. Another example is the patent US9762498B2 (Localized congestion exposure) which describes a method of localized congestion exposure within a local loop in a cellular network. The method is performed by a localized congestion exposure sender node of the local loop which inserts a declaration of an expected downstream congestion level into headers of received downlink packets; and forwarding the downlink packets that have the declaration of the expected downstream congestion level inserted into the headers toward the downstream user device. Overall speaking, methods using ECN rely on the fact that (i) the notification of congestion is directly inserted into the headers of user-plane packets and that (ii) the notification of congestion is related to some congestion detection algorithms which run directly at the user plane node in charge of ECN bit marking and which use local information (e.g., queue status) to understand whether there is a congestion situation.
In a legacy approach for ECN bit marking considering a mobile network, a user plane node (e.g., gNBs) implements its own ECN bit marking algorithm (based e.g. on queue status monitoring at PDCP or RLC layer) and performs the marking accordingly. With this approach, ECN bit marking is strictly associated to the capabilities of congestion detection of the network node which will finally perform the marking.
So far, the marking of ECN bit is related to the presence of specific algorithm for congestion detection implemented at user plane nodes (as only user plane nodes handles user data packets where ECN bit can be marked) usually at base station, e.g., by monitoring congestion events such as packet dropping at queue of PDCP layer.
Accordingly, a need exists to increase the use cases of an indication such as the ECN bit marking provided in the data packets of a data packet flow which signals a possible congestion.
Summary
This need is met by the features of the independent claims. Further aspects are described in the dependent claims.
According to a first aspect a method for operating a user plane entity is provided which is configured to forward data packets of a data packet flow exchanged in a cellular network between two endpoints. The user plane entity is located as intermediate node between the two endpoints. The method comprises the step of announcing to the other nodes of the cellular network external to the user plane entity that the user plane entity has a capability to control an indication in the data packet flow exchanged between the two endpoints, wherein this indication signals a possible congestion affecting the data packets of the data packet flow between the two endpoints. Furthermore, network information is received from one of the other nodes which is relevant for determining the possible congestion. The received network information is processed and the indication in the data packets is controlled in dependence on the processing.
Furthermore, the corresponding user plane entity is provided comprising a memory and at least one processing unit, wherein the memory contains instructions executable by the at least one processing unit. The user plane entity is operative to work as discussed above or as discussed in further detail below.
As an alternative, a user plane entity is provided comprising a first module configured to announce to the other nodes of the cellular network external to the user plane entity that the user plane entity has a capability to control an indication in the data packet flow exchanged between the two endpoints, wherein this indication signals a possible congestion affecting the data packets in the data packet flow between the two endpoints, wherein the user plane entity is located as intermediate node between the two endpoints. The user plane entity comprises a second module configured to receive network information relevant for determining the possible congestion from one of the other nodes. A third module is provided configured to process the received network information and a fourth module is provided configured to control the indication in the data packets in dependence on the processing.
The user plane entity as discussed above has the advantage that the indication set by the user entity can be controlled by other nodes outside the user plane entity. Accordingly, other nodes can take advantage of the controlling of the indication. In other words: The option to control the indication in the data packet flow is offered to network nodes not part of the user plane entity.
Furthermore, a method for operating a system is provided, wherein the system comprises the user plane entity and at least one other node of the cellular network, wherein the at least one other node initiates a transmission of the network information to the user plane entity.
Additionally, a system is provided which comprises the user plane entity and the at least one other node, wherein the system is operative to initiate a transmission of the network information to the user plane entity.
Furthermore, a computer program comprising program code to be executed by at least one processing unit of a user plane entity or of the system comprising the user plane entity and at least one other node is provided, wherein execution of the program code causes the at least one processing unit to carry out a method as mentioned above or as discussed in detail below. Additionally, a carrier comprising the computer program is provided, wherein the carrier is one of an electronic signal, optical signal, radio signal, and a computer readable storage medium.
It is to be understood that the features mentioned above and features yet to be explained below can be used not only in the respective combinations indicated, but also in other combinations or in isolation without departing from the scope of the present invention. Features of the above- mentioned aspects and embodiments described below may be combined with each other in other embodiments unless explicitly mentioned otherwise.
Brief Description of the Drawings
The foregoing and additional features and effects of the application will become apparent from the following detailed description when read in conjunction with the accompanying drawings in which like reference numerals refer to like elements.
Fig. 1 shows a schematic architectural overview over a system in which a user plane node located between two endpoints of a data packet flow offers the possibility to control an indication signaling a possible congestion.
Fig. 2 shows a schematic view of a message exchange between the entities involved when another network node controls the indication in the data packet flow indicating a possible congestion.
Fig. 3 shows one possible implementation where the user plane node uses network information generated from other nodes as input for controlling the indication in the data packet flow indicating a possible congestion.
Fig. 4 shows another possible implementation where the user plane node uses network information generated from other nodes as input for controlling the indication in the data packet flow indicating a possible congestion.
Fig. 5 shows an example flowchart of a method carried out by the user plane entity in a procedure as shown in Figs. 2 to 4.
Fig. 6 shows an example schematic representation of a user plane entity configured to control an indication of a possible congestion in the data packets based on information received from another node.
Fig. 7 shows another example schematic representation of a user plane entity configured to control an indication of a possible congestion in the data packets based on information received from another node. Detailed
In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are to be illustrative only.
The drawings are to be regarded as being schematic representations, and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose becomes apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components of physical or functional units shown in the drawings and described hereinafter may be implemented by an indirect connection or coupling. A coupling between components may be established over a wired or wireless connection. Functional blocks may be implemented in hardware, software, firmware, or a combination thereof.
In the following a solution will be discussed in which the indication signaling a possible congestion is an ECN bit; another solution could be that the indication signaling a possible congestion is a field added to the header of L2 layer data packets, e.g., a MAC control element (CE); however, any other kind of marking might be used which can be placed in the data packet flow to indicate a possible congestion.
The marking can have the effect that the marking is sent back to the transmitting node transmitting the data packet flow to a receiving node. When the transmitting node, the origin of the data packet flow knows that a congestion is occurring or might occur in the path between the transmitter and the receiver, the transmitter could react accordingly and take countermeasures such as a reduction of the data flow rate.
The process of controlling the indication such as the ECN bit marking at the user plane nodes is empowered and offered to network nodes not part of the user plane. The controlling of the indication or the ECN bit marking is performed by the user plane node upon request or after processing network information generated from different nodes or functions of a cellular network, wherein potentially any network node of the cellular network, also from different domains, such as a cloud infrastructure, might be used as the other node. Instead of managing the use of the indication in the data packet flow based on internal information available at the user plane node such as the queue status, the controlling of the indication may be seen as a service offered by the user plane node. This enables the setting of the indication such as the ECN bit marking to be exploited by other nodes not part of the user plane with the aim to react to several network situations which could benefit from an application bit rate reduction.
In the following a 5G cellular network is considered for the cellular network as an example. Nevertheless, the idea described below can also be applied to other cellular networks such as 4G networks or any other cellular network technology.
The different functional entities of the cellular network are considered as entities and the corresponding node reflects the functionality provided by the corresponding node. Accordingly, entity and function might be used interchangeably so that the user plane entity may be implemented by a User Plane Function, UPF or vice versa.
One idea of the present application is to extend a cellular or mobile network with a functionality where the nodes or functions, especially the ones which are not part of the user plane, can request the marking with the indication of a possible congestion to be performed by the user plane entity either explicitly, such as a request to start or stop the marking, or implicitly by providing network information which then triggers the start or stop of the marking.
The other node which can request the marking or which can control the setting of the indication could be a Network Data Analytics function, NWDAF, a Session Management Function, SMF, a user plane function or an Access and Mobility management Function, AMF. Furthermore, an Operations, Administration and Maintenance system, OAM, RAN distributed unit or a RAN centralized unit or other cloud infrastructure monitoring functionalities or transport network infrastructure monitoring functionalities may be used.
Accordingly, functions in the control plane of the network which either generate performance related network information or oversee the managing/monitoring network traffic can ask the user plane entity to control the indication set in the data packet flows. Furthermore, nodes and other network domains might be used, such as nodes of the cloud infrastructure, which monitor the load of cloud instances or nodes of the transport/backhaul network which monitor the load of the transport or backhaul links.
Although the present disclosure focuses on ECN bit marking functionalities, the idea described above or below may be applied to other functionalities that require some changes of fields of higher layers of the protocol stack, such as IP, TCP QIIIC, or the IP headers that could be performed by network nodes handling the user plane packets. The user plane path is between the UE, the gNB, the UPF and the server. Additional user plane entities might be part of the data packet flow.
Fig. 1 shows a schematic overview in which a data packet flow 20 is exchanged between two endpoints 40 and 50. Each of the endpoints 40 and 50 comprises an application 41 , 51 which initiates the data packet flow. Furthermore, each of the endpoints comprises a stack 42/52 through which the data packet flow 20 is passed. The user plane stack at the UE comprises from top to bottom, the Application layer (including application protocols like HTTP, but also TCP/UDP/QUIC, thus the layers L4 to L7, followed by the PDU layer (basically IP), followed by the 5G-AN protocol layers (including SDAP, PDCP, RCL, MAC; PHY). The user plane stack at the server end point comprises from top to bottom the application layer as mentioned above, followed by the PDU layer and layers 2 and 1 .
A user plane entity 100 is located between the two endpoints 40 and 50. The user plane entity 100 comprises a forwarding mechanism 140 which forwards the data packets of the data packet flow between the two endpoints, wherein either endpoint 40 is the source of the data packet flow and endpoint 50 is the destination or vice versa. The user plane node furthermore comprises a queue 150 which is configured to queue the data packets transmitted in the data packet flow and configured to control the throughput of the data packet flow through the user plane node 100.
Furthermore, another node 200 of the cellular network is provided comprising an application 210 which is interested in controlling an indication which is set by the user plane entity 100 in the data packets of the data packet flow. The user plane entity can be one of many user plane entities in the flow, where only one user plane entity does the marking. The application 210 could be an NWDAF estimating the throughput achievable for a certain data packet flow, a RAN functionality estimating the throughout achievable for a certain data packet flow, or performing admission control tasks and realizing that some packet flows would have to lower the bitrate. Furthermore the application 210 could be an orchestrator of a cloud infrastructure estimating the throughput that certain cloud entities handling data packet flows could achieve I support. Accordingly, the other node 200 intends to control the setting of the indication which signals to the receiving side of the data packet flow that a congestion might occur. This kind of information may then be signaled pack to the transmitting endpoint. The congestion might already be present or might occur in the near future based on a prediction made by the other node 200 or as received by the other node 200. In the embodiment shown the other node 200 controls the setting of the ECN bit in the data packet flow 20. The connection between the forwarding mechanism 140 and the application 210 may be implemented as ECN Application Programming Interface, API. In the same way the interface between the application 41 , the stack 42 or the interface between stack 52 and application 51 and/or the interface between the queueing mechanism 150 and the forwarding mechanism 140 may be implemented as ECN API.
The overall solution proposed is depicted in Fig. 2. In the proposed solution an ECN bit marking can be performed by user plane nodes upon reception of network information or explicit request from other network nodes not involved in the user plane. Fig. 2 shows that a generic user plane node 100 performs ECN bit marking upon processing network information or a marking request from the other network node 200 of the mobile network (potentially, also a node not part of the user plane). Some steps of the proposed solution can be summarized as follows:
• Step S11 is a subscription procedure, which happens between the user plane node 100 in charge of performing ECN bit and the network node 200 which is interested in ECN bit marking. The subscription can be either triggered by the user plane node 100 or by the other network node 200, depending whether ECN bit marking is performed implicitly or explicitly based on the other involved network node. More details will be provided below.
• Step S12 is when the network node provides the user plane node with either network information or a marking request.
• Step S13 is when the user plane node 100 processes the received network information or marking request from the other network node 200. During this step, the user plane node 100 uses the information received from the other network node 200 to understand whether ECN bit marking should be performed (either start or stop marking) or not.
• During step S14, the user plane node implements the decision taken during previous step. One possible implementation is that the user plane node in charge of performing ECN bit marking uses network information provided by other network nodes as input to the algorithm of ECN bit marking. This approach is depicted in Fig. 3. With this approach, the user plane node performing ECN bit marking can re-use existing I standardized APIs and network information I notification while at the same time improving its capabilities of ECN bit marking in addition to legacy e.g. queue status. Considering the four steps listed above, in this implementation the following can happen:
• In step S21 , the user plane node subscribes to or requests network information or network notifications which are relevant to ECN bit marking. In this case, the user plane node is extended with a functionality which allows, if ECN bit marking is supported by and authorized for a certain flow, to understand which network information or network notifications are relevant and to trigger a request or a subscription to such information I notifications. Examples of relevant network information I notifications for ECN bit marking might include, but not limited to, QoS (Quality of Service) Sustainability Analytics (generated by NWDAF in current 5GS), notifications generated by RAN (Radio Access Network) on QoS unfulfillment/re-fulfilment, policy updates generated by PCF, PDU session modifications generated by SMF (Session Management Function), dedicated performance-related information I notifications generated by dedicated network functionalities (e.g., performance monitoring I prediction functionalities deployed either at RAN or at core network), performance-related information I notifications generated by transport or backhaul networks, information I notifications generated by cloud infrastructure, deployment information such as cell topologies and borders, statistical information such as maps of cell strengths, etc. Subscription or request of relevant network information I notifications is performed through standard-defined procedures (e.g., subscription to QoS Sustainability Analytics by NWDAF) and I or through proprietary procedures depending on the case.
• During step S22, the network node provides the user plane node with the network information or network notifications as specified during the first step (S21).
• During step S23, the user plane node 100 processes the received network information. For this step, the user plane node is extended with a functionality allowing to process the received information / notification from another network node to understand whether ECN bit marking should be performed (either start or stop marking) or not. This processing could include, but not limited to, the following: o Check whether the received information is relevant for ECN bit marking. This can consider for example checking if the information is performance-related (e.g., performance improvement I degradation) then it could be considered relevant to ECN bit marking while if the information is not related to performance then it could be considered as not relevant to ECN bit marking. The checking could focus on understanding the impact on ECN bit marking based on the time windows related to the network information. For instance, modification of ECN bit marking might not be necessary for network information indicating an upcoming loss of coverage or performance degradation I improvement lasting only few seconds while long-lasting performance changes could be worth of ECN bit marking. o Identify if the received information refers to performance improvement or degradation and modifies ECN bit marking accordingly. If the ECN bit is currently not marked and the information refers to performance improvement, then there will be no change to ECN bit marking. If the ECN bit is currently not marked and the information refers to performance degradation, then the ECN bit will be marked to signal the performance degradation to the application. If the ECN bit is currently marked and the information refers to performance improvement, then the ECN bit marking will be removed to signal the performance improvement to the application. If the ECN bit is currently marked and the information refers to performance degradation, then there will be no change to ECN bit marking. o Identify which flows the network information refers to. This can be done by e.g. considering information such as UE ID, QoS Flow ID (QFI), etc., included in the received network information. o Identify which time windows should be considered for ECN bit marking. Especially when considering network information related to prediction of network performance (e.g., performance degradation I improvement predicted e.g. 30 seconds ahead), the user plane node identifies when ECN bit marking should be modified. For example, if performance degradation I improvement is predicted e.g. 30 seconds ahead, the ECN bit marking could be set to start right after the processing of the received network information (30 seconds ahead of the actual degradation I improvement). Another option is that ECN bit marking could be set to start closer to the predicted time of performance degradation I improvement (e.g., only 10 seconds ahead instead of 30 seconds as indicated in the received network information).
• During step S24, the user plane node implements the decision taken during previous step.
The approach depicted in Fig. 3 has the advantage that it can be implemented on existing networks without requiring the introduction of new APIs or of new network information. The limitation is related to the fact that additional logic would be required at the user plane node in charge of ECN bit marking to process all possible network information I notifications potentially related to ECN bit marking.
Another possible implementation is that the user plane node in charge of performing ECN bit marking offers a new API, e.g., ECN bit marking API, which is used by other network nodes to explicitly request ECN bit marking. This approach is depicted in Fig. 4. With this approach, network nodes can implement their own logic to understand when to trigger ECN bit marking and accordingly request the marking to the user plane node which handles user plane packets. Considering the four steps listed above, in this implementation one has:
• In step S31 , a network node subscribes to ECN bit marking offered by the user plane node through the ECN bit marking API. Consequently, the mobile network is extended with the following functionalities: o A user plane node is extended with an ECN bit marking API, which is used by other network nodes for triggering ECN bit marking. o A network procedure is introduced to allow a network node to subscribe to ECN bit marking by using the ECN bit marking API. This subscription can be implemented in several ways: ■ One option is that the user plane advertises its capabilities of ECN bit marking to other network nodes, potentially indicating that ECN bit marking is supported for certain UE I D(s), QoS Flow IDs (QFIs), etc. Then relevant network nodes provide a reply to the user plane node indicating that they are interested to ECN bit marking, potentially indicating that they are interested in ECN bit marking for certain UE I D(s), QoS Flow IDs (QFIs), etc.
■ Another option is that network nodes of a mobile or cellular network directly trigger a subscription to ECN bit marking towards relevant nodes of the user plane. In this case, the network node is aware of the ECN bit marking API of a certain user plane node, and uses this API to inform the user plane node that ECN bit marking might be required for certain UE ID(s), QoS Flow IDs (QFIs), etc.
• During step S32, the network node sends a marking request information to the relevant user plane node by using the ECN bit marking API. To this aim, the network node is extended with a functionality allowing to understand whether ECN bit marking would be required for certain UE(s) or for certain flow(s) and to accordingly trigger an ECN bit marking request to relevant user plane nodes. The ECN bit marking request could include, but not limited to, the following: o ECN bit action, i.e., start / stop ECN bit marking. o Associated time windows, e.g., perform the action until further notice, perform the action for the upcoming 1 minute, trigger the action in 20 seconds, etc. o Involved UE(s), or QoS Flow IDs (QFIs), etc., for which ECN bit marking is requested.
• During step S33, the user plane node 100 processes the received ECN bit marking request. For this step, the user plane node is extended with a functionality allowing to process the received ECN bit marking request. This processing could include, but not limited to, checking relevant flow(s) to be marked, setting time windows of marking, etc. • During step S34, the user plane node 100 implements the decision taken during the previous step.
The approach depicted in Fig. 4 has the advantage that the process of ECN bit marking is not bounded anymore to existing network information of a cellular network, potentially any network node of any network domain can use the ECN bit marking API offered by user plane nodes to ask for ECN bit marking. One example is a radio network control function that needs to reduce the load, and thus orders marking of the ECN bit, for all or certain users in an area. Another example is a cloud infrastructure manager that, upon detection of high process load of user plane functions, uses the ECN bit marking API offered by user plane nodes to ask the application to reduce the bitrate. This has the advantage that a generic network node of a generic network domain can implement its own logic to estimate whether ECN bit marking could be needed or not for a certain UE (User equipment) I flow, without having any impact on the functionalities of the user plane node performing the marking of user plane packets.
It should be noted that the details given for some of the steps shown in Fig. 3 might also apply to the corresponding step shown in Fig. 4 and the other way round, if not indicated otherwise. By way of example details given in step S32 may also apply to step S22 discussed in connection with Fig. 3. In the same way the details given in step S23 might also be valid for step S33.
Fig. 5 summarizes some of the steps carried out by the user plane node, i.e. user plane entity in the embodiments discussed above. In step S51 the user plane entity announces to the other nodes of the cellular network which are nodes external to the user plane entity that the user plane entity has the capability to control the indication in the data packet flow, wherein this indication signals a possible congestion affecting the data packets of the data packet flow between the two endpoints. This was discussed above in connection with steps S11 , S21 and S31. In step S52 one of the other nodes sends network information so that the user plane node receives the network information from one of the other nodes of the cellular network, wherein the network information is relevant for determining the possible congestion between the two endpoints 40 and 50. In step S53 the received network information is processed as discussed in step S13, S23 and S33. Step S54 describes the controlling of the indication in the data packets in dependence on the processing as mentioned in S14, S24 or S34.
The controlling of the indication can indicate that the indication is set based on the network information or is removed based on the received network information.
Fig. 6 shows a schematic architectural view of the user plane entity 100 which can carry out the above discussed steps. The user plane entity 100 comprises an interface 110 which is provided for transmitting user data or control messages to other entities and which is provided for receiving user data and control messages from other entities. The interface is especially qualified to forward the data packets between the endpoints and is qualified for receiving the network information from the other network node. The user plane entity 100 furthermore comprises a processing unit 120 which is responsible for the operation of the entity 100. The processing unit 120 can comprise one or more processors and can carry out instructions stored on a memory 130, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk, or the like. The memory 130 can furthermore include a suitable program code to be executed by the processing unit 120 so as to implement the above-described functionalities in which the user plane entity 100 is involved.
Fig. 7 shows another schematic architectural view of a user plane entity 300, wherein the user plane entity comprises a first module 310 configured for announcing the capability of controlling the indication in the data packets as discussed above in connection with steps S11 , S21 or S31 . The user plane entity 300 comprises a second module 320 configured to receive the network information from the other node as discussed above in step S12, S22 or S32. A third module 330 is provided configured to process the network information as mentioned in step S13, S23 or S33. A module 340 is provided configured to control the indication as mentioned in step S14, S24 or S34.
From the above said some conclusions can be drawn.
When the user plane entity processes the received network information, it may determine whether the received network information indicates a change of the possible congestion. If this is the case, the user plane entity determines whether the received network information relates to an end, an improvement or a degradation of the congestion and furthermore identifies which at least one data packet flow is affected by the received network information. The indication is then controlled in the identified at least one data packet flow based on the received network.
It is possible that the user plane entity determines a time window in which the possible congestion indicates a change of the possible congestion based on the received network information. The indication is then controlled in the determined time window. Preferably it is only controlled in the determined time window and not before and after the time window, so that the controlling is limited to the time window.
When the indication is controlled, this can mean that the indication is set based on the network information or that the indication is removed based on the received network information.
Furthermore, when the network information is received by the user plane node, a request may be received to set or remove the indication in the data packets, wherein the request comprises at least one flow identifier which identifies the at least one data packet flow in which the indication should be set or removed.
The received network information can mean that different pieces of information are received, such as Quality of Service, QoS, related information for the data packet flow, performance information of the cellular network, a deployment information including information about a topology of the cellular network and/or statistical information of the cellular network. All these parameters alone or in combination might be used to control the indication.
When the user plane entity announces its capability to control the indication, this can mean that the user plane entity subscribes to a flow related network information by which the user plane entity then asks for the network information allowing to determine the possible congestion in the cellular network. The subscription of the user plane entity to the flow related network information may be triggered by the user plane entity or may be triggered by the other node.
When the capability is announced indicating that the user plane entity can control the indication, this can mean that the user plane entity receives from one other node a subscription request to the flow related network information which is offered by the user plane entity and by which the user plane entity offers the service to control the indication upon a request received from a subscriber to the service.
The received network information may further comprise at least one of the following pieces of information: a request to start or stop setting the indication, a time window in which the indication should be controlled, and/or at least one flow identifier identifying the at least one data packet flow where the indication should be controlled. As far as the system is concerned comprising the user plane entity and the at least one other node, it is possible that the transmission of the network information is triggered by the at least one other node or is triggered by a subscription request received from the user plane entity in which the user plane entity subscribes to the flow related network information provided by the at least one other node to provide the network information. The at least one other node may include one of the following functions: a Network Data Analytics Function, NWDAF, a Session Management Function, SMF, a User Plane Function, UPF, an Access and Mobility management Function, AMF, and a Policy Control Function, PCF.
One advantage of the above discussed solution versus the current solution of ECN bit marking is that several performance related network parameters could be implicitly provided to the application by re-using ECN bit marking also in the case that such information is generated or provided by network nodes or functions which are not part of the user plane. The controlling of the indication has the advantage that it can be performed upon request or based on network information generated by several network nodes or functions not part of the user plane instead of leveraging only on congestion detection algorithms at the user plane entity in charge of the bit marking.
This approach has the limitation that other network functionalities or nodes in other segments of the network (control plane functions such as NWDAF or SMF or PCF, which are thus not involved in user plane but generate performance-related information) could not take advantage of the ECN bit marking functionality to e.g. deliver to application the information that bitrate should be reduced. This is also valid for other components of the network infrastructure, e.g., one can think about a cloud infrastructure which generates information that high processing load for user plane packet is detected in a certain cloud instance. In this case, the invention can help that the application reduces the transmission bitrate and to this aim the ECN bit marking is a useful feature to be used. This would not be possible if ECN bit marking is performed based on congestion detection algorithm at user plane nodes.
Given that ECN bit marking is a rather application-friendly feature, it could be useful to reuse this feature to provide applications with network-related information generated from network nodes not part of the user plane or from entities of different network domains, e.g., cloud infrastructure, but this is not currently possible without modifying congestion detection algorithms at user plane nodes The scenario above might also be used in a roaming situation in order to make the application aware of a performance related information of the visited network. The delivery of network information generated from the core network nodes of the visited network to the application layer via control plane signaling may depend on agreements between the visited and the home network. Furthermore, with the proposed solution the ECN bit marking process can be used for this purpose when the final aim of the network service is to support a bit rate adaptation at application.